Re: [DRAFT RFC] Adding Simplified Password Hashing API

From: Date: Wed, 27 Jun 2012 12:59:51 +0000
Subject: Re: [DRAFT RFC] Adding Simplified Password Hashing API
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to internals+get-60995@lists.php.net to get a copy of this message
Em Wed, 27 Jun 2012 14:43:35 +0200, Pierre Joye <pierre.php@gmail.com> escreveu:
On Wed, Jun 27, 2012 at 2:32 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt> wrote:
Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara <ircmaxell@gmail.com> escreveu: I don't see any advantage in adding complexity through another level of indirection. If people want control over the default their application uses, they can just use a constant they define.
And people will have to, as I described it earlier, and see below.
You described why people *may* have to, depending on the circumstances -- for instance, when interoperability in mixed environments is required. No one is saying that relying on a default value is appropriate in those circumstances, so this argument misses the mark.
That said, I think the default algorithm should provide sufficient guarantees to enable it to be used in a forward compatible fashion.
Back then MD5 alone was all nice and shiny. So no, it is not possible to be forward compatible.
If this API existed 10 or more years ago and used MD5 as a default, I don't see how it could not be used in a forward compatible manner back then -- seen from the outside there's nothing different about MD5 or other digest method except for different parameters (which can be stored together with the salt and the method in the result of password_hash()) and digest size. And, unsurprisingly, you have no justification on why it could not be made forward compatible. -- Gustavo Lopes

« previous php.internals (#60995) next »