0
$\begingroup$

Let's assume the following situation:

The attacker has extracted 1000 password hashes from a website (vuln.com) along with all their usernames and hashing algorithm (assume bcrypt). The only piece of information stopping them from cracking all the hashes is the missing passwords and salts. Assume the salts are all cryptographically random.

What would change if the attacker also has all the salts?

What are the differences between cracking the hashes with and without knowing the salts?

Improve this question
$\endgroup$
  • 1
    $\begingroup$ This looks very much like a homework exercise, but I'm not 100% sure. Could you share some ideas that you have? $\endgroup$ – DannyNiu Feb 24 '20 at 9:09
  • $\begingroup$ Possible duplicate of Can you help me understand what a cryptographic “salt” is? $\endgroup$ – kelalaka Feb 24 '20 at 10:56
  • $\begingroup$ This isn't homework actually. I understand what salt and pepper are and how they work. I'm curious about the differences in what it would take to crack hashes with or without the salt known. Without the known salt, it'd be like brute-forcing longer passwords. However, knowing the salt means having part of that longer password known.That much is quite straight-forward. However, that "straight-forward" thing only accounts for simple cases like hash = bcrypt(password + salt) and not other more complicated ways the password and salt can be combined. $\endgroup$ – John Zhau Feb 24 '20 at 11:12
  • $\begingroup$ Just wondering why this is not asked in Information Security. You cannot brute force if the salt is already around 128-bit and you don't know it. Also, since the collision, you may get a solution but this will not work since you need to work it with the unknown salt. It is not only salt stopping the attacker but also, memory hard hashing like Scrypt. argon2id and passwords genereated from a good entropy source like diceware. $\endgroup$ – kelalaka Feb 24 '20 at 11:45
  • $\begingroup$ @kelalaka In this case, I'm thinking of using only the brute-force attack. Simple hashes and short salt strings can be assumed to simplify this. An example with pw.len = 6; salt.len = 2 is fine for demonstration purposes. With a few variables (pw.len, salt.len), we can scale it up with longer strings. I'm not very good with maths so I'm wondering how we can estimate computations and whether there's some analysis that can be done knowing the salt but not how the password and salt are combined before the hash. $\endgroup$ – John Zhau Feb 24 '20 at 13:11
3
$\begingroup$

The point of using salt is not that it's secret. In fact, it's usually stored together with the hashed password. The point of using salt is that it's different for each entry. This has a few major benefits:

  1. Two users who use the same password won't have the same hash. Hence an attacker can't see which users share a (presumably weak) password.
  2. In a dictionary attack, the attacker can't use a precomputed table of bcrypt hashes. Instead, they have to compute each hash for each salt anew. In particular, the use of salt is a pretty good defense against attacks using rainbow tables.
Improve this answer
$\endgroup$
  • 1
    $\begingroup$ Actually, the point of a salt is very much that it's unpredictable prior to seeing the hash / ciphertext to avoid precomputed dictionaries against a specific user. $\endgroup$ – SEJPM♦ Feb 24 '20 at 8:49
  • $\begingroup$ @SEJPM I would see that as an addition to above goals. It is a bit of a generalization of the second point. $\endgroup$ – tylo Feb 24 '20 at 12:03
0
$\begingroup$

wallenborn has correctly described the actual purpose of a salt and its implementation. If a salt or an analogous value is kept secret, it is sometimes called pepper.

A pepper that is long enough and randomly generated makes a big difference to password cracking. Even simple passwords like 123 would be safe.

The only problem is to implement the pepper in a way that it is always available for password hashing and still remains secret.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.