Do more to encourage keyed hashing for password validation

[agreinhold]

Organization:2

Type:Researcher

Document (63-3, 63A, 63B, or 63C): 63B

Reference (Include section and paragraph number): 5.1.1.1

Comment (Include rationale for comment): NIST should do more to encourage a transition to keyed hashes for storing password validation data in large or high value systems. For ethical, liability and likely legal reasons, organizations requesting passwords from users have a responsibility to protect this highly private information. Properly implemented, keyed hashes can make recovery of passwords from data breeches orders of magnitude more difficult than when unkeyed hashes are employed. I can think of no other measure so cost effective and practical that would do more to remedy inadequacies in cyber security, which have reached the level of national crisis.

The use of unkeyed hashes unfairly shifts much of the burden of protecting password validation data from system owners to individual users by asking the later to select ever more complex passwords, lest their accounts be easily compromised after a breach. Given that keyed hashing is a viable alternative that only requires users to avoid the most easily guessed passwords, continuing to place a strong password requirement on users is unnecessary and unreasonable. A huge amount of damage has already been done by recovery of account and password pairs from data breaches. Such password compromises can be completely prevented by the proper use of keyed hashes.

The NIST SP800-63B draft, in section 5.1.1.1, begins to address the issue when it says:

“Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks.”

In my opinion this is the most important recommendation in 63B regarding passwords, but it should be elaborated and strengthened.

Section 5.1.1.1. then suggests two methods for storing password validation data:

A [unkeyed hash]: “Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2” with at least 32 bit salt and 10,000 iterations.” 

B [keyed hash]: “A keyed hash function (e.g., HMAC), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.”

While method A is an improvement over the still common practice of using a single pass of a fast cryptographic hash to create stored password validation data, NIST should more forcefully encourage transition to the stronger keyed hashing approach (method B).

Unkeyed but salted hashing algorithms, have come to the end of their useful life for securing password validation data. The arms race between attackers and defenders has been won by the attackers. Attackers now have access to high performance general purpose graphics processing units (GPGPUs), not typically included in data center servers, and to botnets with hundreds of thousands, if not millions of processors. It is only a matter of time before massively parallel custom integrated circuits designed for Bitcoin mining are repurposed for password cracking. While NIST SP800-63 requires multi-factor authentication for higher AAL levels, when the password protection is weak, two-factor authentication effectively reduces to single factor.

Resource intensive key derivation functions still have uses in applications such as disk encryption, where KDF wait times to unlock secondary memory on the order of a second are acceptable, but computations that lengthy are too expensive for password validation in large multi-user systems. There is an economic cross over between resource intensive hashing and hardware security module-based keyed hashing. Even the most expensive HSM would cost less per password validated compared to a one second KDF requirement on a typical data center server. On the other hand, a ~10 millisecond computation requirement, such as 10,000 iteration PDKDF2, is not sufficient to stop attacks mounted with a 100,000 computer botnet.

While transitioning to keyed hashes can be costly and time consuming, the changes already mandated in the SP800-63B draft will require significant revamping of password validation software in typical installations, so the additional cost of incorporating keyed hashing might not be that great, with benefits far exceeding cost.

There are several ways NIST could incentivize keyed hashing for password validation.:

1. The best option would be for NIST to depreciate unkeyed hashing for large systems and propose a reasonable time table for its elimination, starting with new systems that serve a large number of general-public users.
2. If developing such a time table is beyond the scope of the present effort, NIST could still indicate that it expects to depreciate unkeyed hashes in the near future.
3. NIST could require different security parameters for systems using keyed vs unkeyed hashes. For example the 10,000 iteration requirement is probably too low for unkeyed hashes, while it is unnecessary, except as a backup, for keyed hashes. Also the suggestion that six character passwords are acceptable when randomly generated by the system (which is technically dubious for unkeyed hashes, especially for PINs) would make more sense if keyed hashing were used.

The cost of the keyed hash approach is arguably cheap insurance vs the cleanup and liability issues associated with database breaches. While the changeover to keyed hashing could be time consuming, that is all the more reason to at least signal the future now, as NSA has done for quantum resistant cryptography. Indicating that unkeyed hashing will be depreciated would give technical experts who want to do the right thing the ammunition they need to influence their organization’ s long-term budget planning.

Protecting the master secret A minimum size for the keyed hash master secret should be specified. For public-facing systems, an attacker can create their own account prior to recovering the password verification data. This would give them a known good password, along with its hash and salt from the breech. Together, these items can be used to mount an brute-force attack on the keyed hash function master secret. For more private systems, an attacker might use social engineering to gain a password, or find a user known to reuse passwords based on previous exploits against other systems. Accordingly, any keyed hash master secret should have strength appropriate for a symmetric cipher key, i.e. 128 bits, or 256 bits for a quantum computing planning horizon. The added cost of using a longer key is minuscule.

The master secret must never appear on the protected computer system, lest it be compromised along with the password validation data. If the master secret is transferred it must be encrypted, e.g. per NIST SP 800-38F “Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping.” Of course the key encryption key used with the key wrap must also never appear on the protected system.

Suggested Change: The iteration count for unkeyed hashing ought to be different then for keyed hashing or the use of an iterated hash for HSM based systems might be eliminated. [text tbd]

Public-facing systems with more than 500,000 users SHALL employ keyed hashing using a hardware security module approved at FIPS 140-2 or equivalent.

Systems that employ PINs for authentication SHALL use keyed hashing.

The keyed hashing master secret SHALL be at least 128 bits in length, with 256-bits preferred.

The keyed hashing master secret when present outside a hardware security module shall be wrapped in accordance with NIST SP 800-38F.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

[jimfenton]

The requirement for use of a keyed hash is a SHOULD because there are legacy systems for which it would be very difficult to implement a keyed hash and manage the secret securely. Note that if the key is breached as well, there is no benefit over a single hash.

The intent is to encourage both the use of a keyed hash with proper key management and the use of many rounds of a key derivation algorithm. The rationale is that this is "defense in depth": if the key is breached as well as the database, it still isn't trivial to attack the database.

While, other things being equal, use of a keyed hash along would be preferred over 10,000 rounds of key derivation, the normative language we are using does not have enough nuance to add color to that: phrases like REALLY SHOULD are not used.

There is no current basis for requiring a hashing secret that is longer than 112 bits (the shortest key size used in "approved cryptography") and we see no benefit of doing so here.

Thanks for your thoughts on this; we will continue to search for words to emphasize good behavior on the part of verifiers.