Why Bcrypt Can Be Unsafe for Password Hashing?

https://blog.enamya.me/posts/bcrypt-limitation

by enamya • 9 months ago

14 23 9 months ago

blog.enamya.me

byhemechi2• 8 months ago

Does this really need yet another blog post? 72 characters is more than enough to be resistant to brute-force attacks, as demonstrated by thousands of data breaches containing bcrypt hashes that remain uncracked (excluding the obvious top 1k passwords/ credential stuffing). In my personal opinion calling it "unsafe" is just fear mongering, especially in conjunction with a recommendation of using Argon2 which is comparatively very new and is probably safe - but once again, does not have the proven record that bcrypt does.

mikehall314• 8 months ago

I agree 72 characters is plenty for most circumstances. However, as the blog points out, this is a byte limit not a character limit.

Some of the family emoji can be > 20 bytes. Some of the profession emoji can be > 17 bytes. If people are using emoji in their passwords, we could quite quickly run out of bytes.

I think it’s a limitation worth being aware of, even if “unsafe” is perhaps overstating it.

testdelacc1• 8 months ago

Does anyone actually use emoji as a password.

byhemechi2• 8 months ago

I still don't see how that's an issue, yes a password using a series of ridiculously complicated family emoji will be truncated but the actual bytes still provide entropy, just because the data doesn't use pixels when rendered doesn't mean it doesn't increase the search space

cwbriscoe• 8 months ago

You could always pre-hash the password with sha256 or something similar to guarantee you won't go over the 72 byte limit.

zetanor• 8 months ago

The hash is 24 bytes. Even without an input character limit, you're likely to find tons of valid aliases for your 1000-character password within the 72-byte password space.

enamya2• 8 months ago

Well, if you limit the discussion to passwords, you're right, maybe no need to worry especially if using randomly generated ones (like ones from password managers), but if the algorithm is used to check some "composed" credentials (like what happened with Okta last year) then maybe it's worth worrying about, no ?

K0IN• 8 months ago

I don't find this too concerning but libraries should document this and maybe even raise exceptions on data longer than 72 bytes, failing silently is the worst behaviour.

basilikum• 8 months ago

bcrypt is from 1999.

It's really sad that the state of the art from 25 years ago is still ahead of common practice today and you can be lucky to find it in systems today. Most systems still use general purpose cryptography hash functions for password storage. Those are explicitly designed with designed goals that go exactly contrary to the goals of password storage. For general purpose cryptographic hash functions being fast and very low in resource consumption and requirements is a feature. That is the exact opposite of what you want for password hashing. You want something that is much slower to have a higher work factor for an attacker and requires a significant amount of memory with pseudo random access for computation so you cannot easily implement it cheaply in hardware and cannot trivially parallelize many operations on the same piece of hardware.

PBKDF2 wich simply runs the same general purpose hash function for multiple rounds on the salted password only helps with the work factor but fails in everything else. Yet it's considered an acceptable password hashing function and probably even above average security.

We should be well beyond the usage of password for authentication and only using public key based systems for remote authentication. Instead we're using an extremely poor authentication mechanism for humans – one which is a security anti feature and the root of a huge portion of all successful attacks – and we're not even at the point of securing its secrets with long outdated security from the last millennium.

Please just use argon2 or yescrypt or scrypt. They are actually made for password hashing and use modern cryptography not from the year when Matrix was released.

TZubiri• 8 months ago

Alternate title:

"Why Python's bcrypt implementation is unsafe for Password Hashing"

enamya2• 8 months ago

*used to be unsafe just to note, other implementations have the same design (silent and truncate), I've recently found out that htpasswd from Apache HTTP server has the same silent behavior

Why Bcrypt Can Be Unsafe for Password Hashing?

Related Stories