2

I want to store some data so the only one who'll be able to access it is the user itself. Here is my idea: when user registers, his password will be hashed in SHA256 (so it'll fit as an AES key), and encrypt the data using it as an AES 256 key.

If so, I can give up the password section in the DB, I'll won't be needing to hash the password, make salt, etc - I can just try to decrypt the data - it it success, the password is correct.

So what considered to be more secure? One-way-hash using PHP's password_hash with a strong salt, or just hash the password using SHA256 and use it as an AES key (which won't be encrypting the password itself) ?

After all, I've read that AES 256 is secure enough to encrypt TOP SECRET info, so I'm pretty sure that it's hard to figure out what's the key. And even it they will somehow get hold on the key, they'll still have to brute-force the SHA256 to access the password.

Thanks!

Bob Ortiz
  • 6,339
  • 9
  • 45
  • 91
Vlad Gincher
  • 330
  • 1
  • 3
  • 14
  • Possible duplicate of [What is better salted hash or openssl encryption?](http://security.stackexchange.com/questions/15553/what-is-better-salted-hash-or-openssl-encryption) – techraf May 22 '16 at 11:54
  • @techraf NO. I'll never encrypt passwords, it's an awful idea. The question is if the password will be used as an AES key, encrypting other data (a private RSA key), is more secure then just hashing it (with php's password_hash, for example). – Vlad Gincher May 22 '16 at 12:06
  • Your title has one predicate: "to store", so the latter clause reads unambiguously whether to "store password as an AES key". In the question you mention you wanted to use it (stored password) for encrypting/decrypting some data. – techraf May 22 '16 at 13:34

2 Answers2

4

Do not use SHA256 to hash passwords. SHA256 is a message digest algorithm. It is designed to be very fast. Use an algorithm which is intentionally designed to be slow and hard to implement in specialized hardware. Why? Because fast algorithms allow an attacker to brute-force a large number of passwords until they found one which works. "They'll still have to brute-force the SHA256 to access the password" is not that much of an obstacle. A SHA256 cracker which runs on a consumer-grade GPU can calculate the hashes of millions of passwords per second.

Bcrypt (which is used by PHP's password_hash) is one such algorithm, but when you want to turn a password into an encryption key, then it is not the right choice because it's not designed for this purpose. The search term you are looking for is "Key Derivation". A standard solution is scrypt which has several advantages over your method:

  • It hashes each password with an unique salt. That means two users with the same password will have different hashes. That means the attacker needs to brute-force each password individually and can not run their cracker over the whole database until they found a password which fits someone's hash.
  • It can generate keys of any length you want. So you gain more flexibility regarding the length of your encryption cypher.
  • Its hashing function is intentionally designed in a way which makes it a very bad fit to implement with specialized parallel number-crunching hardware like GPUs, FPGAs or ASICs.
Bob Ortiz
  • 6,339
  • 9
  • 45
  • 91
Philipp
  • 49,017
  • 8
  • 127
  • 158
  • That's true, but they do not have access to the hashed password as well, first they'll have to bruteforce the AES, and only then they can see the hashed password (it's the key for the encrypted data) – Vlad Gincher May 22 '16 at 14:51
  • 8
    @VladGincher - they will not bruteforce the AES. They will SHA256 common passwords and try them as the key. This will be very fast. And, because people choose weak passwords, it will be highly successful. – Neil Smithline May 22 '16 at 15:26
  • 2
    @VladGincher The security from AES256 comes from there being 2^256 possible keys to try. But that only applies when the keys are completely randomly generated. When you derive the keys from passwords, you've reduced the keyspace to the hashes of likely passwords, which is far, far less with most users. That's one reason why one should not invent an own cryptography systems: You just read "AES 256 is secure enough to encrypt TOP SECRET info" so you assume it's secure enough for you, but you don't realize that this applies to a completely different use-case. – Philipp May 22 '16 at 15:37
  • OK, thanks, Philipp @NeilSmithline. If I'll add a long and random salt? Will it be secure enought? – Vlad Gincher May 22 '16 at 17:50
  • 1
    @VladGincher No, it won't, because you have to assume that a attacker which got the encrypted data also got the salt, so a longer salt gives you a linear increase at best because there is more data to hash, nothing more. – Philipp May 23 '16 at 06:25
3

For encrypting data, it's generally recommended to store a random key and encrypt this with the appropriately salted password. This means that if/when the user changes their password, you only need to decrypt and re-encrypt their key, and not all their data.

SomeoneSomewhereSupportsMonica
  • 360
  • 1
  • 6