3

Forgive me, as I am very new to cryptography, but it seems interesting, and I have a question.

I'll state my beliefs and please feel free to correct me on the aspects that I'm mistaken so i can learn:

Here's what I think I know:

  1. When trying to protect a password, it goes through a hash function (i.e. SHA-1), and the resulting hash is stored in the database instead of the actual password itself.
  2. Any time one attempts to log in, and they type in their password, their entry gets hashed and then compared to the hash value in the database
  3. So does this mean that for a given login system, if i type "password1", it always has the same hash value?

  4. If that is the case, then wouldnt all members of a login system who have the same password also have the same hash value in the database? Or is there an additional form of security/differentiation implemented for each user so that my "password1" does not come out to the same hash value as the "password1" of another user?

  • 1
    In addition to the answers below, don't use SHA-1 as a password hash, and don't attempt to build your own salted hash. Use bcrypt or scrypt (implementations exist for nearly any language you could want to use). – Stephen Touset Aug 18 '14 at 21:41
  • Or pbkdf2. And with respect to the salt, an easy way to "get" what the salt really means is that when you append it to the passwords, every password becomes unique even if every user has the same password. That's why it is so vital that the salt be random and completely unique for every user (it's pointless otherwise). – Craig Jan 3 '15 at 13:15
7
  1. Yes, sort of. Ideally two values are stored. A unique salt, and a hash of the salt+password. A globally unique salt is generated and stored for each password.

  2. Again, sort of. First the salt for that user account is retrieved from the database, then the salt+password is hashed and compared to the hash value sotred in the database.

  3. No, because the salt will be different for each user, resulting in a different final hash value for each user.

  4. See 3. The salt is the additional security/differentiation component that prevents the hashes from being the same.

  • 1
    It may be worth pointing out that there is a common misconception about salts among people new to the topic, with some people calling even non-unique, site-wide identical "salts" that, or invent strange distinctions for the two (such as "salt" and "pepper"). Don't fall for this; instead, use the term as the answer does. – pyramids Aug 19 '14 at 8:25
  • @pyramids, a "pepper" is a distinct security feature, and a valid one. It provides defense-in-depth, requiring both the DB and application source code to be compromised before being able to see both values. – Chris Murray Aug 19 '14 at 9:33
3

True

All members with the same password have the same hash, unless the hash has been salted with a random value.

In fact the hash value for "password1" is always the same regardless of the web application

  • 4
    "Unless the hash has been salted" is such a big exception---a web application that does not do this should be considered as having a security flaw---that I am tempted to say it comes close to invalidating your answer. – pyramids Aug 19 '14 at 8:20
  • 3
    @pyramids Guess what, there are a lot of websites out there with worse password storage problems than whether they're salting password hashes. Ulkoma's answer is accurate despite your ivory tower idealism that every site should be salting hashes. – PwdRsch Aug 21 '14 at 15:30
  • 1
    @PwdRsch and yet, what pyramids said about the absolute requirement that sites salt their passwords is completely true in a totally practical sense--not "ivory tower idealism." Not salting passwords at this stage of the game is unconscionable, pretend security and a case of making promises you aren't serious about keeping. Honestly, it should be actionable. – Craig Jan 3 '15 at 13:18
1

Funnily enough, all of your questions are answered by the same word: salt

A salt is typically a large (128bit) random value.

First, a unique salt is generated for each password. Now, instead of hashing the password and storing it, we append the salt to the password and then hash the result of that. Now, we store the salt and hash in the database. Whenever the user tries to login, we append the salt and perform the same hashing technique to make sure we get the same hash as the database.

This has the property that each stored hash will be unique, and each password (even the exact same password) will have a different hash (because the salt is unique).

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.