Any reason to still use Portable PHP password hashing framework?

[NotionCommotion]

Used to be a good option, but don't know anymore as password_hash() is now available.

 

Agree?

 

I understand that I shouldn't ever manually salt and disable the functions salting.  That being said, is there any reason to add a bit extra to the user's password (such as an internal ID and some random constant)?

[Jacques1]

PHPass is long obsolete and seems to have been abandoned by its author. The last version is from 2006.

 

While the script is certainly mature, it's also full of unnecessary and potentially dangerous legacy stuff like a fallback to MD5. In addition to that, the code is very cryptic (no pun intended) due to lots of low-level byte fiddling.

 

So, no, I wouldn't use PHPass in new applications. The author did a great job at introducing bcrypt to the PHP world (the underlying C implementation is also from him), but now we simply have better libraries.

 

 

 

I understand that I shouldn't ever manually salt and disable the functions salting.  That being said, is there any reason to add a bit extra to the user's password (such as an internal ID and some random constant)?

 

I'm not sure what that has to do with PHPass.

 

Theoretically, it can make sense to mix a secret key into the hashes if the key and the hashes are stored separately (ideally on two different machines). This forces an attacker to compromise both the database and the key storage.

 

However, the concrete implementation is tricky. Do you have an extra server at hand? If not, then the whole approach is rather questionable, because the key will be sitting right next to the hashes. How do you get around the input limit of bcrypt? As you probably know, it can only process up to 56 bytes. If you reserve, say, 16 bytes for the key, then the actual password is limited to merely 40 bytes, which is an actual problem for passphrases. This can be fixed by reducing the input with an HMAC before it's hashed, but this would be highly experimental and risky.

 

So I'd stick to plain bcrypt.