No point in addslashes etc

If you use a script like this:

$user=md5($_POST['user']);
$pass=md5($_POST['pass']);
#sql="Select * from users where md5(user)='".$user."' and md5(pass)='".$pass." LIMIT 1';

It's pointless to use any other security measure maybe except overflow testing. Encoding the input into md5 prevents any malicious characters from sneaking in.

Am I right?

Nevermind, I misread.

I'm not sure what you wrote, but I encode into md5 before putting into query, so it should be fine.

Am I right?

Likely. Why don't you try it and see? That's the best way to find out.

Don't use md5, salted or not salted. Too many collisions.

ynori7 wrote: Likely. Why don't you try it and see? That's the best way to find out. That I will. However, I am not as experienced at sql injection as some other people on here.

Also, another question:

Since this method cannot be used for storing forum posts (you want them not-md5 hashed), could you simply use hex encoding to store posts in a db? Or would it increase the volume of the db too much (5 to 6 times as much)?

About collisions: You could check for collisions at time of user creation.

About seeing plaintext, I agree, let me mod the code a bit:

$sql="SELECT * from users where md5(user)='".$user."' and md5(pass)='".$pass."' LIMIT 1;";

ranma wrote: Since this method cannot be used for storing forum posts (you want them not-md5 hashed), could you simply use hex encoding to store posts in a db? Why? How is that easier than the alternative? You still have to sanitize the posts anyway since they get printed to the screen.

Ok, how about you do strip tags and then you do hex encode?

MoshBat wrote: [quote]ranma wrote: That I will. However, I am not as experienced at sql injection as some other people on here.

Also, another question:

Since this method cannot be used for storing forum posts (you want them not-md5 hashed), could you simply use hex encoding to store posts in a db? Or would it increase the volume of the db too much (5 to 6 times as much)?

You're overcomplicating the most simple of things.

" or 1=1– ' or 1=1–

See, I can write those things, and the database it just fine. I wonder how that's done… Think![/quote]

I can do that easily, but some websites are immune to that but are vulnerable to others.

And my question stands. Could the md5 method be effectively used?

ranma wrote: Ok, how about you do strip tags and then you do hex encode? You're not thinking. Why would you waste the server's processor power to hex encode every post? What's the gain?

1)> You're not thinking. Why would you waste the server's processor power to hex encode every post? What's the gain?

That's why I was asking.

2. Convert all applicable characters to HTML entities - Applicable doesn't mean ALL. Plus, look at the comments underneath. Some characters are wrongly encoded.

Sounds like overcomplicating a simple topic.

MoshBat wrote: [quote]S1L3NTKn1GhT wrote: Sounds like overcomplicating a simple topic. I've already said that.[/quote]

stfu. If i say something that you said i sound smart. Now sshhhh.

MoshBat wrote: Okay. I'll just mock up some code for you…

$pass = md5($_POST['pass']);
$qwerty = mysql_query("SELECT * FROM users WHERE user = '$user' AND pass = '$pass'");
//next bit.```


No point using mysql_real_escape_string AND addslashes, use one or the other (preferably mysql_real_escape_string)

MoshBat wrote: There are holes in both. I like to be safe.

-_-

That's why I just use md5. Is it way more resource-intensive?

ranma wrote: That's why I just use md5. Is it way more resource-intensive? Yes it is. The algoritm looks like this. Just use mysql_real_escape_string() and you'll be fine. I don't see any reason not to use the standard function(s) created to prevent SQL-injections.

spyware wrote: [quote]MoshBat wrote: There are holes in both. I like to be safe.

-_-[/quote]

personally that made me laugh. :P