Hi Steve,
On 2/20/22 12:44, st...@tobtu.com wrote:
Also ~99% of implementations of crypt() that use sha256crypt and/or sha512crypt
password hashing algorithms are vulnerable to a long password DoS attack. Since
they don't know they need to limit the password length because the runtime is
O(pwLen^2+pwLen*rounds). Note a 14000 byte password takes ~1 second, 28000 is
~3 seconds, 56000 is ~11 seconds (results may vary depending on CPU and
sha256crypt vs sha512crypt). Ignoring bcrypt: sha256crypt and sha512crypt are
the only other algos that are not horrible and they are still very bad.
Since password_verify() and password_needs_rehash() already supports hashes
created with crypt(), the only thing needed to do is remove crypt().
Removing it would cause serious BC issues with no practical gain.
What are "BC issues"?... Backward compatibility issues?
Yes.
If that's the case, you may not know that password_verify() can verify all
password hashes created by crypt(). The whole point of deprecating and finally
removing crypt() is that users can no longer create bad password hashes. This
is a massive gain in security. It's like removing mcrypt which removed people's
ability to ECB encrypt data. Sure there are very limited uses that are secure
but 99.9999% are crypto101 errors.
I am maintaining a software that supports a *legacy* password hashing
algorithm that, for reasons that are not relevant to this discussion,
performs two passes of BCrypt hashing with the *same* salt:
crypt(crypt('password', '$2a$08$salt'), '$2a$08$salt');
This is not something that can be replicated with password_hash and
password_verify, because password_hash does not accept an explicit salt
starting with PHP 8.0 and password_verify does not know about this
double hashing.
Even though this hashing algorithm is legacy, we need to maintain
compatibility with that for the foreseeable future to be able to upgrade
users into the current (password_hash() based) hashes, without them
needing to reset their passwords.
Also the *ONLY* non-broken password hash function that crypt() can do is bcrypt
and password_hash()/password_verify() is a better alternative for bcrypt hashes.
Basically crypt() serves no purpose besides as a legacy footgun.
I disagree. Apart from my real world use case above, there might also be
other real world use-cases where interoperability with other software is
required.
As an example: Older versions of Dovecot (< 2.3) do not necessarily
support BCrypt hashes, but they support SHA512-CRYPT. The existence of
the crypt() function allows a PHP-based management portal to generate
password hashes that are understood by those Dovecot versions.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
