2

I am creating a web app, and I was wondering if it would be secure to use 100,000 iterations of sha256 for storing passwords? I know that there are algorithms such as scrypt and bcrypt, however, I was wondering if it would be feasible to use 100,000 iterations of sha256 for password storage.

I am a complete newbie, and help would be much appreciated.

Matt
  • 29
  • 1
  • 2
  • 2
    Even if you are salting there will still be other issues with using just SHA256 – jrtapsell Feb 10 '18 at 20:54
  • 1
    Am I right that you are using no salt? In the case the same password for different users results in the same hash no matter how many iterations you use which is not what a proper password hash should do. – Steffen Ullrich Feb 10 '18 at 21:31
  • Note that iterative hash functions and PBKDF2 are different. PBKDF2 mitigates some attacks that multiple hash rounds don't. – forest Feb 11 '18 at 04:25
  • Any question about whether some security is "good enough" should be qualified by what you're trying to secure with it. – David Conrad Feb 12 '18 at 16:10

4 Answers4

4

To answer the title: no.

Your question's premise is incorrect in the first place. Repeated iterations of SHA256 is not a suitable algorithm for password storage.

You should use Argon2 if your language has an available binding. If you're using PHP you can use the inbuilt password_hash function with the PASSWORD_ARGON2I flag. For .NET applications there's a fully managed implementation available. There's a binding available for Java too. There's a fantastic article from Paragon about storing passwords safely, which has example code for a bunch of languages.

If you absolutely cannot use Argon2, although I see no reason why you couldn't (there are bindings for almost every language now!), then you should use scrypt, bcrypt, or PBKDF2-SHA256, in that order of preference. Again almost every language has bindings or libraries for these.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
4

Let's break the question down into two elements:

1) Is using 100,000 iterations good enough for password storage?

It depends! You should always use as high an iteration count/work factor as your system can handle with reasonable responses, understanding that your side will be single-threaded (hashing the one provided password), while the attacker will be parallel (trying many possible passwords simultaneously).

So, determine how much time you can afford to spend on each hash; if your rules is the hashing can take no more than 1/10th of a second, and you expect 16 logins per second on an 8 core box, then the hash iteration count/work factor should take 1/20th of a second.

2) Is using SHA-256 good enough for password storage?

By itself, no. As part of a construct including a salt, yes, absolutely. The construct you're looking for that uses SHA-256 is PBKDF2-HMAC-SHA-256, which uses iterations of HMAC-SHA-256, which is simply HASH(Key XOR opad, HASH(Key XOR ipad, text)) where ipad and opad are fixed values (sized for SHA-256).

PBKDF2 (RFC2898) iterates them as such: 

           U_1 = PRF (P, S || INT (i)) ,
           U_2 = PRF (P, U_1) ,
           ...
           U_c = PRF (P, U_{c-1}) .

It is important to note that the HMAC construct is the PRF.

Answer: Yes, if you use PBKDF2-HMAC-SHA-256 with 100,000 iterations AND you can't fit more into the time available

You can find a variety of PBKDF2 implementations at my Github repository, including a variety of languages and from-scratch implementations as well as OpenSSL and PolarSSL and other library based implementations, including test vectors.

Please compare the speed of whatever you write and whatever else is available to you - for secure password hashing you must use your fastest implementation

Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
1

Which algorithm?

See: How to securely hash passwords?

How many iterations?

See: Parameters for PBKDF2 for password hashing

Luc
  • 31,973
  • 8
  • 71
  • 135
  • 3
    You can do better than this. – Polynomial Feb 12 '18 at 12:28
  • @Polynomial Well it's a duplicate question, but I feel like yet another comment would go unnoticed, and with newlines it's easier to read and find the answer you're looking for. I think this should answer OP's question as well as future visitors'. – Luc Feb 12 '18 at 13:23
  • You could at least expand on the contents of the links a little. Even a relevant quote from each would be better than this. – Polynomial Feb 12 '18 at 14:46
-5

You could do that, but honestly, what's the gain? You will spend lots of valuable resources to do that, in any kind of implementation I can think of. Plus, after some thousand iterations, you won't really get much in terms of safety. If you want to use sha do a nice implementation with unique salt for each user and maybe hash again two or three times if that makes you feel more secure. Βut there is no need for more iterations. After that, you either use a better algorithm, or get to improve more aspects of your security implementations.

Chris Tsiakoulas
  • 1,757
  • 1
  • 9
  • 9
  • 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**. – forest Feb 10 '18 at 22:46
  • Please see also https://security.stackexchange.com/q/211/165253 and https://security.stackexchange.com/q/3959/165253. – forest Feb 10 '18 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. – Chris Tsiakoulas Feb 11 '18 at 10:56
  • The hole point is to not let someone get the information you want to store/hash/hide. If they do, you 're doomed. Given time and resources, they will get the information they want and there are not many things you can do about it. – Chris Tsiakoulas Feb 11 '18 at 11:02
  • 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. – FINDarkside Feb 11 '18 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). – forest Feb 12 '18 at 01:42