What about salt?

[fresheneesz]

In the documentation (readme), its very clear that a salt is definitely needed for secure password hashing. However, when it comes to the actual API, I don't see anything about salt. The parameters I ses are:

scrypt.passwordHash(password, maxtime, maxmem, maxmemfrac, callback);

The way I understood it, maxtime, maxmem, and maxmemfrac are parameters that determine something about how to hash the password, but the machine's own capabilities are factored into how exactly the password is hashed. I would have assumed that you would use these factors to create a salt, which you then hash with, but it doesn't look like thats how this API is structured.

This ruby scrypt library seems to do what I would expect (allow you to create an appropriate salt, then hash with it later): https://github.com/pbhogan/scrypt

How can I create the same hash (or verify a hash) on multiple non-identical machines reliably? I want to be able to store a user's password hash next to the salt in th database (which seems like the standard setup). How do I do this with node-scrypt?

[fresheneesz]

Ah, things are clearer now because of these: http://stackoverflow.com/questions/277044/do-i-need-to-store-the-salt-with-bcrypt http://stackoverflow.com/questions/10778117/nodejs-bcrypt-library

Apparently the salt is stored inside the "hash". IE really the hash is salt + hash, and it separates the two out and uses them appropriately when checking the password. Nice.

[barrysteyn]

Yes, you can also just look at the source code to see this, but if I'm not mistaken, I did mention that salt is added to the hash automatically in the documentation On 2013-07-11 11:04 PM, "fresheneesz" notifications@github.com wrote:

Ah, things are clearer now because of these:

http://stackoverflow.com/questions/277044/do-i-need-to-store-the-salt-with-bcrypt http://stackoverflow.com/questions/10778117/nodejs-bcrypt-library

Apparently the salt is stored inside the "hash". IE really the hash is salt + hash, and it separates the two out and uses them appropriately when checking the password. Nice.

— Reply to this email directly or view it on GitHubhttps://github.com/barrysteyn/node-scrypt/issues/8#issuecomment-20855941 .

[fresheneesz]

I believe you are mistaken. I explicitly looked for the word salt in the documentation before creating this issue. The word salt is only mentioned in the criteria for a good password storage scheme.

[barrysteyn]

Hi

I have bolded the part where I mention it. Please RTFM.... :)

<<

Password key derivation requires three properties:

• The password must not be stored in plaintext. (Therefore it is hashed).
• The password hash must be salted. (Making a rainbow table attack very difficult to pull off).
• The salted hash function must not be fast. (If someone does get hold of the salted hashes, their only option will be brute force which will be very slow).

This scrypt library automatically handles the above properties.

On Sun, Jul 14, 2013 at 2:49 PM, fresheneesz notifications@github.comwrote:

I believe you are mistaken. I explicitly looked for the word salt in the documentation before creating this issue. The word salt is only mentioned in the criteria for a good password storage scheme.

— Reply to this email directly or view it on GitHubhttps://github.com/barrysteyn/node-scrypt/issues/8#issuecomment-20941355 .

[fresheneesz]

Saying scrypt handles the above properties doesn't give enough confidence to the security-minded individual. I strongly recommend explicitly saying that the salt is appended to the hash inside scrypt's result (what the documentation currently calls a "hash"). Scrypt is a useful library, but it is far less useful if developers with less perseverance than my own find the documentation confusing or incomplete. RTFM isn't a solution when the manual makes things hard to read or find.

My recommendation:

• Use different words for the salt, hash (actual raw result of hashing the password+salt), and scrypts final result (hash+salt) - so a phrase like "scrypt token"
• In the documentation for passwordHashSync, say explicitly something like "returns an scrypt token which contains a hash and the salt". Similarly for passwordHash.

I'm happy to amend your docs if you're inclined to accept an amendment like this.

[barrysteyn]

Hi

Yes, please amend the documentation. I would be more than happy to accept any help. And thank you in advance.

Barry

On Sun, Jul 14, 2013 at 6:54 PM, fresheneesz notifications@github.comwrote:

Saying scrypt handles the above properties doesn't give enough confidence to the security-minded individual. I strongly recommend explicitly saying that the salt is appended to the hash inside scrypt's result (what the documentation currently calls a "hash"). Scrypt is a useful library, but it is far less useful if developers with less perseverance than my own find the documentation confusing or incomplete. RTFM isn't a solution when the manual makes things hard to read or find.

My recommendation:

• Use different words for the salt, hash (actual raw result of hashing the password+salt), and scrypts final result (hash+salt) - so a phrase like "scrypt token"
• In the documentation for passwordHashSync, say explicitly something like "returns an scrypt token which contains a hash and the salt". Similarly for passwordHash.

I'm happy to amend your docs if you're inclined to accept an amendment like this.

— Reply to this email directly or view it on GitHubhttps://github.com/barrysteyn/node-scrypt/issues/8#issuecomment-20945569 .

[fresheneesz]

Here's my edit: https://github.com/barrysteyn/node-scrypt/pull/10 . I decided to call it the Scrypt hash-token and made sure the documentation consistently used that term. I also combined a lot of duplication that was in the documentation to make it easier to understand the whole thing as well as being easier to scan for specific things. Let me know what you think.

[fresheneesz]

This morning I thought of the term "salty hash". Dyou hink its better than "hash-token" ? Or is it too silly?

[barrysteyn]

Hi

Today I promised to push out a change to the library regarding SunOS compatibility. I will look at your changes sometime this week. Perhaps we can have a google chat whereby I can ask you some questions about your terms (I must admit, I have not had time to look at your changes).

I want to thank you in advance for contributing to this project. Unfortunately you have caught me at a particularly busy stage in my life, but I don't want you to be discouraged by me taking my time to review your documentation. Its only because I am working towards a deadline for one company, I am interviewing at another, I am co-owner of a third (all the way in South Africa) and I have code changes which I promised I would pump out for this project today.

So I am snowed under :)

Barry

On Tue, Jul 16, 2013 at 1:10 PM, fresheneesz notifications@github.comwrote:

This morning I thought of the term "salty hash". Dyou hink its better than "hash-token" ? Or is it too silly?

— Reply to this email directly or view it on GitHubhttps://github.com/barrysteyn/node-scrypt/issues/8#issuecomment-21057284 .

[fresheneesz]

Sure no problem. I'm in no rush. As a matter of fact, I'm waiting on windows support to use scrypt in full. Let me know when you want to chat

[barrysteyn]

I am actually looking for someone to collaborate on the windows port. My windows knowledge only goes back to XP, and I have not used it for years. So it would be appreciated if you could help me out.

I have an idea how to code it, I just need someone to test it (and I am too lazy to setup a VM - and I would like someone who knows/uses windows to look at it over).

What do you say?

On Tue, Jul 16, 2013 at 10:45 PM, fresheneesz notifications@github.comwrote:

Sure no problem. I'm in no rush. As a matter of fact, I'm waiting on windows support to use scrypt in full. Let me know when you want to chat

— Reply to this email directly or view it on GitHubhttps://github.com/barrysteyn/node-scrypt/issues/8#issuecomment-21088826 .

[fresheneesz]

I'd be game to test it for you. I'm a little busy myself tho, so depends how much time it takes up how quickly I can test.