Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61894
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <009401cd6f28$b71c69c0$25553d40$@com>
References: <CAAyV7nFRT24rksh6iDWxstfQwJ4+KdEC7Zs6EC8wBtJ8Zorf7w@mail.gmail.com>
	<4FFF1831.8070902@sugarcrm.com>
	<CAAyV7nHi0k6S-zbi5=xCE8EmXpaEds9RoZTB8RPOeO8K_ZLY=w@mail.gmail.com>
	<005101cd6f18$9da38510$d8ea8f30$@com>
	<CAAyV7nGOiVD0=z+6nJKAhr6qu96GuU4+nBTTQiizcP9DxNRUUg@mail.gmail.com>
	<009401cd6f28$b71c69c0$25553d40$@com>
Date: Tue, 31 Jul 2012 10:54:48 -0400
Message-ID: <CAAyV7nH8w5j+AQYQqh0O5eA78tjrvEzAAvKkPNPNrRFhBvDxvQ@mail.gmail.com>
To: Jonathan Bond-Caron <jbondc@openmv.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf3074b8fe21dd0004c6215ce5
Subject: Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified
 password hashing functions
From: ircmaxell@gmail.com (Anthony Ferrara)

--20cf3074b8fe21dd0004c6215ce5
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron <jbondc@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

--20cf3074b8fe21dd0004c6215ce5--