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.
"Why Python's bcrypt implementation is unsafe for Password Hashing"
byhemechi•2h ago
mikehall314•2h ago
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•2h ago
flysand7•2h ago
3eb7988a1663•1h ago
embedding-shape•1h ago
byhemechi•2h ago
anonym29•49m ago
There are far fewer possible combinations of any three emojis than there are any 72 ASCII characters.
This is x^3 vs y^72, where X is the total number of distinct emojs and Y is the total number of distinct ASCII characters.
24 bytes of data is not 24 bytes of entropy if there are only a couple thousand different possible inputs to produce all of the possible 24 byte sequences produced by those inputs.
For simplicity: picture having only two possible input buttons. Each one produces 1000 bytes of random-looking data, but each one always produces the exact same 1000-byte sequence, respectively. You have a maximum password of 1 button press. The "password" may contain 1000 bytes, but you only have one bit of entropy, because the attacker doesn't need to correctly guess all 1000 bytes, they only need to correctly guess which of the two buttons you pressed.
cwbriscoe•2h ago
stavros•2h ago
zetanor•1h ago
enamya•1h ago