22 ms·
You can add the configurable slowness factor to any secure hash. Just use salts but leave out k bits from each when storing them. The more bits you leave out, t
by praptak 15y ago
You can add the configurable slowness factor to any secure hash. Just use salts but leave out k bits from each when storing them. The more bits you leave out, the more work it takes to verify a password as the verification procedure needs to brute-force the missing k bits.
- dchest 15y agoYou can also write a new cipher, discover a new key derivation function, and invent a new hash function. But that's not the point. Use bcrypt or scrypt.
- praptak 15y agoAny analogy between using a standard technique with a standard hash and going for DYI cryptography is a bit stretched.
- dchest 15y agoReally? You just described a KDF, and advised people to use it without providing any references to implementations. "Just leave out k bits of salt and brute-force it" -- do you really expect non-cryptographers to be able to correctly implement this algorithm? If you insist on using hashes, at least you could tell people to use PBKDF2 to turn a standard hash into KDF.
- llambda 15y agoEven so this doesn't account for another advantage of bcrypt: its "de-optimized" key scheduler, which adds to the difficulty of cracking the hash.
- cperciva 15y agoThe key scheduler in bcrypt is a red herring. I don't know what was going through their minds when they wrote that. They could have used a larger number of iterations and gotten the same result. The only reason why bcrypt is better than PBKDF2 is that blowfish needs a large circuit to compute.
- icebraining 15y agoIf you leave out bits, any password whose hash matches the rest will work, even if it doesn't match the 'lost bits' (since your login server won't be able to verify that, obviously). The only thing you've accomplished is to make the cracker's life easier.
- praptak 15y agoYou don't leave out bits from the hash but from the salt. The hash is stored whole and (obviously) needs to match whole.