Enforcing password strength

There have been a lot of high-profile site compromises of late (kernel.org, Linux.com, MySQL, WineHQ, ...), most or all of which have led to password disclosure. Hopefully all of the disclosed passwords were stored as hash values, but, even so, sufficiently motivated attackers may well be able to crack some of the passwords via brute force or other means. Because passwords are often reused between sites, these compromises have made projects and others concerned about the security of the passwords granting access to their sites.

That concern led Kevin Fenzi of the Fedora infrastructure team to put out a message noting that all Fedora Account System (FAS) users are required to change their password (and SSH public keys, more about that below). As Fenzi said, the password change is not because of any known compromise of the Fedora infrastructure, but is, instead, a reaction to the recent compromises: "due to the large number of high profile sites with security breaches in recent months, that this is a great time for all Fedora contributors and users to review their security settings and move to 'best practices' on their machines." Part of those "best practices" is to have a strong password, so Fedora is enforcing some rules on the new passwords:

I asked Fenzi in an email where the rules came from, and he pointed me to a Fedora infrastructure bug ticket and the report [PDF] from the University of Amsterdam that it references. That report looks at various password cracking methods and estimates that using those guidelines (actually just the first three) will result in passwords that will take ten years or more to crack at 2 billion guesses per second. That rate was an average of what the researchers found that a modern GPU-equipped system could guess for several different hash algorithms.

As Przemek Klosowski points out, the number of possibilities for each kind of password differ widely. There is a math error in the length-12 case (should be (24+10)^12), and evidently Klosowski is only considering 24 letters, rather than the 26 in English, but his conclusion still stands: the number of possibilities are ten orders of magnitude apart from the first to the last rule. In the end, that doesn't really matter, as long as the weakest choice is sufficient.

Most who commented on the requirement were not particularly annoyed by the password change mandate, but the same cannot be said about the SSH key requirement. SSH users may tend to be more security savvy and are thus less likely to have lost control of their private SSH key than they are to have an easily cracked password—though of course that's no guarantee. But if the private SSH key that corresponds to the public key installed on the FAS servers has been compromised, it's likely that's because the owner's system has been breached. If that's the case, generating a new SSH key on a compromised system will likely only result in another compromised key. In addition, a massive SSH key flag day has its own dangers as Simo Sorce points out:

There is a strong belief that the kernel.org compromise was done via a compromised SSH key, however, so the infrastructure team is requiring folks to change their keys. Many are not happy about it, including Sorce who goes on to say:

Sorce's complaint is a reasonable one. Unfortunately, it's hard to know whose keys may have been compromised (or, indeed, if any have been compromised at all) as several folks mentioned. By bringing it up and requiring everyone to change their keys, it may result in better security—and will at least raise the awareness level of the problem, which could result in better security practices by some who were being lax. It is undoubtedly annoying to those who have been careful with their keys, but it isn't that hard to generate and use a new key, even if it is only used for FAS.

Raising the level of awareness of these issues is perhaps the only good thing that has come from these high-profile break-ins. It is pretty easy to get complacent about security, reuse passwords on many sites, have password-less SSH keys, and so on. Events like the kernel.org breach can help break us all of our lax security habits. Certainly many sites, projects, and organizations—even those who haven't suffered a breach—are looking at their security practices; it's a good time for individuals to do so as well.

Passwords are only part of the story, of course, but they tend to be on the "front-line" of the security of our systems, so it is a good place to start. As xkcd so eloquently put it, the time for relatively short but "hard" to guess passwords may well be behind us: pass phrases are more easily remembered and less easily cracked. It's good to see that Fedora is not enforcing a limit on the password length, it's likely that many other sites do have a fairly short limit that will make using pass phrases harder. The Fedora rules do provide some good guidelines to follow when creating passwords or phrases.

Having too many passwords is almost as bad as having too few, because managing them securely can be quite a headache. One suggestion that Fenzi made is to use a password manager program like "revelation, gnome-keyring, seahorse, or keepassx". Looking more closely at those kinds of applications is on my to-do list, for both personal and professional reasons. Look for an article on that topic to appear on your virtual doorstep in the near future.