5

I am building an application that needs to locally store sensitive data, that is encrypted using the SHA-256 of a password provided by the user. It uses AES for encryption.

I am worried that some users may choose to use a weak password, that could be brute-forced by an attacker that gets that file and wants to read the content.

I am thinking that, in order to get the hash, a nonce must be appended to that password, and the first nonce for which the hash has the first X bits set to zero, that's the key that must be used. If X is set to 20, around 1 million hashes should be calculated in average to get the valid key from the password provided by the user.

This way the user might take 1 second to calculate the key (depending on their machine), making it extremely harder to brute-force it by guessing passwords.

Of course, this is something I came up with, and I guess that's why I shouldn't use it. Is there any widely tested alternatives for this?

Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65
Nathan Parker
  • 257
  • 2
  • 9

1 Answers1

16

.. encrypted using the sha256 of a password provided by the user.

You should not use a simple hash to create the key from the passphrase. These hashes are optimized for speed and thus brute-forcing is possible. Instead you should use proven key derivation functions like PBKDF2 or similar. See the Wikipedia article about Key Derivation Functions for more details.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Note that PBKDF2 is relatively weak. I'd consider using Argon, scrypt or bcrypt instead. Each of them has its own advantages. I'd probably go with scrypt myself, since it's only enough to have some confidence it it, while combined with significantly better cost ratio between attacker and defender than bcrypt or PBKDF2. – CodesInChaos Nov 03 '15 at 16:45
  • @CodesInChaos Thank you! I will have a look at scrypt. But why is PBKDF2 weak? – Nathan Parker Nov 03 '15 at 17:13
  • @NathanParker, The Wikipedia article on PBKDF2, to which he linked, explains it's weakness quite well. – tjd Nov 03 '15 at 17:20
  • While scrypt _can_ have a higher time/memory trade-off, making it harder to brute force using specialized hardware, in reality these gains are only seen in blockchain proof-of-work systems, such as found in cryptocurrencies, where the difficulty is based on the reality of users brute forcing solutions. On an authentication server, the difficulty is based on the capabilities of one machine, which almost always is _not_ using GPU acceleration, thus is always weaker than any attacker who does use specialized hardware. – Ghedipunk Nov 03 '15 at 17:21
  • I'm not saying scrypt is bad. I'm just saying that it's not a holy grail for KDF, and gives no real gains above PBKDF2 or bcrypt. – Ghedipunk Nov 03 '15 at 17:22
  • @Ghedipunk In my opinion it's the other way round. Scrypt works well for KDFs where you can afford ~1 second of computation time. It doesn't really work well as proof-of-work for crypto-currencies since there even a small advantage for specialized hardware is good enough to prevent CPU miners from competing. – CodesInChaos Nov 03 '15 at 20:14