Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60823
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+yzxZhx9YVarc7dYJYf5LPnTxR6eR3RYa43QsgFOe+DCw7t-Q@mail.gmail.com>
References: <CAF+90c-6VWJ_kBW=Z8Br-NOxKyuTkwStRg-OMBa6844w3=CjDA@mail.gmail.com>
	<CA+yzxZhx9YVarc7dYJYf5LPnTxR6eR3RYa43QsgFOe+DCw7t-Q@mail.gmail.com>
Date: Thu, 14 Jun 2012 09:11:55 -0400
Message-ID: <CAAyV7nGJRGO9tu_UKsO+nVAp5Ks_HTsGCU+4TF2i7MeJmvkSrw@mail.gmail.com>
To: Daniel Macedo <admacedo@gmail.com>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Adding a simple API for secure password hashing?
From: ircmaxell@gmail.com (Anthony Ferrara)

Daniel,

> However, I'd like to throw in scrypt as well. Thoughts?

Yes, that's something to include for sure. I've actually been working
on the side on an implementation of scrypt to sit next to my pbkdf2
proposal as hash_scrypt (as the native function, so that it can be
used natively (without the salt generation component)...

> Stas has the right approach, not only should the methods be simplified and
> platform/algorithm agnostic but have a proper salt built in (there are a
> few CSPRNG implementations around), I've seen salts used from numbers to
> md5's to just being skipped altogether.

Well, just to be clear, a salt does not need a CSPRNG. All it needs to
be is reasonably unique. In fact, I wouldn't make it CS, as that would
deplete the available entropy in the system for CSPRNG generation.

So in practice, a normal PRNG will suffice. With that said, mt_rand()
is not enough. It should be a moderately good PSRNG. It just doesn't
need to be CS. If mcrypt is available, DEV_URANDOM would be a good
place to get entropy.

Or, we could implement a system like I did in
https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random
that follows RFC4086: http://tools.ietf.org/html/rfc4086#section-5.2
Where it mixes together several sources of weak and moderate strength
PRNG...



On another note, I had started an implementation of this yesterday. So
far, I see two "clean" ways of doing it. We could do it class based (I
put it on SPL because it's more of a library addition):

interface \SPL\Password {
    public function hash($password);
    public function verify($password, $hash);
}

class \SPL\Password\BCrypt implements \SPL\Password {
    public function __construct($cost = 15){}
    public function hash($password) {
        // Work involving crypt()
    }
    public function verify($password, $hash) {
        // Work involving crypt()
    }
}

Or, a more procedural approach, with a single "dispatching" function

function password_hash($password, $algorithm = PASSWORD_BLOWFISH,
$options = array()) {
}

function password_verify($password, $hash, $algorithm =
PASSWORD_BLOWFISH, $options = array()) {
}

function password_register($algorithm_name, $hashFunc, $verifyFunc) {
}

The one big issue that I ran into was in registering a namespaced
class into SPL. The SPL class functions aren't designed to handle
namespaced classes as far as I could tell. So we'd have to make a
patch to that first to add macros to support namespaced code...

Thoughts?

Anthony