Password hashing: Keccak or not

Question 1

I use Blowfish and really like it, but Keccak is said to be better.

"Better" is such a relative term. Better in what? Security, performance, scalability, portability, ... ?

If you want the greater "security" just for hashing user passwords, then Keccak is probably a not good option. Blowfish will give you better "security" as in it will take longer to brute-force the hash if the hash is ever discovered.

That being said, Keccak is a decent option if you're looking for something to run on embedded architecture, or if you want greater portability. Here is a PHP implementation on github, and here is another You can also make your own language extension by downloading the Keccak source.

But, honestly, it's probably best to stick with what you know. If a hacker can easily get the blowfish hashes you are currently using, then the problem is not the hashing algorithm but the access to the database. Also note that the PHP extension would have to be installed on ALL of the servers using this, which may or may not be possible if you're using a shared host.

In reality you should probably stick with what you have. Chances are it's safe enough, and once the Keccak implementation gets ported to the standard PHP core you can move then (if you need to). Just my two cents.

Question 2

short answer:

No, and probably never. For password hashing, BCrypt & PBKDF2-HMAC-xxx are better choices than any simple SHA-1/2/3 algorithm. And until SHA-1/2 actual have feasible preimage attacks published, SHA-3 is actually the worst choice, specifically because of it's speed and low cache footprint.

longer answer:

A major factor in the relative security of different password hashing algorithms is: how much faster can a dedicated attacker hash passwords compared to you? That is, how much faster is their software/hardware combination (purchased for the express purpose of password hashing), versus your software on your server (off-the-shelf C implementation for software, hardware purchased for the needs of your application).

One of the main SHA-3 criteria was that is should run efficiently on embedded architectures, which are typified by small amounts of on-die cache, registers, etc. But this also describes modern GPUs: fewer registers/accumulators, smaller on-die caches; but on the flipside, their silicon is optimized to perform the same task in parallel on LARGE amounts of data. This is perfect for your attacker's brute-force attempts: for ever dollar spent on silicon, your attacker gets more SHA3 hashes/sec by buying another GPU than you do by buying a better CPU.

For this specific reason, BCrypt was designed to do a larger number of reads/writes to an in-memory table, one that's currently larger than the cache of most GPUs. Which means the current GPU-based BCrypt implementations aren't even up to speed with their CPU counterparts. So just by choosing BCrypt, you've slowed down your attacker's advantage for every dollar he spends, by forcing him to buy CPUs the same as you.

This is why raw speed is the enemy of password hashing. You want to choose the algorithm whose fastest software/hardware combination offers your attacker the least advantage per dollar over the commodity software/hardware that you'll be using. Right now, that's BCrypt, or the slightly lesser choice of PBKDF2-HMAC-xxx. Since GPUs are probably only going to getter better at doing SHA3, I doubt it'll ever be the correct choice. I don't have the numbers on SHA3, but "which is more secure" is not a nebulously relative term - the above rule can be used to precisely quantify it.

Question 3

This is an old question, but it sounds like everyone is confused by cryptography terminology again. Let's clear a few things up.

Keccak is a cryptographic hash function.
Blowfish is a block cipher (which has a 64-bit block size and shouldn't be used for encryption anymore).
Bcrypt is a password hashing function, which has a different use-case than a mere cryptographic hash function. Bcrypt is based on Blowfish, but it isn't Blowfish.

I'm not just being pedantic; these distinctions are important because Keccak isn't competing with bcrypt, it's competing with SHA-256.

Here's an easy way to safely store a password in PHP:

Use password_hash(), password_verify(), and password_needs_rehash()

That's it. You don't even need to care what these functions do, you just need to use them (unless you're using something like libsodium instead).

Currently, this interface provides bcrypt. Bcrypt is mostly fine, except for a few foot-bullets to watch out for:

It truncates passwords after 72 characters, which degrades the security of long passwords with a low entropy-per-character keyspace.
If you try to circumvent the previous foot-bullet by pre-hashing, be careful that you don't pass raw binary to bcrypt, because it also truncates after NUL characters.

If you're worried about these problems, a temporary stopgap exists in password_lock.

In PHP 7.2, it will likely be possible to use Argon2i through this interface (assuming the RFC passes).

In a few years (circa PHP 7.5, assuming no major version bumps) we may see PASSWORD_ARGON2I become the new value for PASSWORD_DEFAULT, but maybe not. We've got a few years for cryptography researchers to gain confidence in it.