Another thing you should consider, if you want it to be secure, is avoidance of SQL injection. For example, suppose your login code does:

SELECT COUNT FROM Users WHERE Username='(typed)' AND Password=MD5('typed'))

and it logs you in using that, you have a major security issue. If I type in

Username: "some_real_user' --" (without the quotes)

then look at the happens to the SQL:

SELECT COUNT FROM Users WHERE Username='some_real_user' --' AND Password=MD5('typed'))

Anything after the '--' is commented out... so your thing becomes

SELECT COUNT FROM Users WHERE Username='some_real_user'

Uh oh...

What you should do, as a rule, is use Bind variables (or "prepared statements", in the Java world). The way it works is, you put placeholders into your SQL code as so:

SELECT COUNT FROM Users WHERE Username=:userName AND Password=:md5Passwd

(assuming your do your encryption on the client side...whatever)

then, in your code, you populate some data structure (strings or whatever you need in your sql) with what the user types. Then, you don't need to worry about checking for these things. As an added bonus, you only need to compile your SQL statements once, and then just re-use them with different bind variables.

Quote:You do realise than any checksum is bound to have collisions? Otherwise it's actually a compression alogorithm in disguise.

Allow me to retro-interject "will work without collisions for my purposes." My point about programmers in the same room is proven. :P

Quote:Original post by Replicon
Another thing you should consider, if you want it to be secure, is avoidance of SQL injection. For example, suppose your login code does:

Interesting, thank you. I'm only a basic SQL guy and this information is new and useful to me!