0

I tried to find a similar question but I did not find a question describing my exact scenario and I am still puzzled if the following actually makes an application more secure.

I have legacy passwords stored with SHA1 and a common salt imported to my system. If the user logs in, I am able to rehash the password itself with a stronger algorithm - that's fine. But for the import I want to hash the SHA1-hash again with SHA256 (or better bcrypt) and an individual salt and afterwards remove the SHA1-hash - in my understanding this should increase the security as I increase entropy by adding an individual salt and using a stronger hashing algorithm. Is this correct or does the decreased entropy from SHA1 remain when doing this?

Christoph Sonntag
  • 101
  • 2
  • If you're going to migrate a password system to a stronger hashing, don't use SHA256. A cryptographic hash algorithm like SHA256 is not suitable for password hashing, because they're designed to be fast; password hashing need to be designed to be slow and have adjustable slowness so that it keeps up with improvements in computing power, like bcrypt/pbkdf2/argon. – Lie Ryan Jul 09 '19 at 10:10
  • You're right, thanks for the hint - but my question still remains - would hashing an SHA1-hash with e.g. bcrypt increase the security? – Christoph Sonntag Jul 09 '19 at 10:17
  • Steffen's linked question definitely answers this for you. Two quick notes though. Salts and hashes don't add entropy. Entropy is the degree of "randomness" in the final password hash, and neither of those add randomness. The salt, while random, doesn't practically add entropy because it is a value known to the attacker. Hashes don't add entropy because even though they look random, they aren't - they are deterministic algorithms. Also, do yourself a favor and use whatever password hashing algorithm is built into your language/framework. Don't implement things yourself. – Conor Mancone Jul 09 '19 at 11:07

1 Answers1

-1

As far as I can tell, there should not be any reduction in security to what you're doing as long as this are only applied to the legacy passwords. New passwords and users that have logged in should just use the new hashing system without going through SHA-1 first.

Passwords migrated from the legacy system in such a way will be at least as good as the old system. The use of SHA-1 means that for users with really long, high entropy passwords, theoretically the migrated password isn't stored as securely as the same password stored only through the new system; however if the user has a really long, high entropy password, then their passwords don't need to be salted to begin with to be secure. Practically, this should be of little concern.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • I'm not sure if I agree with your statement about high entropy passwords not needing salts. Sure, if a password is long enough then it is safe from brute Force regardless of whether or not it is salted. However, salts are about protecting the entire database from rainbow tables, so the idea that one particular password might not *need* it is a dangerous one - the whole database needs salts. You can't pick and choose which passwords get salts. – Conor Mancone Jul 09 '19 at 10:49
  • Of course, I'm sure you're not advocating for a system that only salts some passwords, but I'm not sure if it is wise to imply that is reasonable. Otherwise, someone may read this answer and think, "Oh, well all *my* users are smart and use long passwords, so I don't need to worry about salts". Salts are really a requirement, and it's best not to imply otherwise. – Conor Mancone Jul 09 '19 at 10:51