views:

1643

answers:

7

The current top-voted to this question states:

Another one that's not so much a security issue, although it is security-related, is complete and abject failure to grok the difference between hashing a password and encrypting it. Most commonly found in code where the programmer is trying to provide unsafe "Remind me of my password" functionality.

What exactly is this difference? I was always under the impression that hashing was a form of encryption. What is the unsafe functionality the poster is referring to?

+36  A: 

Hashing is a one way function (well, a mapping). It's irreversible, you apply the secure hash algorithm and you cannot get the original string back. The most you can do is to generate what's called "a collision", that is, finding a different string that provides the same hash. Cryptographically secure hash algorithms are designed to prevent the occurrence of collisions. You can attack a secure hash by the use of a rainbow table, which you can contrarrest by applying a salt to the hash before storing it.

Encrypting is a proper (two way) function. It's reversible, you can decrypt the mangled string to get original string if you have the key.

The unsafe functionality it's referring to is that if you encrypt the passwords, your application has the key stored somewhere and an attacker who gets access to your database (and/or code) can get the original passwords by getting both the key and the encrypted text, whereas with a hash it's impossible.

People usually say that if a cracker owns your database or your code he doesn't need a password, thus the difference is moot. This is naïve, because you still have the duty to protect your users' passwords, mainly because most of them do use the same password over and over again, exposing them to a greater risk by leaking their passwords.

Vinko Vrsalovic
To be clear, get the desired security with the hash, it must be a cryptographically secure hash algorithm with the specific property that not only the hash be non-reversable BUT ALSO computationally impractical to generate ANY other string that generates the same hash.
Tall Jeff
Yes and no... Hash collisions need to be hard to generate for the sake of your own application's security, but non-reversability is sufficient for avoiding password leakage.
Dave Sherohman
Thanks for the clear answer
CheGueVerra
... thought to be irreversible ...
Brad Gilbert
... designed to be irreversible ...
Vinko Vrsalovic
Dave: No it isn't. Here is a hash that isn't reversible : `f(n) = n % 2`. It also has a very high collision rate and is totally useless for crypto purposes. A lack of collisions is critical in a cryptographyically-secure hash.
Noon Silk
silky: and how exactly are you going to get the original password back from your lousy hash function? I suggest you reread Dave's comment
Vinko Vrsalovic
+7  A: 

Hashing is a one-way function, meaning that once you hash a password it is very difficult to get the original password back from the hash. Encryption is a two-way function, where it's much easier to get the original text back from the encrypted text.

Plain hashing is easily defeated using a dictionary attack, where an attacker just pre-hashes every word in a dictionary (or every combination of characters up to a certain length), then uses this new dictionary to look up hashed passwords. Using a unique random salt for each hashed password stored makes it much more difficult for an attacker to use this method. They would basically need to create a new unique dictionary for every salt value that you use, slowing down their attack terribly.

It's unsafe to store passwords using an encryption algorithm because if it's easier for the user or the administrator to get the original password back from the encrypted text, it's also easier for an attacker to do the same.

Bill the Lizard
This only works if the attacker knows the value of the hashed password.
Brad Gilbert
+4  A: 

I've always thought that Encryption can be converted both ways, in a way that the end value can bring you to original value and with Hashing you'll not be able to revert from the end result to the original value.

CheGueVerra
+3  A: 

Hashing algorithms are usually cryptographic in nature, but the principal difference is that encryption is reversible through decryption, and hashing is not.

An encryption function typically takes input and produces encrypted output that is the same, or slightly larger size.

A hashing function takes input and produces a typically smaller output, typically of a fixed size as well.

While it isn't possible to take a hashed result and "dehash" it to get back the original input, you can typically brute-force your way to something that produces the same hash.

In other words, if a authentication scheme takes a password, hashes it, and compares it to a hashed version of the requires password, it might not be required that you actually know the original password, only its hash, and you can brute-force your way to something that will match, even if it's a different password.

Hashing functions are typically created to minimize the chance of collisions and make it hard to just calculate something that will produce the same hash as something else.

Lasse V. Karlsen
A: 

As correct as the other answers may be, in the context that the quote was in, hashing is a tool that may be used in securing information, encryption is a process that takes information and makes it very difficult for unauthorized people to read/use.

Peter Coulton
+3  A: 

Excellent answers, not sure this is even worth saying, but in the context of the question:

Always hash passwords.

Ali A
... because you don't need to know the actual value.
Brad Gilbert
+1  A: 

Ideally you should do both.

First Hash the pass password for the one way security. Use a salt for extra security.

Then encrypt the hash to defend against dictionary attacks if your database of password hashes is compromised.

LogicMagic