User registration issue

[Doctor Luz]

I want to add a User/password feature to a web page.

I will store the user and passwords in a MySQL database.

I want the fields to allow UTF-8 strings.

Since I will use mysql_query($sql) to add new users I need to know if the user or password field contains 'dangerous' characters that might cause a faliure of mysq_query().

I'm not sure what can cause a faliure of this function. I suppose if $sql contains characters like \ or ' or " might cause a faliure.

I would like to know what other characters should I check in $sql to prevent a faliure.

Thank you.

[visualAd]

There are functions that exist in PHP for this very purpose.

addslashes() (http://www.php.net/addslashes) - Will modify the string and prefix all single quotes ', double quotes " and back slashes themselves with the escape character. A backslash. This makes the string safe to include in an SQL query.

If the data is coming in via user input, i.e. a form, PHP will sometimes automatically apply the addslashes function to the data. Applying it again will in effect corrupt the data, so before using this function you should check to see if input varaibles such as $_GET and $_POST have already been escaped. The function you would use for this is the get_magic_quotes_gpc() (http://www.php.net/get_magic_quots_gpc) function.

The following is a special addslashes function which only modifies the string if it has not already been escaped:

function addslashes_safe($string) {
if (! defined('GPC_ON')) define('GPC_ON', (bool) get_magic_quotes_gpc());

return GPC_ON ? $string : addslashes($string);
}

[Doctor Luz]

Thank you for your help visualAd

I will work on this. Probably I simply will forbid the ' and " chararacter in the username or password.

do you think that any other character might cause problems on the SQL query?

[visualAd]

Not in MySql, as long as you ensure that all data is in single quotes, even numeric data. I.e:


INSERT INTO users (`UserName`,`Password`,`Level`) VALUES ('Jim O\'Brien', 'com\"plex`pa\\ss@wor$d\'', '45');

Even though the level field is an integer you should still enclose it in quotes to be sure, MySql will convert it to the necessary data type.

I would just use the addslashes function and let the user do whatever they like with their user names. For password field, which is likely to contain meta characters, use the md5() function to create a hash or it and store this in the database instead of the password.

[Doctor Luz]

For password field, which is likely to contain meta characters, use the md5() function to create a hash or it and store this in the database instead of the password.

meta characters? :confused:

[visualAd]

Meta characters are those characters which in the SQL query may be interpreted as part of the query, if not escaped, \ ' and ". Basically those are the chracters addslashes deals with.

[Doctor Luz]

What advantage can I get storing the password's md5() hash instead of the password itself?

[visualAd]

There are a couple of reasons why you should use the md5 function for storing passwords. The md5 hash is a one way hashing algorithm which generates a 128bit binary number based on all the data:


Firstly it improves security. Users may use a password which they use on other sites, possibly secure sites. By encrypting these passwords before storing them, it means that should someone break into your database, they would not be able to see the passwords.

It also means that admins cannot see the users passwords and stating on your site that passwords are stored using irreversable encryption gives them more piece of mind.
Secondly, the md5 function will always return a 32 character string regardless of the size of the password, which can be stored in a fixed length field of a database.
If you are using a non secure site, then you will no doubt be aware that all data including passwords are sent to the server in plain text. You can make the process of logging on much more secure for users whose browsers support Javascript by hashing the password before it is sent to the server.

To make it even more secure a random number can also be sent along with each page request, which is hashed along with the password. This would make it very difficult indeed for an unauthorised user to log on. There is plenty of source code floating around on the Internet for md5 functions written in Javascript. I believe that even the forum software here uses some kind of md5 function too.

[Doctor Luz]

There are a couple of reasons why you should use the md5 function for storing passwords. The md5 hash is a one way hashing algorithm which generates a 128bit binary number based on all the data:


Firstly it improves security. Users may use a password which they use on other sites, possibly secure sites. By encrypting these passwords before storing them, it means that should someone break into your database, they would not be able to see the passwords.

It also means that admins cannot see the users passwords and stating on your site that passwords are stored using irreversable encryption gives them more piece of mind.
Secondly, the md5 function will always return a 32 character string regardless of the size of the password, which can be stored in a fixed length field of a database.
If you are using a non secure site, then you will no doubt be aware that all data including passwords are sent to the server in plain text. You can make the process of logging on much more secure for users whose browsers support Javascript by hashing the password before it is sent to the server.

To make it even more secure a random number can also be sent along with each page request, which is hashed along with the password. This would make it very difficult indeed for an unauthorised user to log on. There is plenty of source code floating around on the Internet for md5 functions written in Javascript. I believe that even the forum software here uses some kind of md5 function too.



They are interesting reasons, interesting to think.

I wonder what is the probability of find two strings with the same md5 hash, or given a hash recover a string.

[visualAd]

I think the chances are remote. A 128bit integer is a very large number, to store it as an integer in mysql you would need two "BIG INT" fields, each of which are 64bits in size.

I think as the data you are hashing gets larger, the chances of getting a duplicate become greater, but finding a string with a duplicate md5 hash would take a very long time and most people would not have the resources and/or time to persue it unless there is large gain from it.