12

When working on a website application, me and a friend asked a security expert (works at IBM) how to handle storing passwords. After hours of google searches (resulting in hours of security.stackexchange.com exploration), I determined that having a user database with the salt in the DB is secure, as long as it's a per-user salt and a slow hashing algorithm.

The security expert said that if the DB was compromised, everything was compromised, which is true. He suggested "one way encryption", which...I don't really get. Isn't hashing, by definition, one way, whilst encryption, by definition, isn't?

If anyone could clear this up, that'd be great.

|improve this question
  • Maybe he's talking about a pepper (which is a value stored outside the DB that's concatenated to all passwords, is the same for every user, and is designed to keep someone who just compromises the DB from being able to guess hashes)? – cpast Feb 2 '15 at 2:46
  • 2
    I know you mentioned this, but it bears emphasis since it is the most important part of a correct solution: you need a slow hashing algorithm, in particular one designed specifically for protecting passwords - such as bcrypt or scrypt (PBKDF2 is also good). There really is no 4th option. Also, note that both bcrypt and scrypt handle the salt internally, so that is something you don't even need to focus on anyway IF you're doing it right (well except for PBKDF2). – AviD♦ Feb 2 '15 at 10:11
  • 3
    This makes me wonder about IBM's hiring practices... – RoraΖ Feb 2 '15 at 14:21
  • 1
    the question could have been marked duplicate if not the story behind it. – elsadek Feb 24 '17 at 9:51
12

You are correct. Hashing is not invertible and encryption is. The security expert is talking through his hat.

The "pepper" that cpast is talking about is the key of a keyed hash. In that case, there are three components in the input to the hash algorithm: the password, the salt, and the key. If the database is compromised, the salt is compromised, but the key is not. If the key is of non-trivial length, like 128 bits, recovering the password from hash and salt alone is probably not possible. (Strictly speaking, it is an "intractable" problem. One knows how to to it -- try all possible key values -- one just cannot do it in reasonable time.)

|improve this answer
  • 1
    Thank you for this answer. This confirms my thoughts. He was mentioning storing the salts in a file protected directory. Do you think he was referring to the pepper in this case? o_O – Awesomolocity Feb 2 '15 at 19:32
  • Generally you will store user ID, salt, and password hash all in the same place, and generally that will be a database table. The key for keyed hash should not be stored in the database. It could be in a file or even compiled into a program. If the database is compromised, e.g. through SQL injection the attacker will still not have the key. Of course, if your O.S. is compromised, you're toast, but that's harder to do. There's more information here: crackstation.net/hashing-security.htm – Bob Brown Feb 2 '15 at 19:36
  • Thank you! That's pretty much what I thought. :) Just decided to come onto the security exchange, just in case. :3 – Awesomolocity Feb 4 '15 at 18:29
6

I suppose that the term "one way encryption" gets back to the days when no cryptographic hash function was available, so to get a password hash on Unix systems for instance an encryption function was used (DES). However, instead to provide a fixed key to encrypt the password (normal usage of this algorithm but which would allow to decrypt the password using this same key), the password itself was used both as the key and as the data to encrypt.

By this way, a one way encryption was achieved since there was no way to decrypt the password without already knowing it.

Afterward, time went on, a lot of people including highly qualified mathematicians and high-profile security engineers worked on the subject, and provided us better tools for each needs (here: password hashing functions). Nowadays no one should therefore try to tinker with existing algorithms to use them in an inappropriate way (an encryption is used to encrypt text, and not to produce a hash).

|improve this answer
3

In standard techie talk, "one way encryption" means hashing. Although technically hashing is a distinct operation from encryption, they are both "cryptographic primitives" and it is common (although technically incorrect) to refer to all cryptography as encryption. Being pedantic with your colleague about this point is unlikely to win you any friends. When speaking to people who are not security specialists I usually use the phrase "one way encryption" as it is more widely understood.

As an aside, it is possible to make any block hash operation into a symmetric cipher, and any symmetric cipher into a block hash operation. There's some info on Wikipedia and Bruce Schneier discusses this in more detail in his book "Applied Cryptography".

|improve this answer
  • 2
    The distinction is actually quite important, and is a matter of confusion. "Techies" is a rather broad category, and might include anyone from a help desk person to a PhD in mathematics working in data science. I don't think it's really pedantic to point out the differences between encryption and hashing as they're distinctly different. It's important we're able to communicate with one another in a field, and if our words become meaningless, that's hard. And in fact there's the case of Adobe, who stupidly used 3-DES ECB mode to encrypt their password file. – Steve Sether Feb 4 '15 at 16:29
  • @SteveSether - what is the distinction between "hashing" and "one way encryption"? I agree we need to communicate with one another, but that does often mean dumbing down the way you speak. – paj28 Feb 4 '15 at 16:50
  • 4
    Hashing actually exists, while one way encryption doesn't and is a confusing term that people who don't understand cryptography use. – Steve Sether Feb 4 '15 at 21:02
  • 2
    @paj28: Do not dumb down the way you speak. Use precise words and phrases. Those who care will follow along; those who do not weren't going to "get it" anyway. – Bob Brown Feb 5 '15 at 3:36
  • @paj28 I wasn't making a large deal about the issue to the person about the difference between "one way encryption" and "hashing". I assumed they were the same, but "one way encryption" seemed to be a contradiction to me so I came to stackexchange to ask if my understanding of encryption was right or if "one way encryption" was something completely different. While I agree that "one way encryption" would be easier to understand, I think proper terminology is preferable; if they don't know the word, it won't take long to teach. – Awesomolocity Oct 23 '15 at 1:42

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.