Are parametrized calls/sanitization/escaping characters necessary for hashed password fields in SQL queries?

When writing a login system for a website, it is standard to use some combination of parameterized calls, sanitizing the user input, and/or escaping special characters to prevent SQL injection attacks.

Any good login system, however, should also hash (and possibly salt) every password before it goes into an SQL query, so is it still necessary to worry about SQL in开发者_如何转开发jection attacks in passwords? Doesn't a hash completely eliminate any possibility of an SQL injection attack on its own?

EDIT: I'd also be curious if current websites do clean their password fields or if it is generally not worred about.

---

It is always best to assume any call to a database could carry query injection.

Personally, I highly doubt that a call with an SHA1 hash would ever be able to inject code, but is there any reason you wouldn't sanitize it anyways?

Paranoia is the best way to go when dealing with injection ;)

---

Probably not.

But isn't a hashed password is just another parameter to a database call? Do you mean you'd mix'n'match parameterisation for all other input except passwords where you use string concatenation?

---

Depends what kind of query you're doing.

If your query looks like

SELECT username from user_logins WHERE 
  username=? AND password_md5 = md5(?)

Then not escaping the specified password inside the md5 function will lead to a sql injection vulnerability.

Just use parameterised queries all the time unless there is some incredibly good reason you can't (Hint: IN (...) doesn't play well with them).

Parameterised queries are easier to do right than escaping, and more secure.