The results are equivalent as much as:
$safeuser = $mysqli -> real_escape_string($user );
$safepassword = $mysqli -> real_escape_string($password);
$mysqli->query( "INSERT INTO usuarios ( nome, senha ) VALUES ( '$safeuser','$safepassword' )" );
... how much so:
$stmt = $mysqli->prepare( 'INSERT INTO usuarios ( nome, senha ) VALUES ( ?, ? )' );
$stmt->bind_param("ss", $user, $password );
$stmt->execute();
However, Prepared statements present some advantages:
- The original query is much more readable (just like the rest of the code).
- You do not need to handle quotes in your query, regardless of the type of parameter.
- No danger of forgetting to treat variables.
- No need to create intermediate variables or change the originals to insert into the database;
- Not your case, but in situations where the same query will be executed several times in a row just changing values, the Mysql connector will only send the updated data instead of sending the query and redo the planning (which is the great difference to do Binding native, by the server).
There are numerous ways to do this. You can use the function
password()
Mysql instead of doing the hash in PHP, as I mentioned in http://answall.com/questions/16967/quais-sao-os-valores-recomendados-para-database-mysql-usuario-senha-e-emai/16978#16978. It may even exist, but I don’t see the advantage of doing it in PHP.– Maniero
The manual already starts wrong saying that MD5 and SHA1 are good options. They are not. You must have read this yesterday. I confess that I never read it in the manual. Because I can’t imagine why they created a function that shouldn’t be used. And mostly because it would be worse than the
password_hash()
. It is necessary to understand why what is there. But if they already talked nonsense in the paragraph, I don’t know if I can trust the rest. I have seen several known applications using it. Anything used without context is likely to be wrong. I agree thatbcript
is a good option.– Maniero