Talk:Salt (cryptography)

Secrecy

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)

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)

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)

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)

Length of Plaintext Salt vs. Known-Plaintext Attack

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)

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)

Discarding the salt

It actually seems you can keep the password much more secure by outright discarding the salt. Assume 6-char all-lowercase password (308 915 776 combinations) and 10 bits of salt (1024 combinations). Decrypting the phrase knowing the password and the salt takes 0.001s.

That means, while knowing the salt, brute-forcing the password will take up to some 3.5 days - perfectly possible. Now if you don't have the salt, bruteforcing the 308,915,776*1024 = 316,329,754,624 combinations will take just above 10 years. Meantime, legit users, in order to log in given the password, must brute force the 1024 bits of salt, resulting the log-in lasting up to 1s, a time still very acceptable. —Preceding unsigned comment added by 213.180.137.171 (talk) 15:15, 15 November 2007 (UTC)

Effectively, that is just making the algorithm more expensive, which can be done in much better ways, such as multple iterations of hashing. Realistically though, tying up the machine, at 100% cpu, for a second just for a password check might not be acceptable in many cases.

A known salt is not designed to make brute-forcing a single password more difficult, it is meant to protect against mass brute-forcing and precomputed tables which it does quite effectively. 122.107.20.56 (talk) 01:00, 3 May 2008 (UTC)

yes it is, I think the Original Poster has misunderstood how and why salts are used, the legit use doesn't need to brute-force anything, the salt is supposed to be known to him, it can be his username or something stored in the same database, like the person above me said, it's primary puropse is to stop rainbow tables, not prevent brute-force, I didn't really understand your reasoning but salting doesn't make it easier to bruteforce a password --RichoDemus (talk) 10:55, 20 May 2008 (UTC)

Based on my understanding of salting, it is not possible to outright discard the salt, because the salt is needed to authenticate the user. I guess I am in agreement with user RichoDemus. --AB (talk) 00:45, 21 February 2009 (UTC)

Etymology

Does anybody know the salt's etymology in this context? Rob.desbois 14:45, 5 June 2006 (UTC)

Nope. But I expect it's connected to the concept of salting a site with something, as in mining fraud. I got curious about this long ago and seem to remember the OED has an entry of some antiquity. ww 18:53, 5 June 2006 (UTC)

I would guess salting the earth is the most likely source. The actual data is "spoiled" to make it more difficult for an adversary to use. JRM · Talk 12:17, 1 July 2006 (UTC)

Ah, nice suggestions you guys have. Here's the way I usually think of it: Salt is our most common spice. So I tend to think of it as the salt "spices up" the password/key. Of course, then perhaps it should be called "pepper" instead. But also, salt is a well known flavour enhancer. That is, adding some salt to food makes the other tastes in the food stronger. (I don't know why it works like that, but it is a well known fact). And the salt in cryptography does make the password/key stronger. So I think "salt" is an excellent word for it in many ways. And it is a short word, easy to spell and pronounce, easy to translate to all other languages and doesn't change cultural meaning when translated. It's perfect! --David Göthberg 11:58, 25 October 2006 (UTC)

Hmmm... I suspect we have here some folk etymology which is nearly always plausible -- else it wouldn't have been proposed and paased around -- but is often off the actual mark. The first point I'd make is that, to my sense of the language, salt isn't a spice. Spices are exotic (or were exotic once), tend to be plant products (shredded tree bark, for instance), are used in quite small quantities, and are entirely optional, nuitritionally. Salt doesn't meet any of those tests, but perhaps my sense of 'spice' is at variance with that of other English speakers. I can burn water without half trying, after all. I wonder if there is a similar distinction in other languages; there appears not to be one such in Swedish (Davidgothberg's native tongue if I understand correctly).

My personal, completely unsubstantiated guess is that it comes from the phrase "take it with a grain of salt". Tomfelker 23:22, 22 October 2007 (UTC)

But I like the etymology/analogy whether folk or not. ww 14:06, 25 October 2006 (UTC)

I've always presumed that the origin of "salt" is as a sort of back-analogy with the fact that you seed a PRNG=Pseudorandom number generator. The bit of gibberish that you feed to PRNG is a seed because it's the start of things and what it is determines everything that then happens (what plant grows out of that pot depends on whether the seed is a geranium seed or a sunflower seed.) So you try to generate a bit of unpredictable gibberish as a seed. However, when you generate a similar value, but if it is input not to a PRNG, but to a hashing algorithm, you're not actually using as a seed to anything. So, salt is a nicely similar-sounding word (phonologically: each starts with an 's', has a double-mora syllabic nucleus, and ends in a consonant that differs from the other only in voicedness, otherwise just being alveolar stops)— and it has a sort of sense of "aptness" that invites folk etymologies like we see here. Compare: "spice" in "Hasty Pudding cipher: Encryption_and_decryption". --Sburke (talk) 12:11, 17 March 2013 (UTC)

Moved from talk page

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)

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)

