1260:
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.
1111:) - 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.
1412:
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. --
1243:
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). --
1108:
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.,
1043:. 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.
690:
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).
267:
199:
172:
1152:- 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
22:
140:
680:. 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! --
80:
53:
329:
1565:" 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.
1411:
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
1259:
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
985:
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
849:
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
689:
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),
1620:
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
1592:
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
1500:
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
1459:
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.
584:
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
401:
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
435:
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
1454:
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
1242:
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,
1147:
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!"
1002:
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
1015:
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
490:
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
465:
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
421:, 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.
1280:
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
1107:
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"
1057:
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
539:
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
1337:
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.
841:
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
562:
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
535:
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.
1532:
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.
512:
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.
735:
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
1472:. 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.
1449:
1226:
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).
797:
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
1221:
1007:
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
1053:, 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.
466:
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.--
460:
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
1501:
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.
964:
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.
631:
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.
850:
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.
130:
568:
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.
601:
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. --
750:(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)
1236:
1488:
1729:
495:
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?--
778:
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 "
491:
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
436:
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).
551:
481:
873:
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.
1660:
1417:
1248:
1073:
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.
1063:
929:
573:
1476:
Hashing allows for later authentication without keeping and therefore risking the plaintext password in the event that the authentication data store is compromised.
1460:
Hashing allows for later authentication without keeping and therefore risking the plaintext password in the event that the authentication data store is compromised.
1396:
1265:
1090:
360:
676:. 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
504:
1191:
1161:
1116:
1031:
874:
814:" 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.
1370:
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.
1261:
1086:
1067:
257:
1724:
1694:
281:
154:
1036:
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.
585:
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 --
1212:
949:
577:
1480:
877:
694:
430:
1719:
1436:
1098:
1017:
995:
594:
514:
475:
437:
1699:
1689:
1684:
1252:
120:
1510:
1269:
1186:(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). --
697:
610:
445:
1120:
1025:
978:
905:
740:. 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
522:
1664:
1208:
1078:
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.
769:
1421:
684:
1714:
1704:
1679:
1134:
708:
247:
1379:
635:
1400:
457:
1734:
1709:
1644:
1474:
During each attempted log in, the concatenation of the salt and the guessed password are hashed and compared with the saved hash.
1444:
867:
826:
555:
294:
276:
182:
96:
1455:
and I was initially confused. I propose someone who is more knowledgeable change the third paragraph in the first section from:
1327:
1313:
149:
63:
310:
1431:
Shouldn't it be static salt instead of public salt? Unless I am missing something, the section is talking about static salt.
1365:
656:
547:
933:
320:
315:
1406:
918:
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?
422:
305:
223:
1046:
Can anyone provide a good source for the claim that one secret key is a form of salting? Personally, I'd not consider the
1656:
1502:
1059:
925:
569:
409:
540:
password, must brute force the 1024 bits of salt, resulting the log-in lasting up to 1s, a time still very acceptable.
1426:
1392:
1354:
1094:
87:
58:
1295:
986:
the database (since the copied user would have a different row number making the password would be unrecoverable). --
753:
1385:
I agree, but for a different reason. The current first sentence states: "In cryptography, a salt is random data..."
1281:
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!!
625:
412:
369:
Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc.
1739:
1358:
1195:
1165:
206:
177:
1391:
There is no indication from the source that the salt needs to be random, just that it needs to be "non-secret".
693:
My personal, completely unsubstantiated guess is that it comes from the phrase "take it with a grain of salt".
1216:
752:— and it has a sort of sense of "aptness" that invites folk etymologies like we see here. Compare: "spice" in
896:
728:
1301:
1290:
834:
648:
is the most likely source. The actual data is "spoiled" to make it more difficult for an adversary to use.
33:
860:
530:
945:
811:
1450:
Clarification that Salts are Stored and not Randomly Generated Each Time the User Enters the Password
1649:
Minor quibble: .NET is not a language. A framework, if you like, that supports multiple languages.
799:
1629:
913:
721:
I've always presumed that the origin of "salt" is as a sort of back-analogy with the fact that you
426:
343:
669:
Ah, nice suggestions you guys have. Here's the way I usually think of it: Salt is our most common
222:
on Knowledge. If you would like to participate, please visit the project page, where you can join
95:
on Knowledge. If you would like to participate, please visit the project page, where you can join
1506:
940:
It wouldn't be a particularly valuable "grain" of salt for consistent usernames--like "root". --
822:
406:
21:
1350:
1183:
1182:(freely and legally downloadable, thanks to the authors and the publisher), and finally my own
991:
807:
500:
487:
471:
219:
1593:
stored in the user account database along with the hash, or as part of the hash string itself.
1388:
The quoted source, however, states "Salt: A non-secret value used in a cryptographic process".
941:
39:
1652:
1375:
1342:
1232:
1222:
Salts also make .. brute-force attacks for cracking large number of passwords much slower ?
1082:
921:
590:
543:
8:
1484:
1286:
1179:
864:
1440:
1413:
1323:
1244:
1142:
1021:
818:
681:
518:
441:
403:
372:
Find editors who have shown interest in this subject and ask them to take a look here.
1346:
1309:
1153:
1149:
1130:
1038:
IMHO, hashing all the passwords in combination with one secret key is just a form of
987:
974:
961:
The salt should also contain non-alphanumeric characters, which the username may not.
892:
794:
645:
616:
606:
496:
467:
338:
1125:
Right. I ripped that confusing text out along with a bunch of other odd notions.
765:
677:
622:
1371:
1228:
586:
492:
392:
1559:
1204:
1171:
1148:
and "Primer on Unix password structure") are questionable: they fail to mention
1332:
1282:
779:
1673:
1319:
1187:
1157:
1112:
900:
653:
1305:
1275:
1172:
Terry Ritter's collection of sci.crypt posts from a discussion around salts
1126:
1109:
970:
887:
602:
92:
417:
But that seems like a huge help, doesn't it? I mean, if the salt was kept
1175:
803:
761:
723:
1537:
someone stealing the hashes cannot tell that the same password was used.
1207:
as external reference. It's pretty comprehensive and well written. --
787:
458:
Blogs.forbes.com: Discussing Gawker’s Breach With Founder Nick Denton
266:
215:
1621:
a different salt, the reverse lookup table attack won't work either.
649:
211:
198:
171:
1058:
database. Sorry. I don't know a proper name for it. </edit: -->
705:
632:
139:
793:
But since then I learnt that the expression that JRM suggested
783:
79:
52:
328:
1039:
1050:
1047:
1730:
Start-Class Computer Security articles of Mid-importance
886:
True, but this is beyond the scope of this talkpage. ---
621:
Does anybody know the salt's etymology in this context?
704:
But I like the etymology/analogy whether folk or not.
397:
Why is it ok for a salt not to be kept secret? —Anon.
210:, a collaborative effort to improve the coverage of
91:, a collaborative effort to improve the coverage of
1468:A new salt is randomly generated for each password
1003:except few saved bytes per user. User name however
802:" which is a positive thing.) Then there are also "
731:. The bit of gibberish that you feed to PRNG is a
482:
Length of Plaintext Salt vs. Known-Plaintext Attack
1176:Handbook of Applied Cryptography by Menezes et al.
956:I can think of two reasons off the top of my head:
350:Review importance and quality of existing articles
456:The Password Statistics section of this article:
1671:
1304:. This page should have such explicit examples.
1170:Let me nominate the following links/references:
353:Identify categories related to Computer Security
863:to here, as it doesn't belong in the article.
1205:Secure Salted Password Hashing - Do it Right
1032:One salt for all passwords, is that salting?
1302:function examples on the Rainbow table page
19:
359:Identify articles for creation (see also:
1725:Mid-importance Computer Security articles
1695:High-importance Computer science articles
1184:article on proper password hashing in PHP
1178:, Chapter 10, page 390 (or page 7 in the
341:. Please allow some days for processing.
795:"salting the earth" / "sowing with salt"
1630:Explain Hashing + salting Like I'm Five
1156:)" (and "use of" on the other link). --
1720:Start-Class Computer Security articles
1672:
1700:WikiProject Computer science articles
1690:Start-Class Computer science articles
1685:High-importance Cryptography articles
1535:even if the salts are publicly posted
1016:see, if the salt changed (is random).
1203:: I'd like to recommend the article
204:This article is within the scope of
85:This article is within the scope of
15:
38:It is of interest to the following
13:
748:is a nicely similar-sounding word
327:
265:
138:
105:Knowledge:WikiProject Cryptography
14:
1751:
1715:Low-importance Computing articles
1705:WikiProject Cryptography articles
1680:Start-Class Cryptography articles
790:". So I updated my comment above.
366:Identify articles for improvement
108:Template:WikiProject Cryptography
1012:on server side with proper salt.
197:
170:
78:
51:
20:
1645:Web-application implementations
252:This article has been rated as
232:Knowledge:WikiProject Computing
125:This article has been rated as
1735:All Computer Security articles
1710:Start-Class Computing articles
1314:18:18, 13 September 2011 (UTC)
235:Template:WikiProject Computing
1:
1470:and then stored by the system
1366:First sentence makes no sense
1135:05:02, 16 February 2011 (UTC)
996:13:00, 29 December 2010 (UTC)
979:01:59, 21 February 2009 (UTC)
782:" is used both in the sense "
729:Pseudorandom number generator
611:00:45, 21 February 2009 (UTC)
556:15:15, 15 November 2007 (UTC)
505:13:48, 29 December 2010 (UTC)
476:13:48, 29 December 2010 (UTC)
431:15:29, 14 December 2009 (UTC)
337:will be generated shortly by
295:WikiProject Computer Security
277:WikiProject Computer Security
274:This article is supported by
226:and see a list of open tasks.
147:This article is supported by
99:and see a list of open tasks.
1632:--04:46, 30 March 2020 (UTC)
1407:Effect on dictionary attacks
1270:14:43, 21 October 2015 (UTC)
1196:21:38, 12 January 2011 (UTC)
1166:21:23, 12 January 2011 (UTC)
1121:21:05, 12 January 2011 (UTC)
709:14:06, 25 October 2006 (UTC)
698:23:22, 22 October 2007 (UTC)
685:11:58, 25 October 2006 (UTC)
150:WikiProject Computer science
7:
1445:17:54, 2 January 2017 (UTC)
1026:17:44, 2 January 2017 (UTC)
950:15:18, 15 August 2008 (UTC)
523:17:38, 2 January 2017 (UTC)
446:17:28, 2 January 2017 (UTC)
10:
1756:
1511:22:25, 29 March 2020 (UTC)
1427:Public Salt vs Static Salt
1422:00:56, 4 August 2013 (UTC)
1401:00:52, 8 August 2024 (UTC)
1253:00:46, 4 August 2013 (UTC)
1217:13:55, 19 April 2013 (UTC)
770:12:11, 17 March 2013 (UTC)
413:01:31, 22 March 2006 (UTC)
258:project's importance scale
1489:05:33, 15 July 2017 (UTC)
1434:Public Salt or Salt Reuse
1296:Detailed examples please.
1099:15:44, 1 April 2010 (UTC)
1068:17:36, 20 June 2009 (UTC)
934:16:55, 16 June 2008 (UTC)
878:06:49, 3 March 2007 (UTC)
868:17:47, 20 June 2006 (UTC)
756:Encryption_and_decryption
288:
273:
251:
192:
146:
124:
73:
46:
1665:12:50, 2 July 2019 (UTC)
1380:21:24, 23 May 2012 (UTC)
1359:22:59, 22 May 2012 (UTC)
1328:22:02, 7 June 2012 (UTC)
1291:18:58, 11 May 2011 (UTC)
1237:11:49, 10 May 2011 (UTC)
859:I moved the addition by
810:", and ww's suggestion "
657:12:17, 1 July 2006 (UTC)
636:18:53, 5 June 2006 (UTC)
626:14:45, 5 June 2006 (UTC)
595:10:55, 20 May 2008 (UTC)
88:WikiProject Cryptography
1433:Commond Mistakes -: -->
1180:PDF file for Chapter 10
906:16:00, 4 May 2007 (UTC)
827:06:04, 7 May 2024 (UTC)
754:"Hasty Pudding cipher:
578:01:00, 3 May 2008 (UTC)
1740:All Computing articles
1513:Christopher L. Simpson
1478:
1462:
488:Known-plaintext_attack
332:
270:
220:information technology
143:
28:This article is rated
1466:
1457:
808:salting a bird's tail
331:
269:
207:WikiProject Computing
142:
111:Cryptography articles
835:Moved from talk page
356:Tag related articles
293:Things you can help
531:Discarding the salt
344:More information...
744:to anything. So,
672:
333:
271:
238:Computing articles
144:
34:content assessment
1667:
1655:comment added by
1362:
1345:comment added by
1154:key strengthening
1150:key strengthening
1102:
1085:comment added by
936:
924:comment added by
904:
800:salt of the earth
670:
646:salting the earth
558:
546:comment added by
390:
389:
386:
385:
382:
381:
378:
377:
165:
164:
161:
160:
1747:
1650:
1361:
1339:
1101:
1079:
942:MattiasAndersson
919:
914:Username as salt
890:
812:salting the mine
751:
678:flavour enhancer
541:
402:usual number. --
361:Article requests
346:
290:
289:
240:
239:
236:
233:
230:
201:
194:
193:
188:
185:
174:
167:
166:
131:importance scale
113:
112:
109:
106:
103:
82:
75:
74:
69:
66:
64:Computer science
55:
48:
47:
31:
25:
24:
16:
1755:
1754:
1750:
1749:
1748:
1746:
1745:
1744:
1670:
1669:
1647:
1452:
1429:
1409:
1368:
1340:
1335:
1298:
1278:
1224:
1145:
1080:
1034:
916:
837:
749:
619:
548:213.180.137.171
533:
493:Preimage attack
484:
463:could have been
395:
347:
342:
325:
237:
234:
231:
228:
227:
186:
180:
155:High-importance
127:High-importance
110:
107:
104:
101:
100:
68:High‑importance
67:
61:
32:on Knowledge's
29:
12:
11:
5:
1753:
1743:
1742:
1737:
1732:
1727:
1722:
1717:
1712:
1707:
1702:
1697:
1692:
1687:
1682:
1646:
1643:
1642:
1641:
1640:
1639:
1638:
1637:
1636:
1635:
1634:
1633:
1626:
1625:
1624:
1606:
1605:
1604:
1603:
1602:
1601:
1600:
1599:
1598:
1597:
1596:
1595:
1578:
1577:
1576:
1575:
1574:
1573:
1572:
1571:
1570:
1569:
1568:
1567:
1547:
1546:
1545:
1544:
1543:
1542:
1541:
1540:
1539:
1538:
1521:
1520:
1519:
1518:
1517:
1516:
1515:
1514:
1451:
1448:
1428:
1425:
1408:
1405:
1404:
1403:
1389:
1386:
1367:
1364:
1334:
1331:
1318:Seconded... --
1297:
1294:
1277:
1274:
1273:
1272:
1256:
1255:
1223:
1220:
1144:
1141:
1140:
1139:
1138:
1137:
1104:
1103:
1075:
1074:
1033:
1030:
1029:
1028:
1013:
999:
998:
982:
981:
966:
965:
962:
958:
957:
953:
952:
915:
912:
911:
910:
909:
908:
881:
880:
861:69.173.174.235
853:
852:
845:
844:
836:
833:
832:
831:
830:
829:
819:David Göthberg
815:
791:
773:
772:
718:
717:
716:
715:
714:
713:
712:
711:
702:
701:
700:
682:David Göthberg
662:
661:
660:
659:
644:I would guess
639:
638:
618:
615:
614:
613:
598:
597:
581:
580:
565:
564:
532:
529:
528:
527:
526:
525:
483:
480:
479:
478:
453:
452:
451:
450:
449:
448:
423:201.216.245.25
394:
391:
388:
387:
384:
383:
380:
379:
376:
375:
374:
373:
370:
367:
364:
357:
354:
351:
335:Article alerts
326:
324:
323:
318:
313:
308:
302:
299:
298:
286:
285:
282:Mid-importance
272:
262:
261:
254:Low-importance
250:
244:
243:
241:
224:the discussion
202:
190:
189:
187:Low‑importance
175:
163:
162:
159:
158:
145:
135:
134:
123:
117:
116:
114:
97:the discussion
83:
71:
70:
56:
44:
43:
37:
26:
9:
6:
4:
3:
2:
1752:
1741:
1738:
1736:
1733:
1731:
1728:
1726:
1723:
1721:
1718:
1716:
1713:
1711:
1708:
1706:
1703:
1701:
1698:
1696:
1693:
1691:
1688:
1686:
1683:
1681:
1678:
1677:
1675:
1668:
1666:
1662:
1658:
1657:184.71.25.218
1654:
1631:
1627:
1622:
1618:
1617:
1616:
1615:
1614:
1613:
1612:
1611:
1610:
1609:
1608:
1607:
1594:
1590:
1589:
1588:
1587:
1586:
1585:
1584:
1583:
1582:
1581:
1580:
1579:
1566:
1563:
1562:
1560:
1557:
1556:
1555:
1554:
1553:
1552:
1551:
1550:
1549:
1548:
1536:
1531:
1530:
1529:
1528:
1527:
1526:
1525:
1524:
1523:
1522:
1512:
1508:
1504:
1503:204.155.230.3
1499:
1498:
1497:
1496:
1495:
1494:
1493:
1492:
1491:
1490:
1486:
1482:
1477:
1475:
1471:
1465:
1461:
1456:
1447:
1446:
1442:
1438:
1435:
1424:
1423:
1419:
1415:
1414:Thedatamatrix
1402:
1398:
1394:
1390:
1387:
1384:
1383:
1382:
1381:
1377:
1373:
1363:
1360:
1356:
1352:
1348:
1344:
1330:
1329:
1325:
1321:
1316:
1315:
1311:
1307:
1303:
1293:
1292:
1288:
1284:
1271:
1267:
1263:
1258:
1257:
1254:
1250:
1246:
1245:Thedatamatrix
1241:
1240:
1239:
1238:
1234:
1230:
1219:
1218:
1214:
1210:
1206:
1202:
1198:
1197:
1193:
1189:
1185:
1181:
1177:
1173:
1168:
1167:
1163:
1159:
1155:
1151:
1136:
1132:
1128:
1124:
1123:
1122:
1118:
1114:
1110:
1106:
1105:
1100:
1096:
1092:
1088:
1084:
1077:
1076:
1072:
1071:
1070:
1069:
1065:
1061:
1060:130.89.163.83
1056:<edit: -->
1054:
1052:
1049:
1044:
1042:
1041:
1027:
1023:
1019:
1014:
1011:
1006:
1001:
1000:
997:
993:
989:
984:
983:
980:
976:
972:
968:
967:
963:
960:
959:
955:
954:
951:
947:
943:
939:
938:
937:
935:
931:
927:
926:75.164.142.98
923:
907:
902:
898:
894:
889:
885:
884:
883:
882:
879:
876:
875:67.185.169.54
872:
871:
870:
869:
866:
862:
857:
856:
851:
847:
846:
843:
839:
838:
828:
824:
820:
816:
813:
809:
805:
801:
796:
792:
789:
785:
781:
777:
776:
775:
774:
771:
767:
763:
759:
757:
747:
743:
739:
734:
730:
726:
725:
720:
719:
710:
707:
703:
699:
696:
692:
691:
688:
687:
686:
683:
679:
675:
668:
667:
666:
665:
664:
663:
658:
655:
651:
647:
643:
642:
641:
640:
637:
634:
630:
629:
628:
627:
624:
612:
608:
604:
600:
599:
596:
592:
588:
583:
582:
579:
575:
571:
570:122.107.20.56
567:
566:
561:
560:
559:
557:
553:
549:
545:
537:
524:
520:
516:
511:
510:
509:
508:
507:
506:
502:
498:
494:
489:
477:
473:
469:
464:
459:
455:
454:
447:
443:
439:
434:
433:
432:
428:
424:
420:
416:
415:
414:
411:
408:
405:
400:
399:
398:
371:
368:
365:
362:
358:
355:
352:
349:
348:
345:
340:
336:
330:
322:
319:
317:
314:
312:
309:
307:
304:
303:
301:
300:
296:
292:
291:
287:
283:
280:(assessed as
279:
278:
268:
264:
263:
259:
255:
249:
246:
245:
242:
225:
221:
217:
213:
209:
208:
203:
200:
196:
195:
191:
184:
179:
176:
173:
169:
168:
156:
153:(assessed as
152:
151:
141:
137:
136:
132:
128:
122:
119:
118:
115:
98:
94:
90:
89:
84:
81:
77:
76:
72:
65:
60:
57:
54:
50:
49:
45:
41:
35:
27:
23:
18:
17:
1651:— Preceding
1648:
1619:
1591:
1564:
1534:
1479:
1473:
1469:
1467:
1463:
1458:
1453:
1432:
1430:
1410:
1393:24.243.2.150
1369:
1347:Exercisephys
1341:— Preceding
1336:
1317:
1299:
1279:
1262:Catskineater
1225:
1200:
1199:
1169:
1146:
1087:ElectroKitty
1055:
1045:
1037:
1035:
1009:
1004:
988:GlenPeterson
917:
858:
855:
854:
848:
840:
755:
745:
741:
737:
732:
722:
673:
620:
538:
534:
497:GlenPeterson
485:
468:GlenPeterson
462:
418:
396:
334:
275:
253:
205:
148:
126:
102:Cryptography
93:Cryptography
86:
59:Cryptography
40:WikiProjects
1300:I like the
1081:—Preceding
920:—Preceding
804:salted bomb
623:Rob.desbois
542:—Preceding
30:Start-class
1674:Categories
1628:Also see:
1372:Byates5637
1229:Mike2learn
1143:References
842:database."
587:RichoDemus
1481:Bhbuehler
1283:Argel1200
1127:★NealMcB★
788:seasoning
695:Tomfelker
674:seasoning
617:Etymology
339:AAlertBot
229:Computing
216:computing
212:computers
178:Computing
1653:unsigned
1437:Xhunterx
1355:contribs
1343:unsigned
1320:Molivier
1188:Solardiz
1158:Solardiz
1113:Solardiz
1095:contribs
1083:unsigned
1018:Xhunterx
922:unsigned
544:unsigned
515:Xhunterx
438:Xhunterx
410:contribs
183:Security
1306:IOLJeff
786:" and "
727:a PRNG=
393:Secrecy
311:history
256:on the
129:on the
1561:says:
1333:Image?
1201:Update
780:krydda
762:Sburke
563:cases.
419:secret
407:(talk)
218:, and
36:scale.
1209:Mhack
1010:AGAIN
865:Strad
784:spice
671:spice
486:Is a
321:purge
316:watch
297:with:
1661:talk
1507:talk
1485:talk
1464:to:
1441:talk
1418:talk
1397:talk
1376:talk
1351:talk
1324:talk
1310:talk
1287:talk
1276:UNIX
1266:talk
1249:talk
1233:talk
1213:talk
1192:talk
1162:talk
1131:talk
1117:talk
1091:talk
1064:talk
1040:HMAC
1022:talk
992:talk
975:talk
946:talk
930:talk
823:talk
806:", "
766:talk
760:. --
746:salt
742:seed
738:seed
733:seed
724:seed
654:Talk
607:talk
591:talk
574:talk
552:talk
519:talk
501:talk
472:talk
442:talk
427:talk
404:maru
306:edit
121:High
1558:As
1051:API
1048:PHP
1005:CAN
901:WRE
888:J.S
650:JRM
248:Low
1676::
1663:)
1509:)
1487:)
1443:)
1420:)
1399:)
1378:)
1357:)
1353:•
1326:)
1312:)
1289:)
1268:)
1251:)
1235:)
1215:)
1194:)
1174:,
1164:)
1133:)
1119:)
1097:)
1093:•
1066:)
1024:)
994:)
977:)
971:AB
969:--
948:)
932:)
825:)
817:--
768:)
706:ww
652:·
633:ww
609:)
603:AB
593:)
576:)
554:)
521:)
503:)
474:)
444:)
429:)
284:).
214:,
181::
157:).
62::
1659:(
1623:"
1505:(
1483:(
1439:(
1416:(
1395:(
1374:(
1349:(
1322:(
1308:(
1285:(
1264:(
1247:(
1231:(
1211:(
1190:(
1160:(
1129:(
1115:(
1089:(
1062:(
1020:(
990:(
973:(
944:(
928:(
903:)
899:/
897:C
895:/
893:T
891:(
821:(
798:"
764:(
758:"
605:(
589:(
572:(
550:(
517:(
499:(
470:(
440:(
425:(
363:)
260:.
133:.
42::
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
