I've been trying to look for the answer, but the latest one I found was outdated by three years. So what are the recommended scrypt cost factors for 2016?

  • 2
    The recommended cost factors = "Use Argon2"?
    – SEJPM
    Commented Apr 29, 2016 at 12:39
  • What? I'm not sure I understand what you're saying.
    – Awn
    Commented Apr 29, 2016 at 15:22
  • 1
    Not sure if this'd be the correct thought process, but I'd think to use moore's law and assume that since 2^3 = 8, so at least 8x the 2013 estimates you found. Commented May 11, 2016 at 19:10
  • Moore's law is to do with transistors on a chip, not with the speed of computation.
    – Awn
    Commented May 15, 2016 at 12:19

1 Answer 1


In general, use the maximum cost factor that is bearable from a performance perspective. I would create a benchmark application which is as close as possible to what your application does, and find out the cost factor on your production hardware that gives you the maximum tolerable delay.

In most systems, I strive for a 10 to 20 ms delay. Assume your attacker has hardware that is, say, 1000 times more powerful than yours (which is not unreasonable, given that scrypt cannot be GPU-accelerated), he can try 105 guesses per second. For a 10-character alphanumeric password, that's 2610 passwords, or about 1014 potential guesses. That would take 109 seconds, or 31 years. Sounds acceptable to me.

If you want to use even higher delays, remember that scrypt is memory hard. This means it uses a (relative) lot of memory, in the order of megabytes, for each verification, so having a lot of them running in parallel might be more of a performance hit than the absolute processing power required.

Have a look at Security.stackexchange.com "Recommended # of iterations when using PKBDF2-SHA256?" for a good analysis of the same subject on PBKDF2.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .