1

Is there any benefit in salting passwords for a strong, unique (not used for other applications by the user) password?

Salting (as I am aware) protects against rainbow tables generated with a dictionary or common passwords. It also protects against an attacker noticing a user with the same hash in another application.

Seeing as a strong password will (likely) not appear on a generated rainbow table, and a smart user will use unique passwords for each application he wants to protect, does salting protect an already "smart" user?

this is theoretical. i have no inclination to stop salting.

in essence, doesn't the salt just become part of the password? it just happens to be supplied by the gatekeeper rather than the user.

Nona Urbiz
  • 4,873
  • 16
  • 57
  • 84
  • 1
    "a smart user will use unique passwords" - Not as likely as you might think and at the end of the day it doesn't matter. It is your site that will be reported as being hacked and blamed by all those not as "smart" as you think when they need too change password on the few other sites where they used the same one. – Fredrik Dec 20 '09 at 20:53
  • there is no reason not to make things doubly salty (trust me, you don't have to taste it, :D) – Dan Beam Dec 20 '09 at 21:20
  • See also: http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190 – Jacco Dec 26 '09 at 13:14

4 Answers4

8

If you can guarantee that all users will never reuse passwords, and that none of their passwords will ever be of a form that it is computationally feasible to precalculate colliding hashes for, then indeed the salt is little additional benefit.

However, the salt is also of little additional cost; while these premises are very hard indeed to guarantee, and the cost of being wrong about them is high. Keep the salt.

moonshadow
  • 86,889
  • 7
  • 82
  • 122
1

Apart from rainbow tables there are also bruteforce tools to resolve a hash. This doesn't prevent unsalted hashes from being resolved. It only takes a longer as stronger the password is. Salting would certainly still make sense.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • i'm confused as to what your answer is exactly. are you saying that the salt helps simply as it adds to length, and therefor processing time for a bruteforce crack? but a strong password is already sufficiently lengthy to ensure virtually complete security from a brute attack – Nona Urbiz Dec 20 '09 at 20:43
  • No, without a known salt you cannot resolve the actual password, regardless of the strongness of the password. – BalusC Dec 20 '09 at 20:45
  • but in essence, doesn't the salt just become part of the password? – Nona Urbiz Dec 20 '09 at 20:47
  • The presence of salt means I can't reuse the results I generated while bruteforcing one server to bruteforce another - I have to start over again from scratch for each target. Also, I need to know the salt in order to be able to find a plaintext collision, although generally if the hashed salted password is available to me, the salt also is. – moonshadow Dec 20 '09 at 20:47
  • i mentioned in my op that cross system security is irrelevant in this theoretical discussion – Nona Urbiz Dec 20 '09 at 20:49
  • It's not irrelevant, or at least is not made so by the reasons you cite. The question is whether the attack is a class break or not - whether the cost of an attack is to be paid per target or per hash algorithm; this is true regardless of whether the user reuses the passwords or not. – moonshadow Dec 20 '09 at 20:53
1

This feels like you want to make an assumption, then base your security on that assumption. When you assumption becomes bad, for whatever reason, then your security becomes bad.

So how might your assumption (that strong passwords don't need salting) become invalid?

1) Over time, larger, more comprehensive rainbow tables are generated. This is something I would worry about if it is up to your user to choose a strong password. They might think they have done a good job, and you and your safety checking might think they have done a good job too, but later it turns out their thought process creating the password was easily duplicated by stringing a few words and numbers together.

2) If users cannot choose their password, your strong password generation process might, due to bug or whatever, turn out to be not as strong as you want.

3) Your user might be too lazy to come up with a site-unique/strong password! This is surely the most important problem. Do you really want to generate a system which is usable only by cryptographic experts? :)

Tim Lovell-Smith
  • 15,310
  • 14
  • 76
  • 93
1

Rainbow tables are most definitely not restricted to dictionary passwords or the like. Most tend to include every character combination up to some max length - after all, it's a one time cost for generation. Do your users all use 12+ character passwords? Unlikely.

Dav on a Plane
  • 81
  • 1