RE: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions

From: Date: Tue, 31 Jul 2012 16:01:07 +0000
Subject: RE: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Tue Jul 31 10:54 AM, Anthony Ferrara wrote:
> 
> On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron <HYPERLINK 
> 
> 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.
> 

Like I said IMHO, I'm not a security expect but I do think there needs to be
modern discussion around 'web password hashing'.

>
> 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).

Fair enough ;)

It can still be a problem if the pepper is large + the crypt() salt

> 
> 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.
> 

Not so great:
password_hash_rfc( hash_hmac('md5', 'password', '1024-bytes secret') )
//
hmac is short (~ 160bits)

I guess you mean:

hash_hmac('md5', password_hash_rfc('password'), '1024-bytes secret')

But then there's no way to know all those crypt() parameters, salt, cost,
etc...

Maybe a new api?
password_hash_hmac($password, $secret, $options = array());

> 
> 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.
> 

That's fine, I feel this should be somewhat easier in php core (without the
need for openssl & al.)

It also comes with a cost of decrypting the hashes / not so great

> 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.
>

Sure managing keys properly can be hard, simple cases: 
$secret = MY_KEY;
$secret = file_get_contents('/security/key.pem');

Again I'm making the assumption that the attacking *does not* have access to
the file system.




Thread (47 messages)

« previous php.internals (#61895) next »