NIST on Password Storage

Password storage is a part of almost any computer-based system and one that presents serious security issues. Numerous breaches have occurs, even in highly security conscious firms. These have revealed millions of user passwords. Strict laws in most US state and the EU now require notifying users of security breaches, making such breaches an expensive liability. 

Yet clear advice on safe password storage is hard to find.  The U.S. National Institute of Standards and Technology (NIST) has a Guide to Enterprise Password Management (Draft), SP800-118, published in April 2009, but it devotes a little more than one page to password storage and provides questionable advice, in my opinion. NIST SP800-118 suggests three ways to protect stored passwords: 

* Using OS access control features to restrict access to files that contain passwords. This is a no-brainer as a first line of defense, but it's not sufficient. OS access control features have proven inadequate in practice. Undoubtedly most, if not all, of the organizations that have suffered password breaches employed access control measures. Attackers bypass such measures by exploiting various software security flaws that allow privilege escalation.

* Encrypting files that contain passwords. The problem here is than an attacker who bypasses those OS access control features to get at the encrypted passwords will likely be able to grab the encryption key as well, since it will be in active use by the system. NIST tries to justify the dangerous practice storing plaintext passwords, saying "cryptographic hashes may not be an option if an authentication protocol requires that an entered password be directly compared to a stored password." Any security benefit from such a protocol must be weighed against the risk of compromising all user passwords. The most common reason for comparing an entered password with a stored password is to see if the user is creating a password that is too similar to a previous password they used. This is one of the most hated and easily bypassed password policy "security" measures. Most users subject to mandatory password change regimes have developed their own way to modify their last password just enough to pass the comparison screen. These methods are usually insecure and well known to attackers. If you run a high security system and you don't trust users to pick secure passwords, don't let them. Generate random passwords with sufficient entropy in a few different formats and let the user pick one they like. Users won't love this either, but at least it offers real security. I plan to talk more about this approach in a future post.

* Storing one-way cryptographic hashes for passwords instead of storing the passwords themselves. Bingo. In my view, this is the only safe way to store passwords. Done right, hashing can protect user passwords of reasonable strength even if the entire password file is stolen. 

NIST goes on to say that Federal agencies must protect passwords using FIPS-approved cryptographic algorithm implementations. FIPS stands for Federal Information Processing Standard. But as I pointed out in my previous post, there is no FIPS-approved cryptographic algorithm that, by itself, is adequate to protect passwords. FIPS-approved cryptographic algorithms were all designed to be fast and efficient, good for most security applications but very bad for password storage. A specialized algorithm that consumes computer resources must be used, and such hashes can incorporate FIPS-approved cryptographic algorithms, allowing compliance with this guideline.

NIST does have a guideline that documents a more suitable method for protecting stored passwords, SP800-132 Recommendation for Password-Based Key Derivation, issued December 2010.  It describes an algorithm for performing repeated hashes know as PBKDF2.  Unfortunately, the document only discusses using it for "deriving cryptographic keys from passwords or passphrases," an important application to be sure, but the exact same method, can be used to protect stored passwords.  Apple uses PBKDF2 in Mountain Lion, its latest version of the Macintosh OS X operating system.

Now I understand NIST has a lot on its plate, and SP 800-132 on PBKDF2 did come out after SP 800-118 on Password Management, but protecting stored passwords is an important security issue. I'd like to see NIST do several things: 

1. Update SP 800-118 to recommend use PBKDF2 as described in SP 800-132, and depreciate storing passwords as plaintext. Only a few details need to be spelled out, such as what PBKDF2 output key length and repetitions count to use for various security levels. (NIST recommends 1000 iterations as a minimum, that's probably too low now. Apple uses around 20,000.) 

2. Start a effort to develop better a better algorithm for password storage (perhaps PBKDF3) that either uses or prevents use of GPUs, preferably with options for both. Colin Percival's scrypt might be a good starting point. His promising approach is currently an IETF draft, but apparently no formal review has even begun.

3. Consider certifying one of the SHA3 finalists that was hard to implement in hardware for use in password storage. 

4. Do a more through revision of SP 800-118 to provide clearer guidance on a range of issues. I plan to say more about this in a future post as well.

There are many computer security problems that seem intractable. Safe password storage is not one of them. We can fix this.