Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
One issue with scrypt is that it has data dependent RAM access, which can lead to side-channel attacks in some scenarios. Not sure how realistic those scenarios are, and if the attack can be mitigated by randomizing memory access. –  CodesInChaos Sep 26 '13 at 16:24
    
I'm not sure time has tested scrypt much. I think there aren't many cryptographers who tried to break it. –  CodesInChaos Sep 27 '13 at 8:11
add comment

3 Answers

up vote 12 down vote accepted

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).

share|improve this answer
5  
Everyone paying close attention to the Password Hashing Competition expects that Colin Percival will be submitting a revision of scrypt. –  Jeffrey Goldberg Sep 26 '13 at 5:16
    
IMO one big practical problem with scrypt is that it doesn't use enough RAM under the time constraints on a typical server. –  CodesInChaos Sep 27 '13 at 8:10
add comment

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.

share|improve this answer
    
I've been using scrypt for a couple of years based on this logic. –  Numina Solutions Sep 26 '13 at 16:10
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.