Timeline for How to store salt?
Current License: CC BY-SA 4.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 30, 2020 at 3:58 | answer | added | user243454 | timeline score: 1 | |
| S Jun 14, 2019 at 22:10 | history | suggested | kc2001 | CC BY-SA 4.0 |
Improved grammar, wording.
|
| Jun 14, 2019 at 20:03 | review | Suggested edits | |||
| S Jun 14, 2019 at 22:10 | |||||
| Jan 11, 2019 at 3:09 | comment | added | Nathan Basanese | // , selfreliantschool.com/how-and-why-to-store-salt | |
| Jan 11, 2019 at 2:56 | comment | added | Nathan Basanese | // , What containers are you using? Are you using Iodized or non-Iodized? You could wind up with a poisoned salt, so avoid metal containers, because salt leaches metals and/or elements out of the metal. Well regardless, ya don't need to use a food-saver, because salt will not go rancid even if it is exposed to air. For large amounts, I recommend scooping the salt into heavy duty gallon-sized plastic bags. Then you can put the bags in a food grade 5-gallon bucket. For all of you preppers out there, it can be used as a bartering item in time of need. | |
| S Dec 2, 2017 at 8:40 | history | suggested | user164892 | CC BY-SA 3.0 |
improved punctuation and formatting
|
| Dec 2, 2017 at 5:21 | review | Suggested edits | |||
| S Dec 2, 2017 at 8:40 | |||||
| Feb 4, 2014 at 18:36 | comment | added | cpast | @matejkramny That's exactly equivalent to just using the username as the salt, and bad for the same reason: if the attacker knows a username they want to break into, they can just precompute the hashes for that username. Including the password in the salt doesn't change a thing. To stop them from precomputing hashes, the salt should be stored in the database, so they can't get it before getting the hashes themselves, which means they need a lot of time to break the hashes after they compromise the database, which gives you a chance to change passwords before they get access. | |
| Jul 2, 2013 at 20:57 | comment | added | code ninja |
Why would you store a salt? If you could compute it using the credentials some way.. such as $salt = base64_encode($username.$password); then you don't have to store it, and if the username and password is correct, it will match the salt too.
|
|
| Jul 31, 2012 at 2:32 | vote | accept | George | ||
| Jul 31, 2012 at 2:32 | vote | accept | George | ||
| Jul 31, 2012 at 2:32 | |||||
| Jul 31, 2012 at 2:32 | vote | accept | George | ||
| Jul 31, 2012 at 2:32 | |||||
| Jul 29, 2012 at 15:00 | comment | added | Polynomial | @JonasWielicki Yup. Some even store in plaintext. See Plaintext Offenders for examples. Another large company, not listed there, is Tesco. | |
| Jul 21, 2012 at 11:57 | comment | added | Jonas Schäfer | +1 for using salts, which is more than big websites seem to do usually. | |
| Jul 21, 2012 at 8:19 | history | edited | Andrei Botalov |
edited tags
|
|
| Jul 20, 2012 at 22:57 | comment | added | Polynomial | @SilverViper That's a bad idea. It gives an attacker the salt, allowing them to compute a rainbow table ahead of time, before overtly breaching your database. In such a situation, the attacker can log in immediately after the attack and you have no time to react. See my answer for a more detailed explanation of this problem. | |
| Jul 20, 2012 at 22:55 | comment | added | Polynomial | @X-Zero There should be no difference at all, and it makes things more awkward when using an adaptive KDF. | |
| Jul 20, 2012 at 21:11 | history | edited | Rory Alsop♦ | CC BY-SA 3.0 |
deleted 74 characters in body
|
| Jul 20, 2012 at 20:20 | comment | added | SilverViper | What about $pwd=hash(hash($password) + username)? | |
| Jul 20, 2012 at 19:41 | answer | added | Andrew Smith | timeline score: -7 | |
| Jul 20, 2012 at 17:35 | answer | added | Tgr | timeline score: 18 | |
| Jul 20, 2012 at 16:07 | comment | added | Clockwork-Muse | Forgive my ignorance, but is it really necessary to hash the password before adding the salt? If you have a good hashing algorithm, it shouldn't make a difference, right? | |
| Jul 20, 2012 at 16:06 | comment | added | Earlz | Heh I did not know there was a name for that, @Polynomial. And I'm pretty sure my database is secure, but just in case it's not. (MongoDB). I figure it can't hurt and it's not that hard to implement | |
| Jul 20, 2012 at 15:58 | answer | added | user7610 | timeline score: 6 | |
| Jul 20, 2012 at 15:58 | comment | added | Polynomial | @Earlz The second salt is called a pepper, which protects you from attackers that only have access to the database. It's useful, but since you're using parameterised queries (you are using them, right?) SQL injection isn't a problem, so that model of attacker is much less likely. | |
| Jul 20, 2012 at 15:54 | comment | added | Earlz | @Polynomial Well, something to consider. I have an authentication system which uses two salts for each password, one randomly generated and stored in the database, and one which is global to the website and stored in the code. My goal was to make it so that even if the database got leaked, it's still not possible to forge a login cookie or brute force the password. | |
| Jul 20, 2012 at 15:34 | comment | added | Polynomial | @Earlz That's not the purpose of a salt, and it's nearly impossible to keep salts hidden anyway! | |
| Jul 20, 2012 at 14:58 | comment | added | Earlz | Well, one thing to consider with salts. If you do manage to keep them secret, and your password hashes get leaked, it becomes completely impossible(probably) to recover a password, even with 10,000 graphics cards brute forcing it | |
| Jul 20, 2012 at 14:23 | answer | added | Polynomial | timeline score: 877 | |
| Jul 20, 2012 at 10:35 | history | tweeted | twitter.com/#!/StackSecurity/status/226264121610493952 | ||
| Jul 20, 2012 at 7:38 | answer | added | lxgr | timeline score: 47 | |
| Jul 20, 2012 at 7:37 | answer | added | Jacco | timeline score: 102 | |
| Jul 20, 2012 at 6:28 | history | asked | George | CC BY-SA 3.0 |