I've always heard that scrypt was better than bcrpyt... because of memory causing GPU a very difficult time to crack. However, the notion always was that scrypt hadn't been tested, it was kind of a new crypt method, and that I should wait it to be tested before using it.
Has that time come where people have made scrypt the new standard to use? or is it still in beta phase?
Scrypt has mostly survived. It is not bad; it just turns out that the touted advantages of scrypt over the competition (mainly bcrypt and PBKDF2) might not be as marvellous as first claimed. As always, it is a trade-off: like any password hashing function, its role is to make password hashing expensive for everybody, attackers and defenders alike. Scrypt uses a lot of RAM in order to force the attacker to use the same hardware as the defender (a PC). The bad point, though, is that it uses a lot of RAM.
See this presentation for some information on the present of password hashing. An open competition is being run, to obtain, publish and analyse new and hopefully better functions (currently in the phase of gathering candidates).
A fair bit of the inherent safety in scrypt is that it doesn't make any specific promises but is already effectively guaranteed to be at least as good as the existing alternatives.
So in the worst-case scenario, scrypt is only as good as existing iterative hash composition techniques. Since scrypt is, itself, an iterative composition technique, and since existing techniques are relatively naïve, it's difficult to imagine how scrypt could possibly be less secure than the alternative. Its safety in this sense is based on the fact that it's using well-established hashes in their recommended configuration.
In the best-case scenario, scrypt will also increase the price of any hardware you'd use for brute-forcing password hashes. By how much? No guarantee. The design goal is that hash-cracking devices will have to have a significant amount of dedicated RAM, which is the simplest way to either dramatically increase the amount of chip dye space that would have to go in to such a device, or dramatically limit the speed of the device, since memory is either very slow or very expensive.
But there's no metric for success, no specific attack to defend against. There's just a general "it probably makes the hardware more expensive" claim that is hardly a claim at all.
The primary downside, of course, is that it probably makes the hardware more expensive. Your hardware, this time. The design goal is to increase the cost of hashing, which means your computer will have to either cost more or perform worse that an equivalent setup with other hash strategies. If you don't understand what scrypt is for, then this can be a real problem.
With Thomas Pornin's most excellent answer in mind, one interim option is to use a mechanism that will thwart today's GPU-based cracking systems, but with the expectation of migrating to the results of the password hashing competition once those become available.
For example, using PBKDF2-HMAC-SHA512 will prevent cracking on today's GPUs by virtue of using SHA512. But this kind of measure should be seen only as a temporary approach. It is not a long term solution.
