Hot answers tagged

7

Introduction BCrypt is a password-based KDF (far from state-of-the-art, but better than PBKDF2, because BCrypt requires sizable RAM, which greatly increases the cost of hardware-accelerated password search). Bcrypt is based on the blockcipher Blowfish, with the initial processing of the password reminiscent of Blowfish's key preprocessing. Bruce Schneier's ...


6

It's called a key derivation function because that's what you'd typically use its output for — as a key for some other cryptographic algorithm. (Of course, you can also use the output of Bcrypt for other purposes, e.g. storing it in a database as a password hash, but that's really a secondary use case.) In general, key derivation functions (KDFs) ...


3

Is it bad to use this method to store passwords? Yes. It is bad. Why? It's bad because you're rolling your own crypto, which is generally considered a bad choice. It's bad because SHA-3 is slow in software (e.g. on servers and consumer PCs) and fast in hardware (e.g. FPGAs, ASICs) and hence attackers can relatively fast try out many passwords. So ...


2

So your idea is that the client does the work in calculating the slow hash $B(P)$, and proves that to the server by using a hash as an encryption key. It is definitely not a standard way to do things, and has some problems. In particular, any eavesdropped can trivially launch an offline dictionary attack on the password, so it is like your normal password ...


2

I know PBKDF2 is essentially "useless" against anyone with a GPU rig and I have read that bcrypt is "useless" to anyone with an FPGA setup. Neither is useless. Newer alternatives like scrypt and the eventual PHC winner make better use of the defenders' resources, but even a thousand iterations of PBKDF2 is useful, compared to doing nothing. If you ...


2

A password manager that produces 16-character passwords is sufficient for most cases. Users who go for 100-byte passwords are usually overly-paranoid, since the actual security benefit is outweighed by the inconvenience. Therefore, limiting a password to 72 characters, while in theory reducing the number of possible passwords, is still very reasonable. ...


1

While it is well known that hash1(hash2(x)) only serves to increase collisions, Collisions essentially do not matter at all for password hashing. You will only lose entropy to collisions if the input entropy is near the size of the hash output. And in that case you are well and truly out of the realm of what can be cracked for any popular hash function. ...


1

What is the likelihood of 2 bcrypt hashes colliding if they use the same work-factor and input? You're describing this: $\tau_1,\tau_2=\text{bcrypt}(pw,cost), \Pr[\tau_1=\tau_2]$. This means that the collision probability comes down to the length of the salt. bcrypt uses 128-bit salts. So you expect to find a collision after doing roughly $2^{64}$ ...


1

Hashing a password does not necessarily weakens the password. What is more important in this case is the collision resistance of the hash algorithm. As long as the collision resistance is given a hash values used is enough to get a high security.


1

I would feel perfectly safe with a 72 byte password. Computing a shorter hash of a longer password is not necessarily weakening your scheme. Passwords are typically not truly random and contain only human readable characters, so that for instance a password of 60 bytes may have an entropy of only 32 bytes. See https://en.wikipedia.org/wiki/Password_strength ...


1

I'm not sure about your specific system; this only addresses "can a key derived from the password make a good shared secret?" The most common password hashing functions are actually designed for exactly this purpose -- deriving a cryptographic key from a (weak) password. That's actually what PBKDF2 stands for: "password-based key derivation function #2" ...



Only top voted, non community-wiki answers of a minimum length are eligible