0

This question already has an answer here:

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?

marked as duplicate by Steffen Ullrich, Conor Mancone, MechMK1, Xander, AndrolGenhald Jul 9 at 14:33

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 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 9 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? – Compufreak Jul 9 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 9 at 11:07
-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.

  • 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 9 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 9 at 10:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.