Replace bcrypt with SHA-512 password hashing

[pkarman]

Why: Must use FIPS approved password encryption strategy.

[amoose]

Just tagging do not merge until this is fully discussed and we cover the implications of this change. cc @jgrevich @mzia @typesend @jacobian @bandrzej @paultag

[paultag]

Yet another case where we get to choose between paperwork compliance and actual security, leading me to think the attack vector of most of government is just paperwork audits and not keeping attackers out and data secure.

The problem is, SHA hashing algorithms are designed to be fast, which is great when it comes to ensuring integrity of messages, but storing passwords is a different game. You want your hashing to be slow. You want to make it hard for someone to break the password hash. bcrypt is inarguably the right thing to go to production with, and compromising on security to put a "FIPS 140-2 approved!™" sticker on it is tragic.

I'd say in any normal environment that we should get the industry standard and widely reviewed bcrypt approved, but NIST have turned out to be unwilling or able to add secure widely deployed industry standard algorithms to their sanctioned lists, putting the entire federal government in this position.

We can't use common and known good algorithms because the processes involved are slow and antiquated, based on processes that were used to validate hardware based crypto. Just like our procurement policies are based on buying boots for solders, and bolts for ships, and not software.

An alternative to bcrypt in the lists of algorithms is PBKDF2, a "FIPS 140-2 approved!™" algorithm similar enough where it might be worth using rather then mucking with a salted SHA. I don't know that it's as widely used or deployed, but hey, NIST says it's totally fine, so at least no one will get in trouble if it turns out to have some subtle flaw.

USA #1.

[paultag]

cc @alex

[jacobian]

Ugh, is there any way we can avoid doing this? bcrypt (or scrypt, or argon2) are industry standards for a reason: they're explicitly designed for password storage. SHA-512 isn't. It may be OK (there's some semi-convincing math here), but I am not a cryptographer and I don't particularly trust doing something that runs against a widely-acceptable best-practice without really strong understanding of what's going on.

[alex]

Assuming SHA512 here is just the vanilla hash function, it is unacceptable for password storage.

PBKDF2-HMAC-SHA512 is acceptable (with high enough iteration count), and generally what I recommend people who care about FIPS use. But it is my professional opinion that it's still not as good as bcrypt or scrypt.

If it is within your power to do so, I'd find a way to get a waiver, this is a clear case of compliance interfering with actual security.

[pkarman]

We can use PBKDF2 but will need to write an adapter. heartcombo/devise-encryptable#11 e.g. is incomplete.

[jacobian]

I agree with @alex that PBKDF2-HMAC-SHA512 is acceptable -- but honestly, only barely. I would strongly suggest seeking a waiver here, and falling back to PBKDF2-HMAC-SHA512 as a last resort.

[pkarman]

heartcombo/devise-encryptable#12

[bandrzej]

@paultag

Welcome to government ;-) Some of the things done sometimes make no sense - fully agree on that point, especially when the standards are 5+ years old. Industry can move to whatever they wish, while here we have to answer to a slew of policies and regulations.

OMB Circular 130A (now revised) drives all things downward, which makes NIST the official federal government standards and the FIPS it produces enforced by FISMA annuals. We use to be able to waive FIPS years ago, but FISMA explicitly prevents that for FISMA packages.

As Federal IT information security and as an assessor, this statement tells me what I have to do first as "proper safeguards":

c) Implement security policies issued by OMB, as well as requirements issued by the Department of Commerce, the Department of Homeland Security (DHS), the General Services Administration (GSA), and the Office of Personnel Management (OPM). This includes applying the standards and guidelines contained in the NIST FIPS, NIST SPs (e.g., 800 series guidelines), and where appropriate and directed by OMB, NIST Interagency or Internal Reports (NISTIRs).

[pkarman]

see #519

[bandrzej]

NIST SP 800-132 calls out using PBKDF2, with HMAC, and then "any approved hash function" from NIST. Several of the FIPS 140-2 approved modules support running PBKDF2 in FIPS mode as the Password-Based Key Derivation mechanism.

Industry, however, is very clear of updated settings, still meeting NIST:

• use a (FIPS-approved) strong random number generator to create a salt of 16 bytes or longer
• use HMAC-SHA-256 as the core hash for PBKDF2 (realize that National Securiyt Systems use HMAC-SHA-512...and some industry are moving to this)
• Perform 20,000 iterations or more
• Take 32 bytes (256 bits) of output from PBKDF2 as final password hash
• Store iteration count, the salt, and the final hash in your password database

SOURCES:
https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/ (updated Aug 2016)
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

[rmhrisk]

It is unacceptable to use a flat hash for passwords, especially in 2016.

When FIPS 140 is a requirement with my consulting customers my recommendations was normally:

• PBDBKF2 with HMAC-SHA-512,
• Using a unique 64-bit salt for each password,
• 20,000 iterations or more.

While Agron2 would be a more appropriate choice on the basis of security, the above is a reasonable position to take given the restrictions you are subject to.

[pkarman]

PBKDF2 implemented in #519