4

Today I've read about AES (A dvanced E ncryption S tandard) and I was asking myself questions which I don't have the knowledge to answer them myself.

I've read in Wikipedia that AES is safe to use even for Top Secret files and until now, no one found a way to hack it. There were indeed some tries to use Side-chanel attacks, but it didn't go that well since it isn't attacking the encryption itself.

In light of what I've read about it, I was wondering, should I use AES to encrypt passwords in my DB? I can save the encrypted password, or rather use hash() function to encrypt the AES encryption of a string in a database which gives it somehow a "double-layered" protection. I might be completely wrong here, I'm just wondering what's the reason it isn't that common when it comes to storing encrypted strings in a DB. I guess that's because there is a decryption method, but still, to decrypt it, you will have to know how many rounds the code used to encrypt it.

Thanks in advance!

Marcus Adams
  • 53,009
  • 9
  • 91
  • 143
kfirba
  • 5,231
  • 14
  • 41
  • 70
  • 2
    Why not just store a salted hash of the password? What possible purpose would you have to be able to retrieve a password in the first place? If a user forgets the password, just have them reset it. – Julio Dec 18 '13 at 17:42
  • @Louis It's more like I'm trying to understand that. If using hashing + encrypting can actually improve significantly the security. BTW, why save a salt in the DB? why even use a salt? if a hacker hacks the DB, he will be able to see the salt in the DB which he can now append to his attempts to get the password – kfirba Dec 18 '13 at 17:45
  • This question may be better suited on security.SE – Maerlyn Dec 18 '13 at 17:46
  • 5
    [This is what can go wrong](http://arstechnica.com/security/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/) when reversible encryption rather than salted one-way hashing is used for password storage. – Michael Berkowski Dec 18 '13 at 17:47
  • 4
    Don't encrypt passwords, precisely because encryption __is__ reversible – Mark Baker Dec 18 '13 at 17:47
  • Head over to http://security.stackexchange.com and search for discussions on password hashing and storage. It is discussed at a high level there. And [this is pretty much the definitive guide](http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php) for PHP password hashing here on SO. – Michael Berkowski Dec 18 '13 at 17:49
  • @MarkBaker and what about hashing an encryption? doesn't it make it more secure? or it is just useless? – kfirba Dec 18 '13 at 17:51
  • 1
    @kfirba That would be useless. Hashing works in practice by storing a salted+hashed value then when a user inputs a password, salting+hashing the input value and comparing it against the one in the database. The original contents of the password are effectively lost. You don't gain anything by encrypting it after hashing because the weak point is still your server security which must somehow hold or access the AES encryption key. Code flaws or server vulns which expose the hashed password table may just as well expose the key needed to decrypt the hashes. No gain there. – Michael Berkowski Dec 18 '13 at 17:54
  • @kfirba You don't store the salt in the database, you store the **salted hash**. That is you pass some extra value to the hash function, along with the password (i.e. `hash_func("badpassword" + "mYs@lt123")`). This aims to prevent attacks were possible password hashes have been precomputed. If the database were compromised, the attacker would not know the salted hash and would have a harder time figuring out what the hashes are representing. – Julio Dec 18 '13 at 18:03
  • 2
    @Louis, generally, you just store the salt next to the hash. The salt is not a secret, it's simply random. – Marcus Adams Dec 18 '13 at 18:27
  • @MarcusAdams Are you implying that they should store the salt in the database, alongside the password? Wouldn't that defeat the purpose of a salted hash in the first place? If the database is compromised, the salt is also made available to the attacker. – Julio Dec 18 '13 at 18:37
  • @Louis, yes, that's the standard use of a salt. The salt is simply to prevent rainbow attacks and to prevent two people with the same password from having the same hash. It's not intended to be any more secret than the hash and is generally stored with the hash (not the password). – Marcus Adams Dec 18 '13 at 18:39
  • 1
    @Louis Even if the attacker gets hands on the unique random salt associated to each salted password hash, she still has to run the whole brute-forcing process for each password individually, without being able to reuse the results from the other passwords. This gives you an extra time span during which your users can change their passwords on your site after you disclosed the breach to them (ideally; most will also have to change it on other sites too). – Jonas Schäfer Dec 19 '13 at 10:27
  • @JonasWielicki This is interesting, and makes perfect sense given a bit of thought. I always presumed it'd be easier to just not store it in the database at all. – Julio Dec 19 '13 at 15:24

1 Answers1

5

Should I use AES to encrypt passwords in my DB?

The problem with storing encrypted passwords (instead of hash values) is that encryption is reversible. It is very uncommon to actually need to store passwords, rather than simply have a mechanism to authenticate users. Encrypting (reversible) passwords is not recommended, and you should have a very strong reason for ignoring this practice.

I can save the encrypted password, or rather use hash() function to encrypt the AES encryption of a string in a database which gives it somehow a "double-layered" protection.

It's hard to tell what you're asking here, but I guess you're asking whether encrypting the hash values will make your system more secure.

The answer is yes, as long as you store the key for that encryption securely and separately from the hash. However, this only adds as much protection as that separation provides. Is it worth complicating the application, especially considering the fact that salted and hashed values using a decent hashing algorithm should be good enough?

I feel that if encrypting hashes were worth it, it would be standard practice, and it's not.

Marcus Adams
  • 53,009
  • 9
  • 91
  • 143
  • Just to add to your answer, the better way to provide a "double-layered" protection is to use a random salt. – Pier-Luc Gendreau Dec 18 '13 at 19:07
  • Yes, the only requirement of a salt is that it's random. – Marcus Adams Dec 18 '13 at 19:11
  • 2
    Use a random, long salt, and use a slow hashing algorithm (i.e., more than one round of hashing). The point of both of these requirements is to make it extremely time- and resource-expensive to brute-force the password or generate rainbow tables if the salts and hashed passwords are ever compromised. See, for example: http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords – elixenide Dec 18 '13 at 20:18