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)

Xhunterx: Glen meant when the attacker knows most of the plaintext, as in a long known salt concatenated with a shorter unknown password and then hashed (or if it is encryption: encrypted with some key). For modern hashes that isn't a problem. For weak ciphers that would be a big problem, since the long known plaintext would allow the attacker to figure out the key, and then he could decrypt the last part that carried the password as encrypted data load. For well built modern ciphers used correctly in a good block mode (CTR mode), and with a good initialization vector, and strong enough key, and so on, it isn't a problem. Since for them you can't figure out the key, even if you know most (or all) of the plaintext, and even if the plaintext is very long.

@GlenPeterson: Short answer: No. Longer salts would not make it easier to figure out the passwords. Longer salts (longer input) doesn't leak more data when hashing. Actually the opposite, longer input causes better mixing (more rounds) in the hash function, except for the last block fed that still only gets one round of mixing. (While longer input can leak more data in other cryptography.)

Long answer: I see what you meant. For the sake of this discussion we have two main cases here: Either using the same salt for all the passwords in the password file, or using different salts for each password.

I will assume we are here talking about the regular cryptographic hashes that fully mix in one block at a time into their internal state, when they process the data: See Merkle–Damgård construction.

Case 1: If we are doing hash( salt + password ), "+" meaning concatenation, and we use the same salt for all the passwords, and the attacker knows the salt and the resulting hash sum, but not the password, then does a much longer salt make it easier to guess the password from the known salt and hash sum? Since then the attacker knows more of the input to the hash function.

I think that wouldn't make the attack easier. Since modern cryptographic hashes have full avalanche effect, and as far as we know they can't be calculated backwards (we think/hope they are one-way). So once the hash function mixes-in the next block it fully hides what came before, so a salt that is longer than one block length of the hash function does not leak or provide any extra information. Also, when the hash function mixes-in the last block with the password then it fully hides what came before, provided the password is good enough. Although, in this case we know what came before since we know the salt. But the last block gets mixed in more than good enough. But even if it is two simple and similar passwords, say "test1" and "test2", then the hash sums would look totally different due to the avalanche effect. So even if you brute forced the "test1" password, that would not help you to find the "test2" password among all the other hash sums in the password file.

If the system is hashing the password and salt in another order, for instance hash( password + salt ) or hash( salt + password + salt), or even hash( password + salt + password ) (kind of like HMAC), then having longer salts would still not make it easier to recognise similar password hashes. Since once the password is mixed in, the internal state of the hash will look completely different for "test1" and "test2", then at the next block where the ending salt is mixed in the resulting hash sum will still be totally different since the two internal states were different before the last block. In theory this case protects the password even better, since the long salt will cause more mixing rounds after the password was processed.

Case 2: The other case you might have meant is if we have different salts for each account. Like hash( salt1 + "test1" ) and hash( salt2 + "test2" ). That still would not help the attacker to compare those hash sums or figuring out one of the passwords, even if the salt is very long, since again: Longer salts doesn't leak more information since the avalanche effect and the one-way-ness hides what data was fed in the beginning to the hash function. And the last block gets mixed in more than good enough. But also in this case putting the salt last, doing hash( "test1" + salt1 ), in theory seems stronger.

Of course, making the hash function take an extra round doesn't hurt (like HMAC does), it likely protects against many of the future weaknesses (if any) found in the hash function. (HMAC was designed to protect against a known weakness (length extension attack) in most current cryptographic hash functions, but that weakness doesn't affect the password hashing we are doing here.) Unfortunately simply causing extra rounds doesn't protect against the main weakness found in MD5 and SHA-1. The weakness where you can on purpose create two similar texts that get the same hash sum. The partially broken MD5 and SHA-1 can't be calculated backwards (yet), but the break in them showed that they have slightly bad avalanche effect. Although I think that specific weakness mostly doesn't affect the password+salt hashing case we are talking about here. (I'll spare you the explanation why here.) But anyway, the general rule is: If ANY weakness is found in a cryptographic primitive, start using better stuff. Since often when one weakness has been found, more and worse are found soon after.

Disclaimer: I am not a crypto analyst, but I have studied computer security since 1987, and cryptography since ca 1994.

--David Göthberg (talk) 17:09, 19 October 2024 (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 seasoning. 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)

Since my English language knowledge has expanded since my old comment above: User ww is correct in that I was misusing the word "spice" since I am Swedish. The Swedish word "krydda" is used both in the sense "spice" and "seasoning". So I updated my comment above.

But since then I learnt that the expression that JRM suggested "salting the earth" / "sowing with salt" is used figuratively in English and other languages. (I just knew its historical background as a way to curse/destroy an enemy area from future agriculture.) So I now think that is perhaps the most likely etymology. (Not to be confused with "salt of the earth" which is a positive thing.) Then there are also "salted bomb", "salting a bird's tail", and ww's suggestion "salting the mine" but I find those less likely candidates. But they all fit to some extent. And as Sburke pointed out, it also sounds good. So yeah, it fits in many ways.

