Extended Subset

Impervia has released an interesting study of 32M user passwords obtained incidental to a data breach. We’re used to this kind of thing by now, I suppose. But in any case it appears that only 0.2% of user accounts had passwords meeting their minimum criteria for a “strong” password:

• Eight or more characters
• Some mixture of the basic character classes: upper- and lower-case, digits, and symbols.

We’ve been hearing this advice for years. In fact, it’s now recommended practice for new password entry text fields to enforce some minimal complexity requirements. Looking at the “top 20″ list of common passwords, anything would be an improvement.

But are mechanical complexity requirements always enhance security? More importantly, is it possible that they could actually decrease security for careful and conscientious users who choose reasonable passwords in the first place?

Consider Schneier’s example password from the report. Distilled from a pass phrase, it comes out as “tlpWENT2m”. For most systems, I like to use the pwgen utility to generate reasonably good passwords. For example, it just suggested the password “Aisah4ahw7″ (I agree they should be written down and managed with careful physical security).

These example passwords have 9 or 10 characters with apparently good probabilities of encountering capital letters and digits. The upper- and lower-case letters and digits amount to 62 possibilities for each character, putting a hard upper limit on the entropy of about 6 bits per character. At 10 characters in length, we could theoretically approach 60 bits of total entropy in our password! “Good enough for government work” as they say. Or at least it used to be.

So what happens when a well-intentioned user interface rejects our thoughtfully-chosen password on the basis that “it must contain a symbol”? Assume that the user has already chosen the password they want to use and has written it down, and it’s otherwise a good one. Perhaps also the UI enforces the recommendation (the report attributes this to NASA) that “if there is only one letter or special character, it should not be either the first or last character in the password.” My guess is that most users at this point get out the eraser and replace one of the characters with a symbol in order to satisfy the rule.

But herein lies a problem: On my (typical US) keyboard there are only 32 choices for symbol characters. In addition, UI text fields have a reputation for rejecting (or silently munging) quote-like or escape-like characters which probably rules out some of the more interesting choices. We have just reduced the maximum entropy contributed by that character from 6 to 5 bits!

But you forgot to consider … Yes, there are a number of holes with this theory.  Lacking any more interesting rhetorical device at the moment, I’ll pretend to discuss them with myself. Here are a few I can think of:

• Those example passwords were derived from rules for English text in one way or another. They won’t be anywhere close to theoretical maximum entropy. - True, but neither will the replacement symbol. More than likely the user will simply replace an ‘a’ with an ‘@’ or some such change. Note the sample characters in the recommendation: !@#$%^&*,;” Even those authors seem to like to type “123456″!
• The user has some freedom to choose which of the characters he will replace with the symbol. - Applying all the “best practices” to the ten character password leaves eight options. Potentially, this could represent three bits of added entropy and in fact push the symbol requirement into a net gain.
• The user could add or change more than one symbol. - Sure, the user has just been required to type one digit, one uppercase letter, one lowercase letter, and five other chars. How much more tricky typing are they likely to be in the mood to add? Oh, and they have to type it perfectly twice in a row right now, and an indefinite number of times in the future.

So this analysis is largely inconclusive. Adding a new password complexity requirement may increase the effective entropy somewhat, but there may even be cases where it decreases it. What is clear though is that there is no set of practical, enforceable requirements that can magically take the users from dictionary words to that perfect, even distribution over the 94^10 = 5e19 possible passwords.

But above all, look out for the law of unintended consequences. Especially when feeling the urge to subject us humans to new sets of rigid mechanical rules, however great they might seem on paper.

DReaM-Cache: Distributed Real-Time Transaction Memory Cache to Support Two-Factor Authentication Services and its Reliability

Here’s a paper we (PhoneFactor and UMKC) will be presenting at IEEE NOMS 2010 in April.

It gives an overview and an in-depth reliability analysis of a distributed real-time transactional data store we developed in support of the PhoneFactor back-end systems. It’s superficially similar to memcached, except that it’s highly available rather than scalable.

We originally called the system “cloud” internally, and still do. Unfortunately though that term has been so hyped-up in the last few years (for something else entirely) that we had to come up with another name for the paper.

• SteveD has posted an experimental patch for GNUTLS
• Unfortunately, it appears that D-Link routers implement a protocol which allows router reconfiguration via SOAP and don’t authenticate it properly. Mix in a little DNS rebinding and this likely results in a remote-MitM vulnerability.

The IESG has approved a fix for TLS! The accepted proposal is substantially the same as that proposed by the Sept. 29 meeting of the Project Mogul activity.

Over the coming weeks, the document itself navigates the RFC Editor publication process picking up an RFC number, normative references, and review along the way. But no further technical changes are expected at this point.

Vendors may now deliver to their customers patches which implement the fix blessed by the IETF.

Most vendors have had the details of the fix (with only minor differences) for over three months now. Some are known to have working (and interoperable) implementations internally, so I expect we will see some patches shipping shortly. Since vendors are no longer “blocking on the IETF”, now is when we get to find out which of them are the most responsive when it comes to keeping their customers secure. In all fairness, this has been a rather difficult security problem to address and larger vendors with many products to support have disproportionately more work to do, particularly in the testing process.

One aspect of this fix is that both the client and the server must be patched in order to restore the full security guarantees advertised by TLS. This obviously will not happen tomorrow, but eventually clients and servers will have to start refusing connections with unpatched endpoints (just like they do with ancient versions of SSL today). I.e., their configuration needs to go from “insecure/compatible mode” to “secure/strict mode”. Unfortunately, as long as there is a single unpatched client and a single compatible-mode server in the world (or a compatible-mode client and an unpatched server) there exists a potential vulnerability. Note that some attacks do not require the victim client and server to be expecting to talk the same protocol on the same port!

To this end, in the coming months we will need client applications to begin warning users if they are connecting to an unpatched server. After all, wouldn’t you expect your browser to warn you if your connection could be hijacked because the (supposedly) secure site to which you were connecting was not maintained well enough to apply critical security patches on a regular basis?

In related news:

• IEEE Internet Computing has a nice article on the bug.
• Steve and I will be speaking at Shmoocon 2010 and TROOPERS10 about both the technical aspects of the bug and the some of the meta-disclosure issues we’ve encountered along the way.