Is hash(site || password || salt) actually a bad idea? [closed]_问答_开发者

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For h开发者_开发百科elp clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

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

From a pure hashing perspective, unless I'm reading your question wrong, you're proposing creating a hash of the password concatenated with a user specific random salt which is the usual approach. Any additional data involved in the concatenation won't make a whole lot of difference if you've already got a cryptographically random strong salt of sufficient length.

Then there's the old argument about which hashing algorithm is the most secure and of course bcrypt will trumps the likes of SHA - and particularly MD5 - due to it's adaptive native and ability to increase the hashing process duration to ward off brute force attacks.

However, you could pragmatically argue that for most general purpose website cases, SHA1 and above would be sufficient. When you look at the breaches we've seen in recent times, password disclosure is usually happening when they're either stored in plain text (obviously very vulnerable) or hashed without a salt (easily vulnerable to rainbow tables). Sure, the SHA derivatives will be faster to work through (particularly if it's a single hash), but in combination with a cryptographically random salt it's not a small task.

Case in point: the ASP.NET membership provider from Microsoft uses SHA1 and is very extensively used. There is no native bcrypt support (although third party libraries are available), which probably should tell you something about how Microsoft views the issue.

Finally, there's also the issue of password strength. Setting a long, strong requirement will obviously contribute to the strength of the hash against many brute force techniques. Of course there's the usability trade-off, but that's another issue.