Skip to content

Ask HN: Borrowed from bcrypt into the SHA2 crypt() schemes. Now what?

2 pointsSaltwaterCdiscuss
On HN

I am maintaining a portable password hashing framework for PHP. Initially it was bcrypt-only, then I adopted the SHA2 crypt() schemes. I said to myself: don't put all the eggs into the bcrypt basket. Then CVE-2011-2483 ( http://www.openwall.com/lists/oss-security/2011/06/20/2 ) hit me, so I knew I was right. However, working with the SHA2 salts from random seeds (nonces) is a pain for everybody who tried those schemes with proper random seeding.

So I made my own re-engineered schemes: https://github.com/SaltwaterC/PasswordHash2/wiki/Proposed-SHA2-crypt%28%29-schemes along with a reference implementation that fixes the common issues. However, in order to get some adoption, what should be the next logical approach? I can safely asume that I am not the only one bashing his head against the wall when the (original) SHA2 schemes are involved.

PS: I know that scrypt exists, if you're asking why I bother with SHA2 crypt(), but for the moment there are no PHP bindings. My C-fu isn't strong enough. I highly try to avoid being the one that screws up a password scheme implementation, especially against my employer's database. See what happened to bcrypt.

Comments

No comments yet.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.