5 ms·
Hashing with an insecure algorithm and without good salting isn't much better that not hashing at all though.
by t3nary 10y ago
Hashing with an insecure algorithm and without good salting isn't much better that not hashing at all though.
- dzhiurgis 10y agoHow do you store salt?
- CiPHPerCoder 10y agoThat question should never even need to be asked. The library you're using should take care of that for you. In PHP: $storeMe = password_hash($plaintext, PASSWORD_DEFAULT); if (password_verify($plaintext, $storeMe)) { // Logged in } The detail is totally abstracted away. All sane password hashing libraries offer this API. See: https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016 https://paragonie.com/blog/2016/02/how-safely-store-password... EDIT - CANNOT REPLY: > One major failure of this article: > > You should generate a random salt for each user and store it alongside the user > record in the DB. No, you shouldn't. Your library should do that for you, and store it as a single string that's opaque to the developer. > I completely disagree. This implies that my DB ORM handles password stuff, > which doesn't make sense. See the passlib section: https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#python https://paragonie.com/blog/2016/02/how-safely-store-password...
- tamana 10y agoBut then you are using php so you already lost.
- CiPHPerCoder 10y agoIf there was any truth at all in that claim, you should be able to compromise paragonie.com right now simply for it running PHP. Otherwise, that claim is false.
- jjawssd 10y agoOne major failure of this article: You should generate a random salt for each user and store it alongside the user record in the DB.
- dchest 10y agoHow is this a failure? That's correct. (If your password hashing library doesn't handle this automatically, of course. But it does the same internally.)
- jjawssd 10y agoIs it normal for password hashing libraries to save salts to a database?
- dchest 10y agoYes, they usually produce a string that looks something like "salt||hash". (Salt is a non-secret value.) This result of bcrypt: $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy |/ \| \____________________/\_____________________________/ | | salt hash | cost | algorithm, version You store this string in the database.
- zo1 10y agoThe big thing about this, is that it is perfectly "OK" to store both the algorithm, cost, and salt alongside the hash. Most people seem to think, and myself included when I was new-to-it, that storing all those things together would compromise the security. The point of the hash is that it is impossible (almost) to get to the hash without the user's password, and there is no way to get to the password with the entire string you posted.
- DigitalJack 10y agoI'm naive about these things, but I was under the impression that salt just thwarted pre-computed hash tables? I guess should be "just" in quotes. So somebody with resources and motive could still brute-force that string. It seems that storing the salt somewhere else would add a comparable amount of security as the salt itself. It seems prudent along the lines of "don't put all your eggs in one basket."
- jjawssd 10y ago> No, you shouldn't. Your library should do that for you, and store it as a single string that's opaque to the developer. I completely disagree. This implies that my DB ORM handles password stuff, which doesn't make sense. Python 3 example: Syntax: hashlib.pbkdf2_hmac(hash_name, password, salt, iterations, dklen=None) Example: >>> dk = hashlib.pbkdf2_hmac('sha256', b'password', b'salt', 100000) >>> binascii.hexlify(dk) b'0394a2ede332c9a13eb82e9b24631604c31df978b4e2f0fbd2c549944f9d79a5' Extremely simple and safe to use. Trivial to store and save/retrieve the salt from DB.
- peeters 10y agoI'm not too familiar with this library, but on inspection this approach seems to have a couple of drawbacks that libraries like bcrypt solve for you: 1) You need to store the salt alongside the password. 2) If you want to futureproof the stretching factor (e.g. change from 100000 to 1000000), you need to store that alongside the password hash as well. 3) If you want to futureproof the hashing algorithm, you need to store that alongside the password hash. The value of the *crypt solutions is that they store the input parameters as part of the stored secret. So you can make adjustments later on without invalidating existing stored passwords, or having to resort to annoying "double-hashes" to migrate to a new approach. I don't understand your comment about the ORM needing to handle passwords. It's a simple fetch of a field from the DB, which you then pass as an input to your password validator. How is that any harder than fetching a salt and a hash and passing those to your validator?
- jjawssd 10y agoI did not realize that the hash and salt are concatenated
- deleted 10y ago[deleted]
- dchest 10y agoNope, it is much better for those who use passwords with good entropy.