I don't see the need, when the input is taken as a string and hashed. Wouldn't hashing it effectively, well, sanitize the input? It seems like a waste of about a couple hundred CPU cycles, not significant, but I don't see the need.
I realize I'll need to use crypt to protect my passwords.
Edit: As an example:
$password = $_POST['password'];
$password = strip_tags($password);
$password = sha1($password);
It makes no sense to me.
分享 The Internet is full of chimpanzees
That's the main reason why it is always mentioned.
In these tutorials, where only raw PHP without even grain of abstraction is used, it's indeed superfluous.
However, in fact, in a real application mysql_real_escape_string or equivalent have to be applied. Not the way it is described in aforementioned tutorials but anyway.
In a sanely designed application database layer have to be separated from other logic. And by the time of the query execution it have to be totally ignorant of the data source or nature. Means all the data have to be treated the same way. I.e. strings have to be quoted and escaped.
Thus, your password have to be sent to database layer, and treated there as a regular string. And, depends on the layer architecture, it may be escaped and quoted, or sent as a parameter separated from the query, or encoded some way - but that shouldn't be our concern at all.
Wouldn't hashing it effectively, well, sanitize the input?
Note the emphasized word.
Your particular confusion coming from the misinterpreting the purpose of mysql_real_escape_string or similar function. In fact, it does sanitize nothing. What it really does is part of required formatting. A string, being placed into SQL query, have to be properly formatted. Always. Despite of the source, contents, or constellations interposition.
After all, some hashing function may return binary string that pretty much can contain a special character. But again - why bother at all? These CPU cycles don't worth a fraction of overall sanity and security of application.
分享
