

Fairy tales in password hashing with scrypt - helper
http://vnhacker.blogspot.com/2014/04/fairy-tales-in-password-hashing-with.html

======
cperciva
I'm confused. Why is he using scryptenc_buf when crypto_scrypt does what he
wants?

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.

~~~
lambda
Maybe because people frequently reference scrypt as a password hashing
function, but when you download the source and look in the top level, what you
get is an example of an encryption utility and no documentation other than a
man page for said encryption utility?

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.h

~~~
cperciva
_Maybe because people frequently reference scrypt as a password hashing
function, but when you download the source and look in the top level, what you
get is an example of an encryption utility and no documentation other than a
man page for said encryption utility?_

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"?

 _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.
    

and realize that this doesn't even sound remotely like what they were looking
for.

 _sigh_

I've added a warning to the top of scryptenc.h which will hopefully help to
point people in the right direction.

~~~
lambda

      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"?
    

Think of this from the perspective of someone who's looking for a password
hashing function. Remember that a lot of people are fairly unclear on the idea
of password hashing vs. encryption; lots of people say things like "the
password database was encrypted" when they mean "the password database was
hashed." For someone who is a bit fuzzy on the idea, but has been pointed to
scrypt as the solution for secure password storage, they may just think "oh,
it encrypts the passwords, OK" and go ahead and use the encryption functions.

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.

------
jrockway
> Anyone could sign in to anybody else's accounts using any passwords.

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.

------
tveita
There's a password hashing competition going right now that will hopefully
result in some more state-of-the art primitives available through a suitable
interface.

[https://password-hashing.net](https://password-hashing.net)

------
modeless
> If I develop a crypto library, I'll conduct user studies like how they do it
> in usability research. Give developers the library and ask them to conduct a
> specific task. Rinse and repeat until nobody would misuse it.

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.

