Re: [DRAFT RFC] Adding Simplified Password Hashing API
| From: | Gustavo Lopes | 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: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.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.
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 LopesThat 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.