-2

Is it more secure to:
a) Take a password, salt it, then hash it.
b) Take a password, hash it, then encrypt it(Using a symmetric algorithm with a large key)

Stoud
  • 344
  • 1
  • 10
  • For people marking as duplicate, I wouldn't really call it a duplicate, the linked question does not really address encrypting a hashed password, or if it does it is not in a prominent position. – Stoud Feb 27 '16 at 03:19

2 Answers2

1

I'll give you effectively the same answer you got on crypto.SE when you asked this question there, but with a bit more explanation.

Passwords should be salted and hashed. Period. Now if you want to encrypt them after salting and hashing them, go for it. If you do not salt your hashes before encrypting, then you run the risk of either a) the resulting encrypted hashes being identical for identical passwords (worse case) or using a unique IV for each encrypted password which is exactly as much work as using a salt but has the added issue of not providing any protection for your unsalted hashes if your encryption is broken and the raw hashes exposed. This problem is why we hash passwords instead of encrypting them in the first place.

So, the bottom line is, salt and hash. And hash with a good, slow hash function like bcrypt.

Community
  • 1
Xander
  • 35,525
  • 27
  • 113
  • 141
  • I didn't mean to double post, I just thought that I failed to post on there because when I went back I didn't see the question. I thought I asked it on this forum and was confused, my bad. Just making sure, while not salting has drawbacks, it would render a rainbow table usless, correct? – Stoud Feb 26 '16 at 22:59
  • @Stoud No worries. – Xander Feb 26 '16 at 23:00
  • @Stoud - what do you mean about 'not salting has drawbacks'? If you don't salt, you are open to lookup tables. For example, if you were to make your password 'baseball', your hash would be one of [these](http://www.hashhunters.net/hash/baseball/). They are trivial to reverse (even though hashes aren't algorithmically reversible, they are reversible with a lookup table). Salting has the effect of making every password globally unique so every hash is unique. See the question I marked as a duplicate - it explains this all. – Neil Smithline Feb 26 '16 at 23:34
  • The question talks about encryption rather than salting, so it should not be in the rainbow table. – Stoud Feb 26 '16 at 23:42
  • @Stoud Salting renders rainbow tables useless, so this is not a unique advantage. – Xander Feb 27 '16 at 00:09
0

The only potential benefit of encrypting vs salt+hash, is that it's reversible. If your client insists on being able to retrieve existing passwords, then encryption is what you need. If you don't need to retrieve the existing value, then encrypting is less secure, and a waste of CPU time.

user1751825
  • 905
  • 4
  • 10