This is an implementation of the scrypt password hashing function. However, unless you have specific reasons to use scrypt, you should instead consider the default function Argon2.

Glossary

• opslimit: The maximum amount of computations to perform. Raising this number will make the function require more CPU cycles to compute a key.
• memlimit: The maximum amount of RAM in bytes that the function will use.

Guidelines for choosing scrypt parameters

Start by determining how much memory the scrypt function can use.

• What will be the highest number of threads/processes evaluating the function simultaneously (ideally, no more than 1 per CPU core)?
• How much physical memory is guaranteed to be available? The memlimit parameter should be a power of 2.

Do not use anything less than 16 MiB, even for interactive use. A reasonable starting point for opslimit is memlimit / 32. Measure how long the scrypt function needs to hash a password. If this is way too long for your application, reduce memlimit and adjust opslimit using the above formula. If the function is so fast that you can afford it to be more computationally intensive without any usability issues, increase opslimit. For online use (e.g. logging in on a website), a 1 second computation is likely to be the acceptable maximum. For interactive use (e.g. a desktop application), a 5 second pause after having entered a password is acceptable if the password doesn't need to be entered more than once per session. For non-interactive and infrequent use (e.g. restoring an encrypted backup), an even slower computation can be an option. However, the best defense against brute-force password cracking is to use strong passwords. Libraries such as passwdqc can help enforce this.

Notes

Do not use constants to verify a password or produce a deterministic output. Save the parameters alongside the hash instead. By doing so, passwords can be rehashed using different parameters if required later on.

By design, a password whose length is 65 bytes or more is reduced to SHA-256(password). This can have security implications if the password is present in another password database using raw, unsalted SHA-256 or when upgrading passwords previously hashed with unsalted SHA-256 to scrypt.

It is highly recommended to use lock to lock memory regions storing plaintext passwords and to call unlock right after cryptoPWHashScryptSalsa208SHA256Str and cryptoPWHashScryptSalsa208SHA256StrVerify return.