encrypt SQL Password Encryption

[ViRuZGamiing]

Hi guys!

 

When working on a login panel I'll need to hash the password as I guess (since we wouldn't like our password te be plain string)

My question tho, Can I choose my encryption type myself? I'm familiar with the MD5 Hash since that's what I'm taught on college.

Should I use MD5 which I know or is there a better suggested one?

 

Kind Regards

[pa3ck]

MD5 is not the best, I would rather use SHA256, because of the possible encryption collision issues. If you really want your password to be secure, you should use salting along with SHA. The reason is, that simple passwords like "password123" let's say gives you "BD4ZDFVscBD", if more users have the same password, they would all have the same hashed password.  

[ViRuZGamiing]

4 minutes ago, pa3ck said:

MD5 is not the best, I would rather use SHA256, because of the possible encryption collision issues. If you really want your password to be secure, you should use salting along with SHA. The reason is, that simple passwords like "password123" let's say gives you "BD4ZDFVscBD", if more users have the same password, they would all have the same hashed password.  

Thanks and how would I decode SHA256, I wouldn't be able (when a player is already registered) to compare the SHA password in the SQL Database with the password written in the (for example:) GUI Login Panel encoded, since they wouldn't be the same, right?

[Dealman]

Don't ever use MD5. You don't decode it, you store the hashed password and preferably use a salt for added security(server-sided salt).

For example:

ABC123 then concatenate it with a salt(usually a random string). "ABC123blgvlkhxb743j" < example. Then you hash that.

You hash the entered password BEFORE you try to log in and compare it. Same password will yield the same hash.

[ViRuZGamiing]

18 minutes ago, Dealman said:

Don't ever use MD5. You don't decode it, you store the hashed password and preferably use a salt for added security(server-sided salt).

For example:

ABC123 then concatenate it with a salt(usually a random string). "ABC123blgvlkhxb743j" < example. Then you hash that.

You hash the entered password BEFORE you try to log in and compare it. Same password will yield the same hash.

Thanks and indeed, I found an article saying exactly the same.

Quote

The general workflow for account registration and authentication in a hash-based account system is as follows:

1. The user creates an account.
2. Their password is hashed and stored in the database. At no point is the plain-text (unencrypted) password ever written to the hard drive.
3. When the user attempts to login, the hash of the password they entered is checked against the hash of their real password (retrieved from the database).
4. If the hashes match, the user is granted access. If not, the user is told they entered invalid login credentials.
5. Steps 3 and 4 repeat everytime someone tries to login to their account.

 

[Dealman]

Aye, just make sure you keep the salt on the server. Don't ever send it to any client.

[ViRuZGamiing]

36 minutes ago, Dealman said:

Aye, just make sure you keep the salt on the server. Don't ever send it to any client.

Yeah cause then they'd just see it in there client files  

Is this a good way of doing it? First time working with salt.

function generateSalt()
	local characters = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F}
	local salt = ""
	for i=0,31 do
		salt = salt .. tostring(characters[math.random(0, 16)])
	end
	return md5(salt)
end

addCommandHandler ( "sha",
	function ( thePlayer, command, input )
		if (input) then
			local salt = generateSalt()
			local sha256hash = sha256(input .. salt)
			outputChatBox(sha256hash)
		end
	end
)

 

[pa3ck]

Yes, something like that, but you don't MD5 the salt, it's just plain text. Let me explain why you need salting.

 

User A's password in plain text: password123 in sha256: BDKKDKDMSBDMBKLSDBMDSKMBK

User B's password in plain text: password123 in sha256: BDKKDKDMSBDMBKLSDBMDSKMBK

See how is that a problem? They are hashed the same way. I don't know if you ever heard of rainbow tables, but basically they are a huge table with a combination of hashed and reversed password. To crack a simple password all you need to do is find "BDKKDKDMSBDMBKLSDBMDSKMBK" in the rainbow table and you will have the password in plain text. But, if you add random characters after the plain password (random for every user) there won't be 2 of the same passwords. So storing salt is not meant to be a secret, it's meant to change the outcome of the hashed password.

[ViRuZGamiing]

Yeah I heard of rainbow tables but very little, I know the MD5 on the salt doesn't need to, but I thought it might give a stronger result.

My teacher on college told me that I'd best use characters above ASCII value 128 since they wouldn't appear in the rainbow table.

So is my 0-9, A-F combination secure enough?

[Dealman]

Nicely put @pa3ck.

I think that's a bit over the top, but if you want to - go for it.

Also remember you need the salt to be unique but the same for every player. So you'll probably want to generate the salt based on their serial or something similar.

I believe the serial is dependent on your hardware so it can potentially change which could be a ptoblem.

[ViRuZGamiing]

3 minutes ago, Dealman said:

Nicely put @pa3ck.

I think that's a bit over the top, but if you want to - go for it.

Also remember you need the salt to be unique but the same for every player. So you'll probably want to generate the salt based on their serial or something similar.

I believe the serial is dependent on your hardware so it can potentially change which could be a ptoblem.

You could just store the salt in a seperate column in the database the just take that add it to the password and hash it on login, right?

You wouldn't need to re-generate the salt? also you wouldn't be able to play on different PC's since you'll then have a different serial as you said

[Dealman]

That is true, though if someone gets access to your database the salt is pretty useless.

There are other ways obviously, you just need to find a solution that suit your needs.

At work atm so can't really post in-depth replies - sorry.