question about how exactly mysql does this

[133794m3r]

Code: [Select]

mysql_real_escape_string(sha256($password)));
Ok now personally to me it should sha256 the $password variable, then it'd attempt to escape the characters that shouldn't be there. Is this true? Or does it strip the special characters then do an sha256? If it does the former, i'll just put that up higher in the registration/login script.

[AcidicOne]

I may be wayy off base here, but you always want to strip everything before it posts because of SQL injection.Some examples i found here for ya, I am sure some of the others could give you some hints as to what they use.

http://asad296.blogspot.com/2008/12/prevent-your-php-mysql-scripts-from-sql.html

[Nox]

The thing is... isn't the result of sha256 consisting solely of alfanumeric characters which would not broke the query anyhow? The escaping function would have no effect then...which is what I believe

[133794m3r]

The thing is... isn't the result of sha256 consisting solely of alfanumeric characters which would not broke the query anyhow? The escaping function would have no effect then...which is what I believe

()#*@#&!__ = 89071e5f1c0f1f9d6cbddbf968976668ee54fe9d11ad892e8c63af7f5e233fe3 when sha256ed.

also how can i strip data before it posts? I'm pulling the data on the login page... i am using a if($_POST){ } in my php file so that way it doesn't auto-run without any data. So i have no data being read until it's posted. I was wondering if i should escape it before hashing, since it's confusing me to as it works. B/c if it sha256s it, even sql injection it seems will be hashed thus making it pointless to escape to me atleast. I'll still do it just incase but well still.
Also
%= bbf3f11cb5b43e700273a78d12de55e4a7eab741ed2abf13787a4d2dc832b8ec

So that's telling me it works with alpha,numeric and special characters. And the username itself though, i will be still escaping it.  And hmm, that pages has a few interesting things i'll be sure to be adding to the escaping function i'll set up earlier on in the page. Mainly, a stripping/adding cslasshes things. Then do the escape string later down the road at teh bottom where it would normally have been.

[dsheroh]

Code: [Select]

mysql_real_escape_string(sha256($password)));
Ok now personally to me it should sha256 the $password variable, then it'd attempt to escape the characters that shouldn't be there. Is this true? Or does it strip the special characters then do an sha256? If it does the former, i'll just put that up higher in the registration/login script.

You don't have to worry about SQL injection on this line.

sha256 can safely accept any character as input.  Barring any serious as-yet-undiscovered bugs in PHP's implementation of sha256, it can safely handle any input given to it, so there's no need to worry about escaping anything there.

The actual output of the sha256 algorithm is just a string of bits, which is then encoded into something more readable for output; your implementation appears to be encoding it as hexadecimal, but base64 encoding is also common for that sort of thing.  In either case, the character set into which it is encoded is 100% SQL-safe, so there is no need to post-process that encoded representation to prevent SQL injection.

[133794m3r]

Code: [Select]

mysql_real_escape_string(sha256($password)));
Ok now personally to me it should sha256 the $password variable, then it'd attempt to escape the characters that shouldn't be there. Is this true? Or does it strip the special characters then do an sha256? If it does the former, i'll just put that up higher in the registration/login script.

You don't have to worry about SQL injection on this line.

sha256 can safely accept any character as input.  Barring any serious as-yet-undiscovered bugs in PHP's implementation of sha256, it can safely handle any input given to it, so there's no need to worry about escaping anything there.

The actual output of the sha256 algorithm is just a string of bits, which is then encoded into something more readable for output; your implementation appears to be encoding it as hexadecimal, but base64 encoding is also common for that sort of thing.  In either case, the character set into which it is encoded is 100% SQL-safe, so there is no need to post-process that encoded representation to prevent SQL injection.

ah ok so it is doing it how i thought. Now to start using the crypt() blowfish_crypt on that line then. I thought it was a bit redundant but wanted to make sure before i did something wrong.