3
$\begingroup$

In most applications, all passwords are salted independently. In terms of security (e.g. attack complexity), what are the consequences of the following differents approaches:

  1. All passwords are salted with the same salt.

  2. The application does not use salting, but end users choose their passwords by appending to them a (truly random) salt. We make the assumptions that these users are able to remember this much longer password, and that an adversary has access to both the identities of users and the salts that have been used in the associated passwords.

I know that the second is impractical, but I am curious.

Improve this question
$\endgroup$
2
  • $\begingroup$ When saving a password verifier just using a hash function is not sufficient and just adding a salt does little to improve the security. Instead iterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash. Use a function such as PBKDF2, Rfc2898DeriveBytes, password_hash, Bcrypt, passlib.hash or similar functions. The point is to make the attacker spend a substantial of time finding passwords by brute force. $\endgroup$
    – zaph
    Commented Jul 31, 2017 at 15:24
  • 1
    $\begingroup$ I've seen #1 in the wild and it's always a bad idea. I've never seen #2 as that seems procedurally impractical. People will choose "1234" as their "random" salt. Never depend on people to be vigilant when they're allowed to be lazy. $\endgroup$
    – tadman
    Commented Jul 31, 2017 at 16:18

2 Answers 2

Reset to default
4
$\begingroup$

All passwords are salted with the same salt.

Duplicate / reused passwords will show up because the resulting password hash is identical. Cracking the password database will become easier as all the passwords can be cracked at once using a specialized rainbow table or simple comparison against all the passwords in the database.

An attacker could also setup a website with the same salt and hope that users will repeat their passwords; in that case duplicates will show up even if the username is different.

There is still one advantage left for the salt: hacking multiple databases at the same time using rainbow tables or dictionary attacks is still thwarted (unless the salt is reused, e.g. when using "007" as salt, and other implementations do so as well).

The application does not use salting, but end users choose their passwords by appending to them a (random) salt. We make the assumptions that these users are able to remember them, and that an adversary has access to both the identities of users and the salts that have been used in the associated passwords.

That depends on the quality of the salt; but given that the users should remember them they might as well use a longer, unique password. Because they are going to forget that salt, especially if it is specified as e.g. hexadecimals.

Using a unique (hash over a) username as salt is possible, but that means that the password must be refreshed if the username is ever taken; repetition of the password by the same user may show up. You should add a static "pepper" - a secret constant salt - to this kind of salt to make it unique for your specific database.

Improve this answer
$\endgroup$
8
  • $\begingroup$ Thank you very much. I am assuming that the part of the password chosen by the human has a normal length/complexity and that the salt is stored on the end user computer (or written on a Post-It, which is sticked on the computer screen). What about this case? $\endgroup$
    – Dingo13
    Commented Jul 31, 2017 at 14:02
  • $\begingroup$ Well, yes, that could work but now your login is tied to a specific device or worse, sticky note (which, at some time, will get unstuck when the password is really needed, according to the laws of not just dynamics but also Murphy and the Keystone Cops). $\endgroup$
    – Maarten Bodewes ♦
    Commented Jul 31, 2017 at 14:06
  • $\begingroup$ Why are you saying that sticky notes are worse? Since I am assuming that the adversary has access to identities and salts? $\endgroup$
    – Dingo13
    Commented Jul 31, 2017 at 14:08
  • $\begingroup$ The salts can be public as long as they are unique to the password hash - the more unique the better. But they should not get lost because then you loose the ability to login, and that spells a very unhappy customer. If the consumer dislikes anything more than loosing his password because of you it's not being able to consume. PS. Sorry, got to continue work now. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jul 31, 2017 at 14:10
  • $\begingroup$ Thank for this comment. I've read again you answer. Are you sure that, in terms of security, this is a good idea to use a hash of the username as a salt? $\endgroup$
    – Dingo13
    Commented Jul 31, 2017 at 14:16
2
$\begingroup$
  1. All passwords are salted with the same salt.

This is equivalent to have no salt at all.
The point in having a salt, is that for each plain password will be 2^(num of salt bits) variations of encrypted password

  1. end users choose their passwords by appending to them a (random) salt.

Assuming that instead of using a random value for the salt, the user will provide the salt (and the internal algorithm will use the salt as if it was provided by the computer) - we'll lose the variaty of the the random used by the computer, and will replace it with a semi-random (or not random at all - if most of the users will choose the same simple to type salt) human based.

This might provide much more password/salt collisions (which computer based random could avoid)

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thank you. I thought so. In fact, I am especially interested by point 2. $\endgroup$
    – Dingo13
    Commented Jul 31, 2017 at 13:50
  • $\begingroup$ Thank for your answer. I am assuming that salts are really (pseudo) randomly chosen by a computer. $\endgroup$
    – Dingo13
    Commented Jul 31, 2017 at 13:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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