Maybe the real problem is that the FIPS standards are too conservative?
Quoting a professional cryptographer: FIPS compliance means that your code/system is sufficiently mediocre.
Conservative would be one thing. Stubbornly out of date would be another.
Indeed. Also often impractical.
A way to solve this is to support both a regular mode of operation and a FIPS mode of operation. I've worked on multiple enterprise products at different companies that take this approach. The full-on FIPS compliant mode is there to check all the boxes for customers who need that for their auditors. Even withing the set of those customers, a majority don't actually run the product in FIPS mode because it's too limited.
All that being said, using sha2 isn’t necessarily “wrong” if you can force your users to use longer passwords. My understanding (could be wrong - I’m not a security algorithms expert) is that all these “hard” hashing algorithms are trying to provide guarantees even if your user has poor security hygiene. If you can force your user to use a randomly generated 20 digit password then you can significantly reduce your server load and reduce latency by using a faster hashing algorithm.
[1] https://stackoverflow.com/questions/11624372/best-practice-f...
Bureaucracy invariably requires compliance, and only compliance. Some problems can be cast in terms of compliance and thus solved in a bureaucracy, but security is not and never will be one them.
Both.
> All the auditors are saying is that you have to use a FIPS approved algorithm.
... which is a problem, because FIPS approved doesn’t imply secure.
Bcrypt is a better password hashing algorithm than any FIPS-approved algorithm at this time. Don’t agree with me? Read up on it. I’m not necessarily recommending it though - there are others that may be even better, depending on the circumstance.
> they are using something else that’s not approved by FIPS (for good reason I might add)
What reason? Is there an expert cryptographer’s opinion or any expert cracking reports you can reference? Just because a group of experts decided a certain list of algos were “approved” several years ago doesn’t mean that newer algos designed or popularized since then are less secure.
Authority alone doesn’t confer reality or truth.
And unlike compliance, security is a process, not a destination.
Compliance is mostly intended to prevent really hideous errors from falling through the cracks. Nobody believes that you can't build a compliant, insecure system, or that you can't build a secure, non-compliant system.
Though by preventing hideous errors from falling through the cracks, compliance requirements also often prevent the best decisions from being made.
If they had required PBKDF2 that would have made more sense. That at least confirms you used the pseudorandom function correctly.