3 ms·

why would someone in 2024 reach for bcrypt for building a secure hash key?

by a-dub 2y ago

EasyMark 2y ago
okta has been around longer than a year and momentum keeps a lot of companies from changing anything until catastrophe strikes
- pquerna 2y ago
  per <https://trust.okta.com/security-advisories/okta-ad-ldap-delegated-authentication-username/ https://trust.okta.com/security-advisories/okta-ad-ldap-dele...> 2024-07-23 - Vulnerability introduced as part of a standard Okta release This issue is not an "okta is old" issue. this was new code written in 2024 that used a password hashing function from 1999 as a cache key.
  - crest 2y ago
    Bcrypt is still perfectly usable for its original purpose. They just picked/wrote a bad implementation that silently truncated inputs longer than the maximum input length. Would you also ask why they picked AES (a cipher from 1998) when the error was with the user (e.g. picking fixed/too short key)?
heliosyne 2y ago
Because bcrypt is still viable. Its cost factor is easily scaled to commodity performance, keeping the attack cost high. The main attack vector these days is GPU-based compute. There, SHA* algorithms are particularly weak because they can be so efficiently computed. Unlike SHA algorithms, bcrypt generates high memory contention, even on modern GPUs. Add in the constraint of broad support, low "honest use" cost, and maturity (extensive hostile cryptanalysis), bcrypt stays as one of the better choices even 25 year later. That said, bcrypt's main limitation is it has a low memory-size cost. There are some newer algorithms that improve on bcrypt by increasing the memory-size cost to more than is practical even for FPGA attacks. More importantly, bcrypt didn't actually fail here. The vulnerability happened because okta didn't use it correctly. All crypto is insecure if you use it wrong enough.
- a-dub 2y ago
  after all of the headaches in the late 90s/early 2000s with truncating password hash functions, i'm just a little surprised that this sort of thing would still be an issue. i understand performance concerns and design trade offs, but i would expect a secure hashing function in 2024 to do proper message scheduling and compression or return errors when truncations are happening. i suppose 90s culture is hip again these days, so maybe this does make sense?
mkj 2y ago
It seemed the best option I could find for a rp2040 microcontroller when I went looking recently? Perhaps not for okta...

why would someone in 2024 reach for bcrypt for building a secure hash key?

by a-dub 2y ago

why would someone in 2024 reach for bcrypt for building a secure hash key?

okta has been around longer than a year and momentum keeps a lot of companies from changing anything until catastrophe strikes

pquerna 2y ago
per <https://trust.okta.com/security-advisories/okta-ad-ldap-delegated-authentication-username/ https://trust.okta.com/security-advisories/okta-ad-ldap-dele...> 2024-07-23 - Vulnerability introduced as part of a standard Okta release This issue is not an "okta is old" issue. this was new code written in 2024 that used a password hashing function from 1999 as a cache key.
- crest 2y ago
  Bcrypt is still perfectly usable for its original purpose. They just picked/wrote a bad implementation that silently truncated inputs longer than the maximum input length. Would you also ask why they picked AES (a cipher from 1998) when the error was with the user (e.g. picking fixed/too short key)?

heliosyne 2y ago

Because bcrypt is still viable. Its cost factor is easily scaled to commodity performance, keeping the attack cost high. The main attack vector these days is GPU-based compute. There, SHA* algorithms are particularly weak because they can be so efficiently computed. Unlike SHA algorithms, bcrypt generates high memory contention, even on modern GPUs. Add in the constraint of broad support, low "honest use" cost, and maturity (extensive hostile cryptanalysis), bcrypt stays as one of the better choices even 25 year later. That said, bcrypt's main limitation is it has a low memory-size cost. There are some newer algorithms that improve on bcrypt by increasing the memory-size cost to more than is practical even for FPGA attacks. More importantly, bcrypt didn't actually fail here. The vulnerability happened because okta didn't use it correctly. All crypto is insecure if you use it wrong enough.

a-dub 2y ago
after all of the headaches in the late 90s/early 2000s with truncating password hash functions, i'm just a little surprised that this sort of thing would still be an issue. i understand performance concerns and design trade offs, but i would expect a secure hashing function in 2024 to do proper message scheduling and compression or return errors when truncations are happening. i suppose 90s culture is hip again these days, so maybe this does make sense?

mkj 2y ago

It seemed the best option I could find for a rp2040 microcontroller when I went looking recently? Perhaps not for okta...