# How about adding PHPass compatibility to the password hashing API

- Thread: https://externals.io/message/62973
- Original archive: https://news-web.php.net/php.internals/62973
- Started by Nicolas Grekas on 2012-09-13T11:33:28+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #62973 — Nicolas Grekas — 2012-09-13T11:33:28+00:00

URL: https://externals.io/message/62973#62973

Hi,

What do you think about adding PHPass compatibility to the password hashing
API ?
We could add two new algos : PASSWORD_MD5 and PASSWORD_EXT_DES.
That way, existing password crypted using phpass ($P$*, $H$*, _* prefix)
could be verified using the password hashing API.
PHPass implementation could then be merged with
https://github.com/ircmaxell/password_compat to provide a forward
compatible PHP Implementation for users without PHP5.5.

?

Nicolas

---

## #62974 — Anthony Ferrara — 2012-09-13T11:49:17+00:00

URL: https://externals.io/message/62973#62974 · In reply to: #62973

Nicolas:

On Thu, Sep 13, 2012 at 7:33 AM, Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:

> Hi,
>
> What do you think about adding PHPass compatibility to the password hashing
> API ?
> We could add two new algos : PASSWORD_MD5 and PASSWORD_EXT_DES.
> That way, existing password crypted using phpass ($P$*, $H$*, _* prefix)
> could be verified using the password hashing API.
> PHPass implementation could then be merged with
> https://github.com/ircmaxell/password_compat to provide a forward
> compatible PHP Implementation for users without PHP5.5.
>

The way password_verify is implemented, it can use any crypt(3) generated
hash for verification. It's just a proxy to `crypt()` with a few extra checks
(it won't verify STD_DES, as it's too short).

With respect to adding those algorithms for generating hashes, I'm 100%
dead set against it. Both are significantly weaker algorithms than BCrypt.
I'd rather have this API only contain strong algorithms.

As far as merging PHPASS, I don't really see the reason either. It's a
weaker algorithm (by a long shot). And it's not really tested as an
algorithm outside of the PHP community. For versions < 5.3, it's better
than what's trivially available (though PBKDF2 + SHA2 is significantly
better, and easily implementable in 5.2). But for 5.3+ there are a number
of algorithms available that are significantly stronger (SHA256, SHA512,
BCRYPT).

The last thing I want to happen is to give the user the ability to make a
bad choice without knowing any better (which is why BCRYPT is the only
option so far).

If you want to support PHPASS passwords, just write a quick wrapper that
checks the prefix, and if it's PHPASS, hash it with PHPASS, then upgrade
the hash. It's not that difficult to implement...

Anthony

---

## #62975 — Nicolas Grekas — 2012-09-13T12:04:15+00:00

URL: https://externals.io/message/62973#62975 · In reply to: #62974

>
> With respect to adding those algorithms for generating hashes, I'm 100%
> dead set against it.
>

Ok, I understand and agree, generating hashes for weaker algos is not a
good idea.

The point I wanted to address was forward/backward compatibility with
existing password databases that use PHPass :



> The way password_verify is implemented, it can use any crypt(3) generated
> hash for verification.
>

So forward/backward backward compatibility is granted for CRYPT_EXT_DES,
well done.

Still, for md5 based hashes ($P$/$H$ prefixes), `crypt()` doesn't work.
What about handling these schemes only in `password_verify()` ?

I think that could help a lot on adoption rate for the new API, easing the
transition for current phpass users.


Nicolas