Fairy tales in password hashing with scrypt
vnhacker.blogspot.com
vnhacker.blogspot.com
I gave him a toolbox which contained a screwdriver and a hammer, and he seems to be complaining that the screwdriver isn't very good at hammering nails.
I found the mistakes in other people's code, so I didn't complain for myself.
Taking a look at the distribution, I can imagine being confused, as there's nothing to indicate that crypto_scrypt is what you want to be using.
Remember, not everyone who uses your library is a security expert, or will spend the time to read all of the code; they may be someone who has heard "you should use scrypt, it's the strongest readily available password hashing function", so they downloaded it and built it, but may not know where to go from there, so they take the most visible code, main.c, and use that as their example starting point.
Here's an example of something you could write in a top-level README to make this a little more clear. Feel free to use if you feel like, or reword as necessary. The main point is just to point people who are looking for a password hashing function to the right place, as that is what a lot of people looking at this may be looking for, and may not find immediately from the example given.
This project provides the scrypt utility for performing password based symmetric
encryption, as well as libscrypt for using the functionality in your own software.
See scrypt.1 for details on use of the scrypt encryption utility.
libscrypt implements the scrypt PBKDF, which can be used to derive a symmetric
encryption key for a password, or can be used as a password hashing function for
storing hashed passwords in a form that will make them more difficult to guess via
brute force.
To encrypt and decrypt files or buffers using a symmetric cipher with a key derived
using the scrypt PBKDF, use the functions declared and documented in
lib/scryptenc/scryptenc.h.
To implement a password hash, or use the scrypt PBKDF directly to derive a key for
some other purpose such as use with a different symmetric cipher, use crypto_scrypt
defined in lib/crypto/crypto_scrypt.hYou mean the code which is labeled on the website as "A simple password-based encryption utility is available as a demonstration of the scrypt key derivation function"?
Remember, not everyone who uses your library is a security expert, or will spend the time to read all of the code
I know people won't read all the code... but you'd think that people would at least read the comment directly above the function prototype
* Encrypt inbuflen bytes from inbuf, writing the resulting inbuflen + 128
* bytes to outbuf.
sigh
I've added a warning to the top of scryptenc.h which will hopefully help to point people in the right direction.
You mean the code which is labeled on the website as "A
simple password-based encryption utility is available as
a demonstration of the scrypt key derivation function"?
The additional note is definitely helpful; I still think it would be good to put something at the top level which points people in the right direction.
As is, if someone wants to figure out what to do for password hashing, they have no documentation at the top level. The most promising thing to try, main.c, just uses the encryption functions. If they then jump to the definitions, your note is over 50 lines above the declaration of scryptenc_file, well outside of what will normally show up in their editor window. Yeah, they will probably have to scroll up a little to find the definitions of parameters and return values, but it's possible to do that and miss the note.
I know, people should read the whole documentation, but it's probably easier to just point them in the right direction from the start than to convince people to read the full documentation.
This is a good test to write: create two users, and see if one can log in using the other's password. (There are lots of ways this could go wrong, not only by using a 0-length password.) Basically, if you don't want something to happen, write a test that fails when it does.
Yes! User testing is often ignored even by application developers who should really know better; it's practically unheard of to perform user testing on APIs, but it makes so much sense. The world would be a better place.