True, but this is beyond the scope of this talkpage. ---J.S (T/C/WRE) 16:00, 4 May 2007 (UTC)

Username as salt

anyone know why the user's name isn't just used as a per user salt? esp. for cases where the salt is semi-public anyway? —Preceding unsigned comment added by 75.164.142.98 (talk) 16:55, 16 June 2008 (UTC)

It wouldn't be a particularly valuable "grain" of salt for consistent usernames--like "root". --MattiasAndersson (talk) 15:18, 15 August 2008 (UTC)

I can think of two reasons off the top of my head:

• The salt should also contain non-alphanumeric characters, which the username may not.
• Usernames can have wildly varying lengths, whereas the salt should probably have at least a minimum length. This however can be resolved by using a (standard length) hash of the username as the salt.

--AB (talk) 01:59, 21 February 2009 (UTC)

A third reason is that if you use the username as salt, the user can never change their username (unless the system also forces them to manually change their password at the same time). Similarly, I had thought of using the database row number as the salt, but that prevents you from copying users in the database (since the copied user would have a different row number making the password would be unrecoverable). --GlenPeterson (talk) 13:00, 29 December 2010 (UTC)

Also, you would have the same salt across multiple sites, which would allow people to see, if you are using the same password. This would identify you as valuable target. There is also no reason to avoid problems with strength and unexpected unicode names and name changes by just using random salt except few saved bytes per user. User name however CAN be used, if you want to hash the password on clients side to increase security in tranzit. (Either if you don't use https or don't trust the CA system or are concerned with user-added certificates). This password should be however hashed AGAIN on server side with proper salt.

PS: I should probably mention that you should not use random salt for client side hashing, as it would require you to send the salt before login, which would reveal, that the user is registered. Sending random salt for nonexistent users is not a solution, as the attacker can check again later and see, if the salt changed (is random).Xhunterx (talk) 17:44, 2 January 2017 (UTC)

One salt for all passwords, is that salting?

This article clearly states that one salt for the entire password database is a form of salting. I have never heard of this usage of the term before. IMHO, hashing all the passwords in combination with one secret key is just a form of HMAC. The sources for this article also only seem to mention salting in the form I know: a random salt is generated for each password and stored under the same access permissions as the hash. The sources even say "together with the hash". To avoid discussions like "in my database I use separate fields for salt and hash", I slightly broadened it. The baseline is the same: everytime you need to verify a password, you need both the unique salt and the unique hash for that password.

Can anyone provide a good source for the claim that one secret key is a form of salting? Personally, I'd not consider the PHP API, to name something, a good source. An API writer doesn't have exact nomenclature in mind, he just needs to decide on a proper name for a function and would hardly do background research on the exact meaning of the word.

<edit> I striked through the sentence about the HMAC. In my effort to name the beast, I misnamed it. I thought along the lines of "proving to the authentication system that it (the auth system) wrote the hash entry". Obviously that's a completely different discussion pertaining to write access to the database. Sorry. I don't know a proper name for it. </edit> 130.89.163.83 (talk) 17:36, 20 June 2009 (UTC)

You make an excellent point, and in truth most experts believe it's better to have a non-static salt for passwords, otherwise you open yourself up to rainbow tables.

In fact... unless somebody comments otherwise in the next few days, I'm going to add a section to talk about best practices with salting. —Preceding unsigned comment added by ElectroKitty (talk • contribs) 15:44, 1 April 2010 (UTC)

This article is indeed very confusing when it says "For best security, the salt value is kept secret. To determine a password from a stolen hash, an attacker cannot simply try common passwords ...", which implies that (1) there's just one salt value and (2) it is kept separately from and "more" secret than the hashes. This is inconsistent with the typical and required use of salts with password hashes - where the salts are per-hash and are kept just as secret as the hashes (and vice versa), not "more" secret (if this were possible, the hashes would preferably be kept just as secret too, so it's not "more"). However, it sometimes makes sense to introduce what has been called a "local parameter" (at least in some discussions around password hashing that occurred in 1990s - e.g., [1]) - a second salt-like value that is used along with (not instead of!) the normal per-hash salts. This local parameter can in fact be stored separately from the password hash+salt database (not exactly "more secret", just separate to some extent), and it might provide extra security in some special cases (e.g., leaked backup dump for the database, but not for the program configuration file). Unfortunately, it also has drawbacks (harder to move/merge user entries between different instances/installs of the system/program). I think the article needs to be revised to avoid this confusion. My suggestion is that the paragraph starting with "For best security, the salt value is kept secret. ..." be removed. Instead, a paragraph explaining that "with password hashing, the per-hash salts don't need to be kept more secret than the hashes, however a local parameter may sometimes be added and kept separate" may be added further down the article. Of course, it'd need to be more verbose - like this comment I wrote - so maybe this deserves a separate section. Completely omitting the "local parameter" thing is also OK (so simply removing the confusing paragraph is a good start), but then the issue/confusion will likely keep coming up. Solardiz (talk) 21:05, 12 January 2011 (UTC)

