New answers tagged


For a login function, you should aim to get the hashing process to take around a second. If you take this post as a guide, 1170ms requires around 8,192 iterations of bcrypt (cost of 13). This means that your iterations add around 13 bits of effective entropy. If you have only 31 bits of entropy in a secret, hashed value, then this bcrypt configuration ...


There isn't a magic line beyond which hashing is useless. Rather, as you reduce the entropy of the input, the output becomes easier to guess. In this mail provider's case, they can add entropy using the salt. The larger the salt, the more entropy it will add.


Not just to keep an old thread alive but some people might have missed a important part of the long story behind this... It's been about an well known infamous and persistent bug when using /dev/urandom from Java versions 1.4 to versions 1.7. See the links below : ...


This might get better responses in or, but I think I can give you the gist of it. If we step away from words and take a look at some numbers it might help to illustrate. Take for example a four-digit code for a lock. There are 10 possible digits (0-9) and four spaces where they can be entered, so there are 10 ...


"openssl des3" is really "openssl enc -des3". The password-based key derivation is a custom, undocumented scheme which, as far as password-based key derivation schemes go, is quite weak; see this answer (especially at the end) for some details. Basically, this is equivalent to hashing the password with a couple of MD5 invocations. What matters for passwords ...


DES3 uses a maximum key size of 168 bits, so if you must use DES3 then go for the maximum key size. Since you're not memorizing the key yourself you should generate the key from a CPRNG. If you have the option you should consider AES which can have larger key sizes.

Top 50 recent answers are included