--David Göthberg (talk) 06:04, 7 May 2024 (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)

Well, some sources are probably confusing since the writers are aware of the history of salts:

In the old days (early 1990s) there often was just one salt for the whole password file. That protected against an attacker using the same rainbow table against several different organisations, and protected the passwords if a user reused his username and password at another organisation. Back then, most systems just had a few hundred users, or at most a few thousand users.

But then people changed to using the more secure option of using a unique salt for each user in the password file.

But the user salt is often combined with a single more secret salt that is unique for that system. In one of the main systems here in my city they didn't store that single salt on any drive, instead it had to be manually entered by the main admins each time the password server was restarted (perhaps once per year on average) directly at the keyboard of the password server. The salt was stored on a folded paper in their physical safe, that only the three main admins had the key and code to, and that safe was in their office that was manned and guarded 24/7/365. The reason for the 24/7 manning is mostly since the city needs services 24/7. And the reason for the 24/7 guarding is mostly because there are so much expensive equipment there, and they had recurrent thefts of the computers in the adjacent buildings until they put alarms on everything and increased the guarding. (I used to work in one of the adjacent buildings, and some of the regular admins from the city office were members in our city's computer club, so we used to hang out on club nights and play Star Craft and discuss computer security.) I know that the usual time for the police to arrive at that location if the intruder alarm is triggered is usually at most three minutes. It is in the same area as our arts museum, all thieves that have tried to grab a painting there have been caught by the police before they could reach the exit door. So almost by accident, that extra salt was stored in a ridiculously secure way.

--David Göthberg (talk) 13:25, 19 October 2024 (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)

I agree, but for a different reason. The current first sentence states: "In cryptography, a salt is random data..."

The quoted source, however, states "Salt: A non-secret value used in a cryptographic process".

There is no indication from the source that the salt needs to be random, just that it needs to be "non-secret". 24.243.2.150 (talk) 00:52, 8 August 2024 (UTC)

I checked the first sentence in the article at the time Byates5637 read it. I think it was grammatically correct back then. And the current version says "a salt is random data fed as an additional input to a" which I think also is correct grammar, although I personally would remove the "an" and just make it "a salt is random data fed as additional input to a". I think it depends if you see that data as one thing, or as a bunch of data (or bits). But I am not a native English speaker.

And regarding the properties of a salt:

The salt doesn't have to be "non-secret", just that it usually is okay if it is public, for instance stored in a password file that some or many users have access to. However, if you can make your salt secret that is even better, that kind of makes the salt into a second key, and makes things stronger. So nowadays most systems don't allow users to see the password file.

Secondly: A salt doesn't have to be random data, instead:

• The salt has to be sufficiently unique (so we don't use the same salt several times). Using current date and time (including current second) might seem unique enough at first. But clocks fail and computers can be tricked into thinking it is another time and date, even if they use GPS-time (just put up a fake GPS sender across the street with a stronger signal than the satellites and you can turn back time). If you see an encryption system that depends on "secure time" you can be pretty sure the designer was an amateur. We have better solutions than using time for pretty much all usage cases.
• It is good if the salt is unpredictable so an attacker can't guess the salt before we create and use it, so the attacker can't start doing calculations ahead of time.
• To just use a counter and increase the value of the salt with one for each use within one session sort of is okay. Provided you start the counter at a large unpredictable random value, so that the next session doesn't use the same values. But using a counter that runs over several sessions is a big no-no, since if you save your current value on disk so you know where to continue the count, and that save fails for any reason, then in the next session you will read the old value from the disk and start from the same value as in your previous session. Same repeat will happen if you restored your system from a backup. But using a counter is kind of silly since we now have so good and fast cryptographically secure pseudorandom number generators that we can use within a session (but it should of course be started from a true random number).

The simplest and most secure way to fulfil all the criteria above is to use a large random value (say at least 100 bits) so collisions (reuse of the same value) becomes very unlikely.

I hope I didn't mix up any of the criteria with IV (initialization vector) and nonce since they are so similar. I tend to mix them up.

--David Göthberg (talk) 11:25, 19 October 2024 (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)

No. If salts are not used, or only a single salt for the whole password file is used, then the attacker hashes each word in the dictionary, and then checks if any of the accounts has that hash. So without unique salts he can attack all the accounts in the same system at once. (If he has the password file that contains the account names and hashed passwords, and knows the single salt if there is one.) With a different salt for each account the attacker has to make a full dictionary attack against each account, one at a time, to find those accounts that use short passwords that exist in the dictionary.

--David Göthberg (talk) 13:51, 19 October 2024 (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)