Hot answers tagged

8

In many cases, 0x00 is treated as end of string. That is where the problem comes into play. So if I passed password\x00defgreallylongpassword into bcrypt, the password would be terminated after password due to the null byte. That is a very insecure password and can easily be found with a dictionary attack. No one types null bytes into a password field, ...


7

You are correct, Blowfish is a reversible cipher if you know the key. Bcrypt has three parameters it uses to hash a password: Salt Password Cost It derives a key using the salt, password and cost to encrypt the well known text "OrpheanBeholderScryDoubt" and not the password itself. So verification would be performing the encryption again on this string ...


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


4

Lucas Kauffman is correct that the more recent algorithms were either too new to be proven, or not available at all, when bcrypt was designed. But this immediately brings up the question of whether a replacement for bcrypt could profitably make use of these more recent algorithms. For password-hashing purposes, Blowfish has one great advantage over more ...


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


3

Bcrypt relies on the blowfish cipher, which is a reversible method of encryption. But bcrypt is not reversible. How is that possible? Or am I mistaken? What does bcrypt do on top of blowfish to make it irreversible? Using the psuedocode from the wikipedia article about bcrypt as an example: bcrypt(cost, salt, input) state ← EksBlowfishSetup(cost, ...


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



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