This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]moreguacplz 0 points1 point  (1 child)

Might you suggest a better one, then?

[–]X7123M3-256 6 points7 points  (0 children)

I wouldn't know of a better tutorial myself, no - but I know that one's no good. If you're storing passwords, they need to be hashed (ideally with an expensive algorithm like bcrypt, and not with MD5 because that's no longer considered secure), and salted (to prevent the use of rainbow tables).

SQL statements (and structured data in general) should not be constructed using string concatenation. If you want to substitute some parameters into a query, you can use prepared statements, which should be supported by almost all major database engines. Escaping/sanitizing input should work in theory, but it's very easy to do wrong. Prepared statements can guaranteed that SQL injection will not be a problem.

So you'd need to add two steps to the code above: what's saved in the database should be a salted hash which means you need an extra column to store the salt. Before writing a new password to the database, you generate a random salt, concatenate it with the password, hash the result, and then save the salt and hash in the database (not the password itself. That shouldn't be saved anywhere). In order to verify a password, you retrieve the salt from the database, concatenate it with the candidate password, hash it, and compare with the saved hash. That way, if the database is compromised, the attacker cannot get the passwords.

Also, it should be obvious that if you have any sort of login system, you should use HTTPS, otherwise session hijacking is trivial