3 ms·

Is it that unreasonable for them to want people to use FIPS approved algorithms? I mean all you're showing them is how fast the current implementations of the a

Is it that unreasonable for them to want people to use FIPS approved algorithms? I mean all you're showing them is how fast the current implementations of the algorithms are, and obviously being too fast isn't great for password hashing, but your benchmark doesn't in itself actually prove the security of bcrypt as a hash algorithm so I don't know why you would expect that to convince them. Maybe the real problem is that the FIPS standards are too conservative?

jnwatson 6y ago
I would say it is somewhat of a misuse of the standard. That a cryptographic hash makes an ok password function is somewhat accidental. If they had required PBKDF2 that would have made more sense. That at least confirms you used the pseudorandom function correctly.
TimTheTinker 6y ago
The real problem is that security decisions are being made by bureaucrats. Full stop. 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.
- CyanLite4 6y ago
  Are you saying the auditors are the bureaucracy or the FIPS standards approvers are the bureaucracy? All the auditors are saying is that you have to use a FIPS approved algorithm. The FIPS people have real cryptography experts who research this stuff on a daily basis that also help set the security standards for the entire U.S. government. The author is coming along here saying they are using something else that’s not approved by FIPS (for good reason I might add) and they’re mad the auditors won’t let them simply because “everyone else is using bcrypt”.
  - TimTheTinker 6y ago
    > Are you saying the auditors are the bureaucracy or the FIPS standards approvers are the bureaucracy? 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.
- dkarl 6y ago
  Bureaucrats track compliance. People who know security and bureaucracy (ideally) design the standards. Engineers are still responsible for building secure systems that happen to also check all the compliance boxes. 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.
  - TimTheTinker 6y ago
    Agreed, this is the unfortunate truth at present. Though by preventing hideous errors from falling through the cracks, compliance requirements also often prevent the best decisions from being made.
vlovich123 6y ago
Sha-2 isn’t appropriate as a password hashing algorithm so there’s something wrong with the compliance team and the engineers not correcting them that they need a KDF. Apparently NIST even calls out regular hash functions as being unsuitable for hashing passwords [1]. You’d need to use PBKDF2 although maybe this advice has been updated since? Maybe they were being recommended PBKDF2 because that too is more susceptible to GPU attacks? Really should be using scrypt rather than bcrypt anyway. 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-for-hashing-passwords-sha256-or-sha512 https://stackoverflow.com/questions/11624372/best-practice-f...
bostik 6y ago
> 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.
- jjav 6y ago
  > 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.

jnwatson 6y ago

I would say it is somewhat of a misuse of the standard. That a cryptographic hash makes an ok password function is somewhat accidental. If they had required PBKDF2 that would have made more sense. That at least confirms you used the pseudorandom function correctly.

TimTheTinker 6y ago

The real problem is that security decisions are being made by bureaucrats. Full stop. 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.

CyanLite4 6y ago
Are you saying the auditors are the bureaucracy or the FIPS standards approvers are the bureaucracy? All the auditors are saying is that you have to use a FIPS approved algorithm. The FIPS people have real cryptography experts who research this stuff on a daily basis that also help set the security standards for the entire U.S. government. The author is coming along here saying they are using something else that’s not approved by FIPS (for good reason I might add) and they’re mad the auditors won’t let them simply because “everyone else is using bcrypt”.
- TimTheTinker 6y ago
  > Are you saying the auditors are the bureaucracy or the FIPS standards approvers are the bureaucracy? 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.
dkarl 6y ago
Bureaucrats track compliance. People who know security and bureaucracy (ideally) design the standards. Engineers are still responsible for building secure systems that happen to also check all the compliance boxes. 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.
- TimTheTinker 6y ago
  Agreed, this is the unfortunate truth at present. Though by preventing hideous errors from falling through the cracks, compliance requirements also often prevent the best decisions from being made.

vlovich123 6y ago

Sha-2 isn’t appropriate as a password hashing algorithm so there’s something wrong with the compliance team and the engineers not correcting them that they need a KDF. Apparently NIST even calls out regular hash functions as being unsuitable for hashing passwords [1]. You’d need to use PBKDF2 although maybe this advice has been updated since? Maybe they were being recommended PBKDF2 because that too is more susceptible to GPU attacks? Really should be using scrypt rather than bcrypt anyway. 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-for-hashing-passwords-sha256-or-sha512 https://stackoverflow.com/questions/11624372/best-practice-f...

bostik 6y ago

> 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.

jjav 6y ago
> 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.