Skip to main content
Information Security

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

6
  • 5
    Are you seriously suggesting to use only two or three PBKDF2 iterations for password hashing? The minimum more than 10 years ago was 1000 and now days that is considered severely insufficient! I seriously suggest you re-think your answer. Do not suggest that users store passwords with "two or three" fast hash iterations. Commented Feb 10, 2018 at 22:46
  • Please see also security.stackexchange.com/q/211/165253 and security.stackexchange.com/q/3959/165253. Commented Feb 10, 2018 at 22:58
  • First of all, my initial suggestion was to use another algorithm. Sha is not suitable for this kind of operations anymore. But if the person asking really wants to use sha only, what's the point of 100.000 iterations? Better use a hybrid WITH sha instead of spending resources to do that... And it's also better to take a look at the security implementations used for input filtering and validation if we are talking about exposing credentials and other information. Commented Feb 11, 2018 at 10:56
  • 3
    The point of spending valuable resources is that the attacker must spend those valuable resources too when he's trying to brute-force the password. Commented Feb 11, 2018 at 18:02
  • 2
    The point is that 100,000 iterations makes it 100,000x harder for them to brute force a hashed password, but only takes a fraction of a second for you to hash. It's a very common and highly effective technique for password strengthening. SHA256 is completely fine for password hashing as long as you use something like PBKDF2 (though it won't be as memory-hard as something like scrypt). Commented Feb 12, 2018 at 1:42