On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron <jbo...@openmv.com>wrote:
> > > > RFC: > > https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper > > > > Thanks, I missed it... > > I strongly disagree with this, the 'pepper' IMHO is a best practice for web > applications. > Again, I have not seen this being said by any security or cryptography expert. > I prefer to live with the idea that an attacker may comprise some > database(s) in the 'cloud' but not the physical machine where you can store > the pepper either in a file, share memory etc... > Ok. So I register an account before I get the database. Now the only thing that I need to crack is the pepper (since I know the salt, hash and original password for my sentinel account). > As far as missing research papers, it's hard to do research on the benefit > of keeping something private. If/when databases do get hacked, it's rarely > released to the public how it happened. > It's very easy to do research on that. There are mathematical proofs that encryption is secure if the secret is secure. I've yet to see that done with a "pepper" used in the manner that you're requesting... > When it comes to web applications, my opinion is odds are greater in SQL > injection / data theft success then gaining physical access to the machine. > #1 SQL Injection: https://www.owasp.org/index.php/Top_10_2010 Wrong. OWASP #1 is not SQL Injection. It's Injection. Including SQL Injection, but also including other forms of injection (header injection, script injection, etc). And that doesn't count that many use SQL Injection as a gateway towards privilege escalation which on many systems will hand them access to the file-system... > > Sure it's an added layer of security but it's hard to deny the 'pepper' > can't help protect passwords against the #1 risk for php/web applications. > I'm not denying the concept. I'm denying the implementation.The existing algorithms expect to see a password. Not a password concatenated with a secret. Sure, it sounds logical that it would make it more secure. But cryptography is not based on what sounds logical. It's based on what's proven. And if it's not proven, it's deemed to be insecure until proven otherwise. If you want to do it in your code, that's one thing. But unproven cryptography has no business in a language level implementation. Furthermore, That link that you posted actually explains things quite a bit. The salt value that's indicated there is actually defined as: A non-secret binary value that is used as an input to the key derivation function PBKDF specified in this Recommendation to allow the generation of a large set of keys for a given password. Now, what does that mean? To understand that, we need to understand what a secret is. A secret is basically a piece of information that the algorithm relies upon for security. Meaning that the algorithm is not secure if the secret is known. A non-secret piece of information is one that the security of the algorithm is not dependent upon. So encryption requires a secret, as the security of the encryption depends on the key being secret (if it's exposed, all security is broken). Since hashing is designed to use a non-secret salt, the security of the hashing algorithm does not depend on it being secret. With all of that said, if you really want a secret in there, don't hijack the hashing algorithm to do it. There are two somewhat decent alternatives: HMAC the password with the secret prior to passing it to password_hash()/crypt(). HMAC is secure and is designed for this exact purpose. Or, Encrypt the resulting hash with a secure encryption function (RIJNDAEL_128 + CBC) prior to inserting it in the database. That way, each component uses standard algorithms as they were designed to be used. But I want to stress something else. Properly managing secrets is VERY difficult. It's not even really possible in PHP, due to the way copy-on-write works, and how variables are removed. To implement this sort of a system correctly is not something even highly competent developers can typically do. It really is that difficult to get right. Anthony
