Verifying password

[lewispham]

How can I verify password hashed by scrypt-async? How is scrypt-async hash different from node-scrypt hash? Are they compatible?

[evilaliv3]

@tresdin:

1. to verify a password hashed by scrypt-async you should recalculate the scrypt hash and see if it maches the one that you stored.
2. yep aside from bugs in the implementation they should be compatible.

[lewispham]

@evilaliv3 I wonder if there would be any standard instruction or specification for password verification in scrypt. Because in bcrypt, this task is complicated. You can see this post for more details.

[dchest]

@tresdin there were attempts to make a universal text encoding for scrypt (params + salt + hash), but so far there are many different implementations. All you need is just to store this information:

{
   logN: ..., // or N
   r: ...,
   p: ..., // always 1 for scrypt-async-js
   salt: ..., // possibly base64 encoded
   hash: ...,  // possibly base64 encoded
}

To verify, read parameters and salt from storage, generate a new hash with the password you're trying to verify and compare to the stored one.

[lewispham]

@dchest Since derived key length is a required parameter in scrypt-async, do I need to include it into hash string? And also, what is p parameter? Why is it so important? Or do you have any source that explains these params?

[dchest]

Ah, true, if you ever want to change the hash length, save it. But I'd just fix it to 32 (if you don't need more derived keys for other purposes). P is parallelization parameter: it tells how many parallel instances to calculate in order to fill more CPU cores. It's fixed to 1 in scrypt-async-js for simplicity (and because apart from web workers JS doesn't parallelize).

The source is the original scrypt paper: https://www.tarsnap.com/scrypt/scrypt.pdf

[lewispham]

I used to be stuck with picking between scrypt and bcrypt for password hashing because of this issue. I think it's no longer a problem to me. Thank you so much @dchest .