6

What should I use as a secure/strong salt for PBKDF2 hashing when salt is not available to use before login as it will be client-side javascript to hash user+pass with PBKDF2 ? I'm going to use sha(user+pass) as salt for pbkdf2.

If I use a random generated salt, I should store it in DB, but when user wants to login, user won't have salt to encrypt his password with salt before sending it to server for verification.

So what's good/safe/secure solution here? P.S. I'm trying to achieve "zero knowledge" protocol. Also I am already using SSL.

JustACPPFan
  • 99
  • 1
  • 6

1 Answers1

7

First, make sure you read this answer to the question "Client side password hashing", paying particular attention to the last paragraph.

Also, please realize that client side javascript is going to be incredibly slow at PBKDF2 compared to good server side code. At least try to find a PBKDF2 implementation that uses HMAC-SHA-512 as a base.

That said, if you want to give the user peace of mind, that's fine; do the following:

  • Client side PBKDF2 hashing for a known, "high" iteration count.
    • Double bonus points if the user is allowed to select the iteration count themselves!
    • I put high in quotes because I doubt your javascript code's going to be fast enough to do tens or hundreds of thousands of iterations in the time you can get enough of your user base to accept, particularly on cheaper mobile devices.
    • A good hash of the username and password as a salt isn't great, though it's better if your code pads the username out to the maximum possible length and puts it first.
      • That way, "user1" and "password" don't make the same salt as "user" and "1password"!
      • There is, of course, no maximum length on the password except what's caused by your back end software; SQL Server, for instance, has an 8000 byte maximum on "less inefficient" string work.
  • Send that hash by itself to the server
    • which then DOES generate a cryptographically random salt of 12-16 bytes
    • and then uses PBKDF2 with a much higher iteration count to hash the hash passed in
      • again hopefully HMAC-SHA-512 for the 64 bit operations to lessen the proportionate advantage of offline GPU attacks.
      • because then someone who gets your leaked password database still has to do the work of an attack against a password hashing function to log in, rather than simply sending the client-generated hash they stole and having it be accepted as-is.

Remember with PBKDF2 password hashing in particular, never ask for an output size larger than the native base hash's output size. Smaller is all right if you're really, really concerned about storage; for instance, requesting only 32 bytes of PBKDF2-HMAC-SHA-512's native 64 byte output.

  • 20 bytes for SHA-1
  • 32 bytes for SHA-256
  • 64 bytes for SHA-512
Community
  • 1
Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
  • Thank you, you deserve your username! So in short, I'm going to pad username with lets say 0x90909090 (will be constant) for max. salt length. Then I'll use user's password and padded salt to generate 64 bytes of SHA512 PBKDF2 with min of 5000 iterations. User will be able to set iterations during account creation and in settings page. In server I'll also additionally PBKDF2 (SHA512) 5000 times hash sent by user and store (during creation) and check (login) with my entry in DB. Also in server during creation I'll assign a user specific salt so I can use for server side PBKDF2. Approve? – JustACPPFan Jan 11 '15 at 21:36
  • P.S. I'll have a fast JS library for PBKDF2 and SHA512, I already have something for it. – JustACPPFan Jan 11 '15 at 21:41
  • To clarify, you're not padding username for max salt length, you're padding username to the maximum allowable username length before you concatenate the password for the client side salt, i.e. the salt is HASH(LEFT(username + 0x909090...90,UsernameLength)+password). Note that your zero knowledge protocol means the user's client side iteration count must be set on the client's browser, not in your database; perhaps a field on the login screen itself. If they can get the iteration count from the database, they can get the salt, and then you can use a real cryptographically random salt. – Anti-weakpasswords Jan 11 '15 at 22:26
  • Also, if you have a fast JS library for PBKDF2-HMAC-SHA-512 under an open source license, I'd like to try adding it to [my GitHub repository](https://github.com/Anti-weakpasswords), which also has a reasonable set of test vectors if you'd like to test your library. – Anti-weakpasswords Jan 11 '15 at 22:27
  • I'm using this: https://github.com/digitalbazaar/forge and all code you need (after script src stuff) is this: var key = forge.pkcs5.pbkdf2(userpass, username, 5000, 64, forge.sha512.create()); I tried output of it with other libraries (PHP PBKDF2 and CryptoPP) same output. I didn't really get your padding thing. What's max username length? It's user's email address? Should I really do padding and can you tell me who defines max. username length? It's just email address. – JustACPPFan Jan 12 '15 at 01:42
  • In your database, you store the username (email address). If you store it as a VARCHAR(28), then the max username length is 28. If you store it as VARCHAR(100), the max length is 100. You pad it to the maximum possible saved database length so that "user1" "password" and "user" "1password" don't end up with the same salt, HASH("user1password")! IF you had length 8 usernames max, it'd end up as HASH("user1...password") and HASH("user....1password") respectively, with "." representing your padding character. – Anti-weakpasswords Jan 12 '15 at 02:30
  • Thank you, just one final question, does it matter what character I use for padding? I'm going to use 0x90 – JustACPPFan Jan 14 '15 at 03:29
  • Any particular reason? [HMAC](https://www.ietf.org/rfc/rfc2104.txt) uses 0x36 repeated and 0x5b repeated for ipad and opad; as for why, the simple answer's in [Why does hmac use two solid pad paramaters?](https://stackoverflow.com/q/19195900); it boils down to: it doesn't matter materially at this point in time. – Anti-weakpasswords Jan 15 '15 at 04:19