Talk:Salt (cryptography)

message: Why is it ok for a salt not to be kept secret? —Anon.
:Because the secret is the password; even if one knows the salt, one would need to compute the hash for all possible passwords- knowing the salt simply reduces the problem from finding the hashes of all possible passwords multiplied against all possible salts, to all posssible passwords, which is the usual number. --maru  (talk) contribs 01:31, 22 March 2006 (UTC)
replies: text: But that seems like a huge help, doesn't it? I mean, if the salt was kept secret, the search space would be a lot larger... Or am I missing something? If you know the salt for a specific user, and you're trying to do a dictionary attack against just that password, the salt is not delaying you much. I understand that large scale attacks against all users are delayed, though. 201.216.245.25 (talk) 15:29, 14 December 2009 (UTC)
replies: text: Well, you should keep the hash secret in the first place. If the hash is leaked, chances are salts will be leaked as well, unless you use some weird split database system. That is why there is little point in keeping salts secret. If you want to make it harder to do a dictionary attack, you can use more iterations and something like bCrypt but this will cost you a lot of resources as well (the more resources you sacrifice, the more work for the attacker in theory). Xhunterx (talk) 17:28, 2 January 2017 (UTC)

text: The Password Statistics section of this article: Blogs.forbes.com: Discussing Gawker’s Breach With Founder Nick Denton was written only two days after the breach and says that people had already discovered 400,000 out of 1.3 million passwords!  Some of that was due to using an older hash algorithm, but I think a significant number could have been discovered by looking at the frequency of various hashes and matching the most common password hashes against the worst (most common) passwords: sequences of numbers starting with 1 and the word "password".  I'd be willing to bet that most of the people using the worst passwords also use the same password for every site, making those few easily-compromised accounts even more valuable to hackers.  Even a few bits of plaintext user-specific salt would prevent what I'd call a popularity-of-bad-passwords attack.--GlenPeterson (talk) 13:48, 29 December 2010 (UTC)
thread_title:  Secrecy 

message: Is a Known-plaintext_attack effective against hash functions like SHA-256?  If so, there is a balancing act where a longer known salt weakens the cryptography, but a shorter salt still prevents identifying obviously-similar passwords (see my "popularity-of-bad-passwords attack" comment above).  The "known-plaintext" article says that "modern ciphers such as Advanced Encryption Standard are not susceptible to known-plaintext attacks" but does not mention SHA.  I'm not sure I fully understand the Preimage attack article, but I think it means that hash functions are designed to resist this form of attack, but better hashing functions are better in this regard.  Does anyone know about this?--GlenPeterson (talk) 13:48, 29 December 2010 (UTC)
replies: text: By definition, known plain-text does nothing for hashes, as hashes (not talking about MAC) do not use passwords. If you have the plain-text for a hash, you don't need any cracking. Known-Plaintext Attack only apply to encryption and possibly to very bad MACs. Xhunterx (talk) 17:38, 2 January 2017 (UTC)
thread_title:  Length of Plaintext Salt vs. Known-Plaintext Attack 

message: :Not sure if this is the place to state this or not and if not please remove it. I have a note about the following link "Storing Passwords - done right!" "imagine a cracker gaining system access through eventual OS or server software errors, and being able to read the user database."
:If a cracker has gained access to your database it does not matter if passwords are encrypted or not because he can do all the damage he needs right there. example: He is in your login table and you have a md5 hash for a password, he inserts his own in place and bam that user no longer has access but the cracker does. Just keep that in mind before going to great extents to secure data that at the point you have been hacked is insecure regardless of what methods of cryptography you have used.
''
I moved the addition by 69.173.174.235 to here, as it doesn't belong in the article. Strad 17:47, 20 June 2006 (UTC)
replies: text: It seems like you're blurring the distinction between read and write access to the user database, which are obviously different levels of compromise on many systems. 67.185.169.54 06:49, 3 March 2007 (UTC)
replies: text: True, but this is beyond the scope of this talkpage. ---J.S  (T/C/WRE) 16:00, 4 May 2007 (UTC)
thread_title:  Moved from talk page 

