To hash or not to hash?

[aggle-rithm]

I have a question about security. I know the prevailing wisdom is that the most secure method of storing a password is with a salted hash, so that it is encrypted in a way that can never be decrypted. What I was wondering is why this is considered a better way to operate than simply encrypting the password with a private key. Is the hash actually more secure, or is it simply more convenient than encrypting/decrypting to verify passwords?

The reason I'm asking is that I recently figured out that my bank knows what my plain-text password is for online banking, and therefore there is no way it is stored in hash form. I'm looking for some insight into how concerned I should be about this.

 

[alfaniner]

"On-on!"

 

[Wudang]

Not really my area but stackexchange sites are usually pretty good
http://security.stackexchange.com/questions/tagged/password-management

 

[Dessi]

I have a question about security. I know the prevailing wisdom is that the most secure method of storing a password is with a salted hash, so that it is encrypted in a way that can never be decrypted. What I was wondering is why this is considered a better way to operate than simply encrypting the password with a private key. Is the hash actually more secure, or is it simply more convenient than encrypting/decrypting to verify passwords?

Great answer here:
http://stackoverflow.com/a/4948393/40516

Long story short, Hashing != Encryption. Hashing algorithms have a few desirable properties for storing a password: they map input to a fixed-length output (unlike encryption algorithms where length of the encrypted text is proportional to length of input text), they usually have very high entropy so that flipping a single bit completely changes the hash (there shouldn't be any correlation between similar inputs), they're also hard or impossible to reverse.

The whole point of hashing is that its hard to reverse the original plain text. Salting a hash prevents a user from initiating rainbow table and dictionary attacks. Imagine the very worst case scenario: an attacker has access to your database, and your application code, in practice should not be able to "decrypt" a hash. I can't really think of an example where a password should ever be reversible.

As for how to store a password, use bcrypt, not because its "more secure", but really because its slow as hell. See linky why slow hashing functions > fast general purpose hashes.

 

[aggle-rithm]

Great answer here:
http://stackoverflow.com/a/4948393/40516

Long story short, Hashing != Encryption. Hashing algorithms have a few desirable properties for storing a password: they map input to a fixed-length output (unlike encryption algorithms where length of the encrypted text is proportional to length of input text), they usually have very high entropy so that flipping a single bit completely changes the hash (there shouldn't be any correlation between similar inputs), they're also hard or impossible to reverse.

The whole point of hashing is that its hard to reverse the original plain text. Salting a hash prevents a user from initiating rainbow table and dictionary attacks. Imagine the very worst case scenario: an attacker has access to your database, and your application code, in practice should not be able to "decrypt" a hash. I can't really think of an example where a password should ever be reversible.

As for how to store a password, use bcrypt, not because its "more secure", but really because its slow as hell. See linky why slow hashing functions > fast general purpose hashes.

OK, so assuming you aren't using a slow hashing scheme, but one of the more common standard algorithms. How is a hashed value better than an ecrypted value? Is decrypting really an option for the hacker if they don't have the key?

(Actually, as I'm writing this, I think I may have the answer. A small change in a plain-text password results in a big change to the resulting hash. The same may not be true of an encrypted value, so the hackers might be able to use statistical analysis to figure out the encryption key.)

 

[aggle-rithm]

This actually brings up another question I've always had about security. With current technologies, hackers can go through all possible permutations of a seven-character password in seconds. But...how do they do this, when most systems lock you out after just a few incorrect tries?

 

[Blue Bubble]

This actually brings up another question I've always had about security. With current technologies, hackers can go through all possible permutations of a seven-character password in seconds. But...how do they do this, when most systems lock you out after just a few incorrect tries?

Simple. They depend on being able to take a copy of the hashed password database to a local machine, and do all the brute-force checking there. In other words, they totally bypass the necessity of checking against the real system, and thus are not subject to system lockout.

 

[DrDave]

How do they decrypt the password 1 character at a time? And how come it takes the same amount of time to do the last character as the first?

 

[Careyp74]

How do they decrypt the password 1 character at a time? And how come it takes the same amount of time to do the last character as the first?

They had special equipment in that movie, just like on CSI when the display shows pictures being flashed on the screen really quickly when searching AFIS for a fingerprint match, or CODUS for DNA.

 

[Wudang]

They had special equipment in that movie, just like on CSI when the display shows pictures being flashed on the screen really quickly when searching AFIS for a fingerprint match, or CODUS for DNA.

And custom built GUIs using Visual Basic to track IP addresses. Scarey what The Man can do.

 

[Daald]

The idea is that if they get as far as to the back end database then they would have compromised all the layers in between.

If that is so then they already have your password in one of the configuration files, since you need it there in order to read the encrypted text or to encrypt the text to begin with.

With hashing the whole idea is that it is a non-reversible action. Rainbow attacks (in which dictionaries and random words are hashed) make hashing by itself insecure for quite a few of your users. The salting is there to throw the rainbow attacks off.

 

[aggle-rithm]

If that is so then they already have your password in one of the configuration files, since you need it there in order to read the encrypted text or to encrypt the text to begin with.

[\QUOTE]

!!!

What?!?

 

[Daald]

!!!

What?!?

Where do you store the encryption key on your application?

You either compile it in the application or you keep it in a config file.

If they can get to your database, they can get to your application binaries and config files.


ETA:

Damn..I see the source of confusion. I said password when I meant encryption key.

 

[rjh01]

What one way functions exist? The ones I know are

- divide the number by a prime and store the reminder. Do that to the number by a few primes and it would be hard to work out the original number.
- divide the number into two parts and then multiply the two parts together. Store the result.

Any others?

Edit. Also to make hash tables even harder they could add in the userid to the password. So even if two users had the same password they would have different hashs.

 

[NewtonTrino]

All I know is that at my high school the main file containing the passwords was clear text. They accidentally (?) left it readable by normal users so I could login as anyone using their own password.

Realistically encryption and hashing use a lot of the same math but as has been pointed out the fixed length output is a nice property.

 

[Octavo]

Edit. Also to make hash tables even harder they could add in the userid to the password. So even if two users had the same password they would have different hashs.

As many others have already said, this is why you usually add a random salt to a hash.

 

[nathan]

They had special equipment in that movie, just like on CSI when the display shows pictures being flashed on the screen really quickly when searching AFIS for a fingerprint match, or CODUS for DNA.

simples; they rely on a broken decryption/checking scheme.

The broken security system takes your guess and the encrypted password, [internally] decrypts the password and then does a char-by-char comparison against your guess, bailing out on the first failure. You arrange for your guess to be placed in memory such that it straddles a page boundary and then arrange for the second page to be paged out. Hey presto, you can determine how far the above check got by measuring the time it takes for the routine to return -- if it takes a long time it'll have advanced into the second page. This allows you to do char-by-char construction of your guess, thus turning the scaling from O(2^N) to O(N).

 

[rjh01]

As many others have already said, this is why you usually add a random salt to a hash.

Nothing that says you cannot do both. It makes sure the salt is unique.

 

[aggle-rithm]

As many others have already said, this is why you usually add a random salt to a hash.

But how do you keep track of the random salt, without also storing it somewhere?

 

[MortFurd]

But how do you keep track of the random salt, without also storing it somewhere?

You do store it somewhere. When someone wants to log in, you take the password they give you, add the salt, and hash the result. You compare that to the stored hash.

Even if the attacker has your salt (which is no problem because it is kept in the database right next to the hash) it doesn't help him. He would have to create a rainbow table using your salt, which takes a long time. Then he would have to try crack your salted hash password. The thing that makes it all worth while is that you use a different salt for every password. All the work done in creating all of the gigabytes of a rainbow table would have to be repeated for every password. That makes it very time consuming and expensive to crack a salted hash password.

The point of all of this is to make it so difficult that the attacker gives up and hits an easier target - or resorts to the XKCD method if they really need your password.