After a lot of reading the expert opinion on password hashing, I understand that scrypt (which is both memory hard and CPU intensive) is a good candidate for password hashing. But I saw the experts recommending a wait of at least 5 years until it is thoroughly peer reviewed and baked (chicken and egg problem ? :) )
If we want to look for rational reasons not to use scrypt right now, we can find mostly these three:
It is unclear whether a "memory-hard" function is what is needed, with the parameter configurations supported by scrypt. Scrypt was initially designed to support local encryption, particularly whole-system encryption. This means that the password must be hashed during the system bootup process; at that time, the computer has nothing else to do, so the whole CPU and RAM is available for a single scrypt; and since bootup already takes a non-negligible amount of time, a password hashing extending over 5 or 10 seconds is no hardship.
A typical server will need a distinct configuration, that uses less RAM (a server cannot afford a gigabyte per password hashing, if it has to serve several clients and not crumble under peak load) and less CPU (a Web site authentication should be done within less than 1 second, because users are not patient; and, there again, we must account for peak load). Whether scrypt is better than bcrypt when configured for "server usage" remains to be seen; in fact, if you need to put CPU usage down to about 1 ms per hash, then scrypt uses less RAM than bcrypt, making the latter a superior option.
As far as memory hardness is concerned, scrypt turned out not to be as optimal as it could be. Some GPU-based optimization is still doable with time-memory trade-offs. The attacker's gain is not devastating, but if we are to change our password hashing function then we may as well try to find one that fulfils its promises.
Such issues, and other information, can be found in this presentation. To summarize: while the ideas expressed in the scrypt design are quite interesting, the general feeling of cryptographers is that there should be more research; and, indeed, it prompted the PHC: an open competition, in the spirit of past efforts such as AES, SHA-3 or eSTREAM, where new candidates are proposed and reviewed.
If you deploy scrypt right now in production, then it should be reasonably strong, although it depends on the parameters you choose. That is the main conclusion of 5 years of research: the cryptography is sound, there is a time-memory trade-off which is not damning, but we don't have a lot of guidance on how to configure it in ways that will work well in typical servers.
