Suppose I were designing a web service with modest security requirements. For the most part, the threat model would be more about bored college students and less about anything you’d ever find in a spy novel. Would there be anything practically wrong with using the following password storage scheme?
salt || hash(site || password || salt)
where site is a unique identifier of my site, password is the user password, and salt is a user-specific random salt, and the hash is a general purpose cryptographic hash function like SHA-1, and || indicates concatenation.
I’m aware of certain issues that come up with this scheme.
-
The hash is (designed to be) fast to evaluate, and one iteration would leave particular weak passwords guessable.
-
Concatenation alone might cause “puns” in the overall input to the hash.
Now, there are certain security professionals on the Internet who would have me believe that, if this is my idea of a good enough password hashing scheme, I could not possibly deserve employment and desperately need to return to school. They point out that there are well-known password hashing schemes with far better properties from a security perspective. They demand that I switch to something better.
But really, should I? I have a bit of a counter argument here.
-
This is probably not going to be the weakest link in my service. Someone truly determined to break in has plenty of other avenues, and I should prioritize my time to secure the weaker ones.
-
Cost-benefit is already against the attacker’s favor if my site has little intrinsic value. How much of a practical concern is it that a large cluster/botnet could recover a weak password in a day/week? Surely it has more valuable things to be doing that day/week.
-
Compromised accounts are more likely to happen because of trojans, keyloggers, social engineering attacks, what have you. Technology isn’t the limiting factor in this security.
-
The more complex my scheme is, the more difficult it might be to move/expand to another platform. If I used bcrypt (hypothetically), I’d potentially have to write a bcrypt wrapper and incorporate that.
I really like this scheme. It’s really simple. The implementation is hard to get wrong. And I would argue, for all intents and purposes with regard to an average site, it should be fine. Asking me to put in a better hashing scheme almost sounds like asking me to install a bigger lock on a door that is already very vulnerable to chainsaws.
If I would be doing something wrong here, I would very appreciate that someone point it out, especially in terms of practical and real-world-applicable concerns.
Thanks.
See What is the point of salt and hashing if database is accessible?
Salts prevent (some) rainbow table attack sbut they they don’t prevent dictionary or brute force attacks.
Use Scrypt or bcrypt instead, where Scrypt is much stronger but both uses a Proof of Work system to make it much harder to crack a password. See the OWASP Password Storage Cheat Sheet