Timeline for Do salts have to be random, or just unique and unknown?
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 11, 2023 at 1:01 | comment | added | ManRow | @martinstoeckli And how many bits of "unpredictability" would you suggest? | |
| Sep 4, 2013 at 7:26 | comment | added | martinstoeckli | @MisterMelancholy - I updated my answer accordingly. | |
| Sep 4, 2013 at 7:25 | history | edited | martinstoeckli | CC BY-SA 3.0 |
To answer the updated question.
|
| Sep 4, 2013 at 6:53 | comment | added | user26547 | I've updated my question a number of times (and am done), and though it's asking the same basic principle, I'm now asking each person with an answer to consider revising their answer to make sure it's still on-topic to the question. Sorry for my indecisiveness, and thank you for your time and input. | |
| Sep 1, 2013 at 20:00 | comment | added | user26547 | @martinstoeckli Updated my question. And thanks for the discussion so far. | |
| Sep 1, 2013 at 19:47 | comment | added | user26547 | Then have them provide their password to change this field? Even so, using anything that the user can change as part of the salt will likely be a bad idea. However, IDs will never change, and if the password changes, their changing their password. I'm going to update my question and make it a little more in-depth with relevance to what we're discussing here. | |
| Sep 1, 2013 at 19:41 | comment | added | martinstoeckli | @MisterMelancholy - You cannot rehash the password when updating the email address. To create the new password-hash you need the email and the original password, but at this moment you know only the email and the hash of the original password. | |
| Sep 1, 2013 at 19:37 | comment | added | user26547 | Yeah. I should probably put that in my question so that it's more clear - sorry for the confusion. And that's simple; If a user wants to change their email, re-hash the password since the salt will be different and update both fields at the same time. If a database gets compromised, users changing their passwords would also change the salt, thus changing a potentially hashed version of the password that provides entropy because the original value is unknown, thus creating a new and random salt. | |
| Sep 1, 2013 at 19:32 | comment | added | martinstoeckli | @MisterMelancholy - Ok i understand now, you don't want to store the salt at all, and therefore want to derrive the salt completely from other parameters. There is one problem though, it will make it impossible to change the parameters afterwards. When the user wants to update the email and you used it as salt, you cannot recalculate the password-hash with the new email, because you do not know the original password then. You would have to store the old email as well, what makes it no better than storing a salt. | |
| Sep 1, 2013 at 19:24 | comment | added | user26547 | Sorry, I removed my comment because I basically asked the same thing on the answer by ilmari Karonen and you replied to it. Also, the whole point of asking this question is to avoid the need to store the salt in plain text in the database. There are functions for hashing passwords that to not append the salt to the password. I know there is a separate salt and pepper, but what's wrong with having them both be the same thing if possible? @martinstoeckli | |
| Sep 1, 2013 at 19:21 | comment | added | martinstoeckli | @MisterMelancholy - You already answered it well. The hash is used to make it impossible to retrieve the original password, so storing the password as salt in a retrievable form will undo the whole effort (you need it for verification). If you want to add a server side secret, a good method is, to encrypt the password-hash with a server side key, or to use a pepper. But don't mix up the two, let the salt be known (plaintext) and the server-side key be a secret. | |
| Sep 1, 2013 at 18:52 | comment | added | martinstoeckli | @MisterMelancholy - It doesn't matter, whether a user has the same id on another site, a rainbow-table with those salts would contain "all" passwords with all of the choosen salts, thus working for every site. About the email, you cannot presume that the emails are hidden from the public, hashes are made or the case, when the database is already stolen, so the email addresses will be known as well. Using the email as salt, maybe combined with other data and hashed, is not the worst thing you can do, but using a random independend salt is always better. | |
| Sep 1, 2013 at 17:31 | comment | added | user26547 | Salting with user ID would be unique for a single database. The chances of the same user having the same ID across 2 (or 3 or 4) websites is likely very low. If a hacker pre-computes a rainbow table with IDs 1-1000, the hash is vulnerable because you used a predictable salt, and is why I stated in my question that salting with the user ID alone is not a good idea. | |
| Sep 1, 2013 at 13:24 | comment | added | martinstoeckli | @IlmariKaronen - Just wrote a bit more clear what i meant (about the middle part), probably you didn't notice the edit. And of course key-stretching is a must today. | |
| Sep 1, 2013 at 13:22 | comment | added | Ilmari Karonen | Technically, as long as each salt is globally unique, their length doesn't matter. (And conversely, just making your salts longer doesn't help if they're not unique.) Salting doesn't really help much against brute-force attacks targeted against a single user (as the middle part of your answer would seem to suggest); for that, you want key stretching. | |
| Sep 1, 2013 at 13:16 | history | edited | martinstoeckli | CC BY-SA 3.0 |
deleted 107 characters in body
|
| Sep 1, 2013 at 12:34 | history | edited | martinstoeckli | CC BY-SA 3.0 |
added 5 characters in body
|
| Sep 1, 2013 at 12:01 | history | edited | martinstoeckli | CC BY-SA 3.0 |
Justification about salt thwarting brute-force attacks.
|
| Sep 1, 2013 at 10:59 | history | edited | martinstoeckli | CC BY-SA 3.0 |
added 96 characters in body
|
| Sep 1, 2013 at 10:51 | history | answered | martinstoeckli | CC BY-SA 3.0 |