Use case, which brought me, a normal human developer, to js-scrypt based signin, where any passphrase would open any account.
Context:
- js-scrypt must be run in web-worker, for all usability concerns
- passing of arrays between worker and main is done by no-copy transfer of buffer
- it is really easy to forget that bytes are passed as buffers, rather than typed array
Problem:
when scrypt.crypto_scrypt(pass, salt, n, r, p, 32) is given buffers for pass and salt, it silently produced always the same output. That is, all new users get the same key, and any account may be opened with any passphrase, with no indication of a problem.
Argument:
Yes, javascript is lousy with types. Yes, this is a developer's problem. Yes, check is messy (5 lines, including throwing up).
But, as Daniel J. Bernstein pointed in his talk, developers of crypto libraries should stop blaming users of these libraries (e.g. developers) for reproducing "obvious" mistakes.
Actually, adding something like
if (pass.BYTES_PER_ELEMENT !== 1) { throw new TypeError("bla"); }
shall be enough. Same line for salt.
Use case, which brought me, a normal human developer, to js-scrypt based signin, where any passphrase would open any account.
Context:
Problem:
when scrypt.crypto_scrypt(pass, salt, n, r, p, 32) is given buffers for pass and salt, it silently produced always the same output. That is, all new users get the same key, and any account may be opened with any passphrase, with no indication of a problem.
Argument:
Yes, javascript is lousy with types. Yes, this is a developer's problem. Yes, check is messy (5 lines, including throwing up).
But, as Daniel J. Bernstein pointed in his talk, developers of crypto libraries should stop blaming users of these libraries (e.g. developers) for reproducing "obvious" mistakes.
Actually, adding something like
if (pass.BYTES_PER_ELEMENT !== 1) { throw new TypeError("bla"); }
shall be enough. Same line for salt.