- Joined
- Jun 5, 2006
- Messages
- 133
- Reaction score
- 0
How do you go about protecting sensitive/confidential data in a database? such as passwords TB_USER?
Well, I took the liberty of being the first person to do this, and I know that for a fact, doesn't matter, the information is publicly available to do this. The first thing you need to do is decide on a method do protect your data. I chose hashing because of it's obvious simplicity. I then chose the md5 hash method. MD5 is quite secure, but nothing is invincible. If you want to use the best you can, I would suggest the blowfish encryption. That shit is nice, but quite overkill for something as simple as a ko db. chances are, nobody will even get into your db, and if they do, they will really have to have some time on their hands to start cracking md5 hashes. Of course, weak passwords are still vulnerable, Do not allow '123321','123456','abc123','123abc'. These passwords are easily guessed, and make the accounts vulnerable.Another thing you should do is make sure the users password in no way refers to the account id. For example, you don't want a user "jonny" with the password "jonny' or "jonny123" nothing like that, it can be guessed lightning quick, and if a password can be guessed, what purpose does it serve?
Ok, so now you've set some password restrictions up, now it's time to start protecting your data!
I've found the best way to do this is to first take your web server offline so no new accounts are created while we do this. Then open tb_user and change the datatype of strpasswd to varchar(400). this is to allow change in size of password. Then, you are going to run "update tb_user set strpasswd = hashbytes('md5',strpasswd)
That query will md5 hash all the passwords in your tb_user. Now, you may be wondering how do we check the password if it's now hashed? Good question, let's start with the simple.
Firstly you will need to allow users to login. But before we can do that, you need to open your tb_user and change the datatype of strpasswd from varchar(400) to varbinary(50). save that table again, and now if you open it you'll see <binary data> as the strpasswd. This is cool, but if you go "select * from tb_user" in query analyzer you will see that it still shows you the varbinary data. This is good, and we can use this.
Open your account_login procedure. This is the most important step.
If you have any of those variables defined anywhere else, this will error, make sure you only define them once as what i just specified. WALA, your passwords in your database are now hashed and hacker friendly.of course, this does not and will not and cannot protect against a hacker Updating passwords (that's why i would suggest using an oddball hash), deleting rows from the table, but if the db is actually taken, they won't be able to do much with the tb_user table.
Well, I took the liberty of being the first person to do this, and I know that for a fact, doesn't matter, the information is publicly available to do this. The first thing you need to do is decide on a method do protect your data. I chose hashing because of it's obvious simplicity. I then chose the md5 hash method. MD5 is quite secure, but nothing is invincible. If you want to use the best you can, I would suggest the blowfish encryption. That shit is nice, but quite overkill for something as simple as a ko db. chances are, nobody will even get into your db, and if they do, they will really have to have some time on their hands to start cracking md5 hashes. Of course, weak passwords are still vulnerable, Do not allow '123321','123456','abc123','123abc'. These passwords are easily guessed, and make the accounts vulnerable.Another thing you should do is make sure the users password in no way refers to the account id. For example, you don't want a user "jonny" with the password "jonny' or "jonny123" nothing like that, it can be guessed lightning quick, and if a password can be guessed, what purpose does it serve?
Ok, so now you've set some password restrictions up, now it's time to start protecting your data!
I've found the best way to do this is to first take your web server offline so no new accounts are created while we do this. Then open tb_user and change the datatype of strpasswd to varchar(400). this is to allow change in size of password. Then, you are going to run "update tb_user set strpasswd = hashbytes('md5',strpasswd)
That query will md5 hash all the passwords in your tb_user. Now, you may be wondering how do we check the password if it's now hashed? Good question, let's start with the simple.
Firstly you will need to allow users to login. But before we can do that, you need to open your tb_user and change the datatype of strpasswd from varchar(400) to varbinary(50). save that table again, and now if you open it you'll see <binary data> as the strpasswd. This is cool, but if you go "select * from tb_user" in query analyzer you will see that it still shows you the varbinary data. This is good, and we can use this.
Open your account_login procedure. This is the most important step.
Code:
DECLARE @pwd varbinary(50), @ccc2 int, @passwordh varbinary(50)
SET @pwd = null
select @pwd = strpasswd from tb_user where straccountid = @accountid
SELECT @ccc2 = count(*) from tb_user where straccountid = @accountid and strpasswd = HashBytes('MD5', @password)
set @passwordh = hashbytes('MD5',@password)
IF @pwd IS null
BEGIN
SET @nRet = 4
RETURN
END
ELSE IF @pwd <> @passwordh
BEGIN
SET @nRet = 3
RETURN
ENDIf you have any of those variables defined anywhere else, this will error, make sure you only define them once as what i just specified. WALA, your passwords in your database are now hashed and hacker friendly.of course, this does not and will not and cannot protect against a hacker Updating passwords (that's why i would suggest using an oddball hash), deleting rows from the table, but if the db is actually taken, they won't be able to do much with the tb_user table.
storing unhashed pass***** in sessions isn't safer than storing them in the database. Sessions are serverside after all 