Right. I ripped that confusing text out along with a bunch of other odd notions. ★NealMcB★ (talk) 05:02, 16 February 2011 (UTC)

References

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)

Let me nominate the following links/references: Terry Ritter's collection of sci.crypt posts from a discussion around salts, Handbook of Applied Cryptography by Menezes et al., Chapter 10, page 390 (or page 7 in the PDF file for Chapter 10 (freely and legally downloadable, thanks to the authors and the publisher), and finally my own article on proper password hashing in PHP (of course, I might be biased, but I think I explain the gist of salting and stretching/strengthening correctly yet in not-too-many words). --Solardiz (talk) 21:38, 12 January 2011 (UTC)

Update: I'd like to recommend the article Secure Salted Password Hashing - Do it Right as external reference. It's pretty comprehensive and well written. --Mhack (talk) 13:55, 19 April 2013 (UTC)

Salts also make .. brute-force attacks for cracking large number of passwords much slower ?

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)

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)

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)

UNIX

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)

Detailed examples please.

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)

Seconded... --Molivier (talk) 22:02, 7 June 2012 (UTC)

Image?

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)

First sentence makes no sense

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)

Effect on dictionary attacks

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)

Public Salt vs Static Salt

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)

Clarification that Salts are Stored and not Randomly Generated Each Time the User Enters the Password

Clearly it wouldn't make sense for a salt to be generated each time a password is entered into a system. If this were the case, the hash of the concatenation of the new salt and the user's password would not match the hash stored on the system. However, this is not explicitly stated in the article and I was initially confused. I propose someone who is more knowledgeable change the third paragraph in the first section from:

A new salt is randomly generated for each password. In a typical setting, the salt and the password (or its version after Key stretching) are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database. Hashing allows for later authentication without keeping and therefore risking the plaintext password in the event that the authentication data store is compromised.

to:

A new salt is randomly generated for each password and then stored by the system. In a typical setting, the salt and the password (or its version after Key stretching) are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database. During each attempted log in, the concatenation of the salt and the guessed password are hashed and compared with the saved hash. Hashing allows for later authentication without keeping and therefore risking the plaintext password in the event that the authentication data store is compromised.

Bhbuehler (talk) 05:33, 15 July 2017 (UTC)

Bhbuehler|Bhbuehler, good for you, and I thank you. I was coming here to post the exact same comment and thank heavens I saw that you'd already posted it. It's just not possible for the salt not to be stored. (Of course, the salt can be stored as scrambled.) And that leads to the question "What good is it?" Because anyone who can steal the list of usernames and salted/scrambled passwords, and can steal the algorithm that the site uses for scrambling, can also steal the salts in one form or another.204.155.230.3 (talk) 22:25, 29 March 2020 (UTC)Christopher L. Simpson

None of which helps the attacker. If system A hashes a password and system B hashes the same password anyone stealing the hashes can tell that the same password was used. If If system A hashes a password with Salt A and system B hashes the same password with Salt B. even if the salts are publicly posted someone stealing the hashes cannot tell that the same password was used.

As [2] says:

" Lookup tables and rainbow tables only work because each password is hashed the exact same way. If two users have the same password, they'll have the same password hashes. We can prevent these attacks by randomizing each hash, so that when the same password is hashed twice, the hashes are not the same.

We can randomize the hashes by appending or prepending a random string, called a salt, to the password before hashing. As shown in the example above, this makes the same password hash into a completely different string every time. To check if a password is correct, we need the salt, so it is usually stored in the user account database along with the hash, or as part of the hash string itself.

The salt does not need to be secret. Just by randomizing the hashes, lookup tables, reverse lookup tables, and rainbow tables become ineffective. An attacker won't know in advance what the salt will be, so they can't pre-compute a lookup table or rainbow table. If each user's password is hashed with a different salt, the reverse lookup table attack won't work either."

Also see: Explain Hashing + salting Like I'm Five --04:46, 30 March 2020 (UTC)

Web-application implementations

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)