message: The article currently has three external links.  Of these, one ("Morris, Robert; Thompson, Ken (1978-04-03). Password Security: A Case History") is excellent: it is both of historical value and is still relevant.  The remaining two ("Wille, Christoph (2004-01-05). "Storing Passwords - done right!" and "Primer on Unix password structure") are questionable: they fail to mention key strengthening - its importance (it is absolutely required for password hashing truly "done right"!) and its use by Unix password hashes (the specific "Primer" mentions "MD5", but fails to mention that the actual algorithm is higher-level and is based on 1000 iterations of MD5).  Better "external links" for these topics would be desirable, or at least the drawbacks of these two need to be mentioned right next to the links - as in: " (fails to mention the need for key strengthening)" (and "use of" on the other link). --Solardiz (talk) 21:23, 12 January 2011 (UTC)
thread_title:  References 

message: Correct me if I am wrong but salt does not make brute force attack slower as it would go over all possible values regardless of any assumptions, unlike dictionary attack does (dictionary attack assumes user would not use some text patterns).
Mike2learn (talk) 11:49, 10 May 2011 (UTC)
replies: text: Using a salt may indeed make brute force cracking slower In order to crack the password given the salt and the hash, you need to concatenate the salt to your candidate password, then hash the concatenated result. Hashing the concatenated result will take longer than hashing the candidate password, which is what would be done if there were no salt. Assume for example that with our hash algorithm, if it takes n seconds to hash a message of size m, then it takes 2*n seconds to hash a message of size 2*m (linear time in the length of the message). Consider using a salt that is much larger than the typical password size, e.g. 1000 times larger. Then brute forcing will take approximately 1000 times longer than it would without salting. Authentication would also take 1000 times longer, but for a single sign-in this may be completely acceptable (also note it doesn't have to be 1000). --Thedatamatrix (talk) 00:46, 4 August 2013 (UTC)

text: That statement about slower cracking contains the restriction "(but not in the case of cracking just one password)" and the paragraph goes on to explain why. The point is that without salt, you can attack all hashes at the same time, without an increase in runtime. With salt, this is not possible and you can only simultaneously attack passwords that have the same salt (which is also why I think the recommendation to choose salts randomly is nonsense - random choice unnecessarily increases the chance of collisions, i.e. 2 or more identical salts). Even with salt (unless it is of huge size, like Thedatamatrix suggested), an attack on any single particular password is not slowed down, you just lose the ability to crack multiple passwords simultaneously. If it is unclear how simultaneous attacks against unsalted hashes would work, here is an explanation: Read all hashes you want to crack into RAM (not a problem for typical attack scenarios, otherwise just buy more RAM), inserting them into a data structure with fast lookup (hash table, balanced tree, etc.). The data structure only needs to be able to answer the question "do you contain hash X?", ideally in O(1) time. Then start cracking by hashing the first password of your password search space, look up the hash in your data structure, save the password in case of a hit, otherwise repeat with the next password. You will find all passwords contained in your search space, no matter how many hashes you loaded into your data structure. Many data structures don't have O(1) access time, but O(log(n)) is still fast enough and is achieved by most data structures optimized for fast access (with O(log(n)) your runtime does increase with larger number of hashes, but only slightly because the runtime is still dominated by the calculation of hashes, particularly if multiple rounds are used, which you do with any decent password hashing scheme like PBKDF2). With salts, you effectively create many distinct password spaces, preventing this kind of attack. Catskineater (talk) 14:43, 21 October 2015 (UTC)
thread_title:  Salts also make .. brute-force attacks for cracking large number of passwords much slower ? 

message: This whole article needs help, and here's one example -- for UNIX the actual password was moved to a file only privileged accounts could read, such as /etc/shadow on Solaris and /etc/security/passwd on AIX. I'm not sure when this was started, but I know that Solaris 2.6 was doing it and I think Solaris 2.5 was as well. And Solaris 2.6 came out over a decade ago!! That's a lot of history to be overlooking!!  Argel1200 (talk) 18:58, 11 May 2011 (UTC)
thread_title:  UNIX 

message: I like the  function examples on the Rainbow table page. This page should have such explicit examples. IOLJeff (talk) 18:18, 13 September 2011 (UTC)
thread_title:  Detailed examples please. 

message: Someone who's good at making .png's quickly should consider making an illustration for this page. It could help visualize how and when salts are added to passwords, and the effect they have on the hashes. This seems to be one of those concepts in which a picture can say a thousand words.  — Preceding unsigned comment added by Exercisephys (talk • contribs) 22:59, 22 May 2012 (UTC)
thread_title:  Image? 

message: I don't understand crypto so I'm not the right person to edit it, but the first sentence make no sense and is not gramatically correct.  Very confusing. Byates5637 (talk) 21:24, 23 May 2012 (UTC)
thread_title: First sentence makes no sense

message: In the "Benefits" section, it says: "Unsalted passwords chosen by humans tend to be vulnerable to dictionary attacks since they have to be both short and meaningful enough to be memorized."
Salted passwords are NOT less vulnerable to a dictionary attack unless the salt is hidden. If you know the salt and the hash, a dictionary attack will terminate in exactly the same number of iterations as it would if there were no salt. The only thing that would take longer is having to hash a larger string each time (the candidate password + the salt, vs. just the candidate password). If you do not know the salt, then you might not be able to effectively crack the password, though you could find the concatenated string. It may be easy to tease apart the password from the salt if the end of the concatenated string looks drastically different from the front (I use 'front' and 'end' assuming salting consists of simple concatenation). I will make a change to note this if there are no objections. --Thedatamatrix (talk) 00:56, 4 August 2013 (UTC)
thread_title:  Effect on dictionary attacks 

message: Shouldn't it be static salt instead of public salt? Unless I am missing something, the section is talking about static salt. Commond Mistakes -> Public Salt or Salt Reuse Xhunterx (talk) 17:54, 2 January 2017 (UTC)
thread_title:  Public Salt vs Static Salt 

message: Minor quibble: .NET is not a language. A framework, if you like, that supports multiple languages.  — Preceding unsigned comment added by 184.71.25.218 (talk) 12:50, 2 July 2019 (UTC)
thread_title:  Web-application implementations