Re: RFC proposal to deprecate crypt()

Hi Steve, On 2/20/22 12:44, steve@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