How can I vendorize bcrypt in a PHP application (and should I)?

Question

I am contributing to a relatively mature open-source PHP project. Recently, I discovered that it stores passwords as plain MD5 hashes, which is quite bothersome to me. I figured that if I was going to fix it, I might as well Do It Right(tm), so I wanted to use bcrypt.

First, what I have found for other languages: bcrypt-ruby appears to use either the original C code from OpenBSD or jBCrypt's java code. py-bcrypt is a thin wrapper around the BSD code. BCrypt.net is a direct port of jBCrypt.

Now, PHP itself supports bcrypt (albeit, misleadingly called simply 'blowfish') in the crypt function. However, versions prior to 5.3 require support on the system itself, generally provided by crypt_blowfish. phpass is the same, and recommends installing either PHP 5.3 or Suhosin.

Since many users of the application use standard shared hosting, I don't want to require any special configuration of the server. I was hoping to just steal the code from PHP's 5.3 release, but it is in C, and (from the small bit of reading I've just done) I cannot require the use of a C-extension for the project's users.

I thought of just creating a pure-PHP port of bcrypt, but looking at the source of jBCrypt, I am not sure that I should, given that I'm not incredibly familiar with either PHP or blowfish, and a mistake here could be simultaneously dangerous and difficult to detect in the first place.

So, I present to you two (multipart) questions:

1. Is my lack of PHP knowledge getting the best of me? Can I really use one of the already-created implementations?
2. Should I instead just create a simple loooping function that calls sha1() or md5() repeatedly for some configurable number of times?

Answer 1

Recently, I discovered that it stores passwords as plain MD5 hashes, which is quite bothersome to me. I figured that if I was going to fix it, I might as well Do It Right(tm), so I wanted to use bcrypt.

You should definitely NOT encrypt passwords. Passwords should be hashed and salted.

Encrypted passwords can be recovered, hashed passwords can't (at least that's the theory). Sure, there are ways to use symmetric encryption algorithms as hash functions, but why do that instead of using real hashing functions like the SHA family?

If you are concerned about the security of MD5 (you should be), you can use the SHA family of hash functions. Also remember to salt the passwords to foil rainbow table attacks. Salting is almost as important as hashing.

Read: Just Hashing is Far from Enough

Answer 2

The "Right Way" is to use sha256 and here is a php implementation. Salts should be a large cryptographic nonce approximatively the size of the hash function you are using. It is common to store the salt in a column in the database, and it is common for attackers to obtain this value and break the salted hash with something like John The Ripper.

The use of encryption for passwords is a clear violation of CWE-257. Unless of course you are using a block cipher as a message digest function which bcrypt does. However, bcyrpt is very old, no one should use this anymore. Blowfish should never be used when there is more modern ciphers to choose from like two-fish, AES and Serpent. Further more SHA256 is more efficient than bcrypt.

The whole point of a hash function is that they are FAST to calculate in one direction and slow to reverse, they should never be looped to increase complexity. This doesn't make you safe this just slows down your program. bcrypt is an iterative calculation because the output of a blockcipher is used as a feedback in order to create a message digest. NIST will never approve of using a slow message digest function. You have been misinformed.