Skip to main content
Information Security

Return to Answer

deleted 2 characters in body
Source Link
Scott Pack
Scott Pack
  • 15.4k
  • 6
  • 64
  • 91

  1. No, you're still too small. OWASP Password Storage Cheat Sheet recommends 64,000 PBKDF2 iterations in 2012 and doubling them every 2 years (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet).

  2. See the other answers above.

  3. You do have the option of doing some hashing client-side (say, 2,000 PBKDF2_SHA-1 rounds), and then once the result of that gets to the server, run it through another large set of hashing (say, 300,000 rounds of PBKDF2_SHA-512), and compare that final value.

Your database stores only the final double-PBKDF2 value.

Your web log files and/or possibly weak SSL sessions use the intermediate single-PBKDF2 value. While that intermediate value is certainly much, much weaker than the final value, it's still quite a lot stronger than cleartext.

Note that you also need to check passwords users propose when changing their password/selecting a new passwords against a normal cracking dictionary with some rules (lowercase both to eliminate case games, add numbers from 1 to 1000 after the word, add dates after a word, basic 1337 speak translations, etc.) to prevent the "strong" password "P@$$w0rd" (upper case, lower case, symbols, and numbers - 8 characters long, it must be really strong!) from showing up.

  1. No, you're still too small. OWASP Password Storage Cheat Sheet recommends 64,000 PBKDF2 iterations in 2012 and doubling them every 2 years (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet).

  2. See the other answers above.

  3. You do have the option of doing some hashing client-side (say, 2,000 PBKDF2_SHA-1 rounds), and then once the result of that gets to the server, run it through another large set of hashing (say, 300,000 rounds of PBKDF2_SHA-512), and compare that final value.

Your database stores only the final double-PBKDF2 value.

Your web log files and/or possibly weak SSL sessions use the intermediate single-PBKDF2 value. While that intermediate value is certainly much, much weaker than the final value, it's still quite a lot stronger than cleartext.

Note that you also need to check passwords users propose when changing their password/selecting a new passwords against a normal cracking dictionary with some rules (lowercase both to eliminate case games, add numbers from 1 to 1000 after the word, add dates after a word, basic 1337 speak translations, etc.) to prevent the "strong" password "P@$$w0rd" (upper case, lower case, symbols, and numbers - 8 characters long, it must be really strong!) from showing up.

  1. No, you're still too small. OWASP Password Storage Cheat Sheet recommends 64,000 PBKDF2 iterations in 2012 and doubling them every 2 years (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet).

  2. See the other answers above.

  3. You do have the option of doing some hashing client-side (say, 2,000 PBKDF2_SHA-1 rounds), and then once the result of that gets to the server, run it through another large set of hashing (say, 300,000 rounds of PBKDF2_SHA-512), and compare that final value.

Your database stores only the final double-PBKDF2 value.

Your web log files and/or possibly weak SSL sessions use the intermediate single-PBKDF2 value. While that intermediate value is certainly much, much weaker than the final value, it's still quite a lot stronger than cleartext.

Note that you also need to check passwords users propose when changing their password/selecting a new passwords against a normal cracking dictionary with some rules (lowercase both to eliminate case games, add numbers from 1 to 1000 after the word, add dates after a word, basic 1337 speak translations, etc.) to prevent the "strong" password "P@$$w0rd" (upper case, lower case, symbols, and numbers - 8 characters long, it must be really strong!) from showing up.

Source Link
More than one round of PBKDF2
More than one round of PBKDF2
  • 11
  • 1

  1. No, you're still too small. OWASP Password Storage Cheat Sheet recommends 64,000 PBKDF2 iterations in 2012 and doubling them every 2 years (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet).

  2. See the other answers above.

  3. You do have the option of doing some hashing client-side (say, 2,000 PBKDF2_SHA-1 rounds), and then once the result of that gets to the server, run it through another large set of hashing (say, 300,000 rounds of PBKDF2_SHA-512), and compare that final value.

Your database stores only the final double-PBKDF2 value.

Your web log files and/or possibly weak SSL sessions use the intermediate single-PBKDF2 value. While that intermediate value is certainly much, much weaker than the final value, it's still quite a lot stronger than cleartext.

Note that you also need to check passwords users propose when changing their password/selecting a new passwords against a normal cracking dictionary with some rules (lowercase both to eliminate case games, add numbers from 1 to 1000 after the word, add dates after a word, basic 1337 speak translations, etc.) to prevent the "strong" password "P@$$w0rd" (upper case, lower case, symbols, and numbers - 8 characters long, it must be really strong!) from showing up.