3

Five years ago, an extremely similar question was asked: has scrypt withstood the test of time. Since this was asked five years ago and some of the responses were mixed, such as:

"Scrypt has mostly survived." or "Everyone paying close attention to the Password Hashing Competition expects that Colin Percival will be submitting a revision of scrypt." or even "scrypt is only as good as existing iterative hash composition techniques".

Of course, with Moore's law, scrypt could be weaker or stronger (due to revisions) than it was stated five years ago.

So my question(s) are:

  • Is scrypt still secure?
  • Is scrypt better than bcrypt for password hashing?
    • schroeder
    • 123,438
    • 55
    • 284
    • 319
    Name of Names
    • 41
    • 3

    1 Answers1

    2

    Yes. Scrypt can be used securely. There are two sources of potential security problems: weaknesses in the algorithm design and errors in the implementation.

    The design of scrypt is relatively simple, so implementation errors will be the only thing that could shock us at this point.

    (Issues like buffer overflows, parsing mistakes, or use-after-free bugs. These are things to look out for, but they're not things particular to password hashing code. You are far more likely to find dangerous bugs in your operating system, web server, browser, or OpenSSL.)

    As for algorithm weakenesses, there is no question that scrypt is better than bcrypt or PBKDF2. There is just one problem that makes it unsuitable for basic web app authentication. It was designed to be a key derivation function used for file encryption. It's not flexible enough for other uses, where time or memory may be more scarce.

    That's why the password hashing competition was held. To improve upon scrypt. Developers should be incorporating Argon2 v 1.3 into new projects and should plan to make upgrades possible if they're curently using an older algorithm. (The only strong justification to consider using something else is if you're developing for a platform that inherently has extremely limited memory.)

    There is no need to panic if scrypt is being use correctly in certain projects. Encrypted data is safe if you used a strong password and a large enough iteration count. Encrypted data is also safe if you used a unique (single use) and unpredictable password, regardless of the iteration count.

    But what's bad about scrypt?

    • It has a single cost parameter. You cannot increase memory use without increasing run time.
    • It's time-memory-trade-off allows a password cracker to decrease memory. Cutting memory by a factor of n only increases run time by a factor of n.
    • It takes more time to fill memory than Argon2 (on existing x64 platforms).
    • It would be easier to improve scrypt cracking hash rates using specialized hardware than it would be to improve on Argon2 hash rates.

    So how do you use scrypt securely?

    • Make sure to set the iteration count high. Try to use a few gigabytes of memory.
    • Use randomly generated salts.
    • Use a trustworthy implementation. Not just any GitHub project. Keep up to date with security updates.
    • Design software such that you can increase parameters or migrate to a different hash algorithm.

    The above four points are also applicable to using Argon2, but it's safer to use more or less time and/or memory. The advice for selecting parameters that accompanies version 1.3 of the PHC Argon project is good.

    Future Security
    • 1,701
    • 6
    • 13
    • Why `takes more time to fill memory than Argon2` is bad? at the end it is preventing the parallelization, right? – kelalaka Sep 04 '19 at 20:35
    • 2
      @kelalaka No. If you double the number of cores your computer has, you double the throughput of any code which does not depend on memory (besides the L1 cache, for which there is one per core). There is, however, a maximum amount of read/writes that can be done through a single RAM controller. So if you write a program that writes a lot of bytes per second then doubling the number of cores would, at some point, not double throughput. Since RAM takes so much space compared to CPU cores, it's better for crackers to minimize how many independent RAM units they need. – Future Security Sep 04 '19 at 22:12
    • 2
      @kelalaka With current technology we can build small amounts of expensive, very fast memory (as with your PC's L1 cache) or very large amounts of cheap, slow memory (as with normal computer RAM). Say you can generate one block per `n` cores in the same time that it takes to update eight blocks of memory. If you built a `8 * n` core computer then you could compute 8 hashes in parallel. By bringing the time it takes to generate a block compared to time to update a block closer to 1:1, it better limits how much parallelism you can get from a single chip, even if memory use is (too) low. – Future Security Sep 04 '19 at 22:12
    • Some of these should definitely go into this nice answer. – kelalaka Sep 04 '19 at 22:14
    • 2
      @kelalaka Oh. There are multiple reasons and I could have lead with a simpler one. Every user of a password hash is going to have a maximum amount of time and maximum amount of RAM they can use. If *available_ram >> write_speed \* available_time*, then it would be beneficial to increase write_speed because it would raise cracker's costs without forcing the defender to use more time or buy faster hardware. (The cracker's cost here comes from power consumption which, for volatile memory, is related to *time \* memory*.) – Future Security Sep 04 '19 at 22:43