加密密码？

Question

I came about this security discussion after reading some topics about session management in php, have a look: https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#title.2

Quote from Chapter: To Pepper Or Not To Pepper?

A much better solution, which is especially useful if you employ hardware separation, is to encrypt the hashes before you insert them in your database. With this safeguard in place, even if an attacker finds a way to dump all of your database tables, they first have to decrypt the hashes before they can even begin to crack them. With the PHP and the database on separate hardware, this becomes much more secure.

In this article, the link to https://github.com/defuse/php-encryption is shared...

So far, I only used password_hash() in order to store passwords in a database. Is it recommendable to encrypt the hash itself? What's your opinion?

Thanks for your ideas!

Answer 1

Hashing with an appropriate hash algorithm is usually enough to protect the passwords, but it is indeed more secure to encrypt (not encode) the hashes afterwards.

When you encrypt the hashes with a server-side key, an attacker must gain additional privileges on the server , to get this key (without the key, the hashes are worthless). It is much easier to get readonly access to a database, than to get privileges on a server. Examples are SQL-injection, thrown away backups, discarded servers, ... In all this cases the encryption would protect the hashes.

In this answer you can find more information, or maybe you want to have a look at the end of my tutorial about safely storing passwords.

Answer 2

Is it recommendable to encode the hash itself? What's your opinion?

No, password_hash() / password_verify() is sufficient. People who need spinal-tap grade security can refer to that part of the article for guidance to avoid accidentally shooting themselves in the foot trying to improve their security , but in general if you're using bcrypt in 2016 then you're fine .

Unless you have separate servers for your website and for your database, the security gain by this strategy is zero. If I can get into your database, I can almost certainly get to your file system, and recover the encryption key.

If you do have separate hardware, and you use an authenticated encryption library such as the one provided by Defuse Security, do feel free to use it. Just know that it's not necessary for most use cases, as the password hashing API provides decent security against modern password cracking.

In a later version on PHP, they'll also support Argon2. If you're going to go overboard, switch to that instead of adding complexity to your protocol.

(Also, it's encrypt, not encode .)

Answer 3

there's no need at all to encrypt the hashes. The attacker has to reverse the hash to find the correct plaintext (user password). This is equivalent to find out the right key for the encryption. hashing is enough. plus salt obviously otherwise your schema is susceptible to rainbow table attacks