I wrote this during breakfast on my way to work so there isn't a ton of documentation along with it.
A quick answer to why storing passwords (in plain text) in a database is bad: [Only registered and activated users can see links. Click Here To Register...]
Here is what my [PS_User_Data].[dbo].[Users_Master] looked like after I implemented password hashing:
[Only registered and activated users can see links. Click Here To Register...]
As you can see I changed the data types on a few columns, changed the primary key, and removed a/some column(s). Also the UserUID column is set to auto increment now.
Here is what my [dbo].[usp_Try_GameLogin_Taiwan] stored procedure looked like after I implemented password hashing:
To add a new user, you would need to run a stored procedure something like this (passing in the appropriate values to the stored procedure obviously):
Basically what is happening when you create a user is:
1. A new user gives you the user name and password they would like to use by filling out a registration form.
2. From the registration script, you pass the user name and password as arguments to a stored procedure meant to create a new user.
3. The stored procedure receives the arguments.
4. The stored procedure generates a unique salt for that user (in this case I use a random number passed into SHA1() to create the unique salt), and stores it in the @salt variable.
5. The stored procedure concatenates the user's plain text password to the salt, and passes the concatenated string into a one-way hashing algorithm (such as SHA1 or MD5), which is then stored in the @hash variable.
6. The stored procedure inserts the data into the [PS_userdata].[dbo].[Users_Master] table.
7. Now you have the password stored in a format that is unreadable and irreversible to humans, but you can still compare against it when users want to log in!
That other table in OMGGame_Web or whatever, we don't care about it anymore. It was redundant data and is now useless.
A quick answer to why storing passwords (in plain text) in a database is bad: [Only registered and activated users can see links. Click Here To Register...]
Here is what my [PS_User_Data].[dbo].[Users_Master] looked like after I implemented password hashing:
[Only registered and activated users can see links. Click Here To Register...]
As you can see I changed the data types on a few columns, changed the primary key, and removed a/some column(s). Also the UserUID column is set to auto increment now.
Here is what my [dbo].[usp_Try_GameLogin_Taiwan] stored procedure looked like after I implemented password hashing:
To add a new user, you would need to run a stored procedure something like this (passing in the appropriate values to the stored procedure obviously):
Basically what is happening when you create a user is:
1. A new user gives you the user name and password they would like to use by filling out a registration form.
2. From the registration script, you pass the user name and password as arguments to a stored procedure meant to create a new user.
3. The stored procedure receives the arguments.
4. The stored procedure generates a unique salt for that user (in this case I use a random number passed into SHA1() to create the unique salt), and stores it in the @salt variable.
5. The stored procedure concatenates the user's plain text password to the salt, and passes the concatenated string into a one-way hashing algorithm (such as SHA1 or MD5), which is then stored in the @hash variable.
6. The stored procedure inserts the data into the [PS_userdata].[dbo].[Users_Master] table.
7. Now you have the password stored in a format that is unreadable and irreversible to humans, but you can still compare against it when users want to log in!
That other table in OMGGame_Web or whatever, we don't care about it anymore. It was redundant data and is now useless.