Talk:Salt (cryptography)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Cryptography / Computer science   
WikiProject icon This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the quality scale.
 ???  This article has not yet received a rating on the importance scale.
Taskforce icon
This article is supported by WikiProject Computer science.
 

Secrecy[edit]

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)
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[edit]

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)

Discarding the salt[edit]

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[edit]

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[edit]

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[edit]

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)

One salt for all passwords, is that salting?[edit]

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 (talkcontribs) 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[edit]

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 ?[edit]

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)

UNIX[edit]

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.[edit]

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?[edit]

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 (talkcontribs) 22:59, 22 May 2012 (UTC)

First sentence makes no sense[edit]

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[edit]

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)