So I'm in the middle of creating a an online game. I've looked at some posts about this but was wondering if the following is suitable for securing passwords. This basically puts the knowledge of cracking it in code and not so much in a database, but would still have a flaw for someone sniffing on initial login.
When the user signs up on the website and enters their desired username and password a unique salt is generated for them (a guid in my case). This salt is sent through some code on the server that will hash it with various hashing techniques hundreds of times hashing the results of hashes. Then once it has it's final hash it'll store that hashed password along with the salt in the DB.
When a user logs onto the game:
1) Client sends username to server
2) Server queries DB for username to get hashed pw (remember it's been through many hashes of various hash algo's) and salt
3) Server sends salt to the client
4) Client does the first hash in the many times server hashing between the pw they entered and the salt and sends that to the server (this is the point I see security issues for sniffers or man in the middle, but this would be one off attacks and client based instead of server based)
5) Server takes this hashed value and completes the original hashing algo that was done when they signed up. Again this is in the server code only.
So with this technique if the DB becomes compromised in any way (they hack the server directly or sql injection to query it) it won't do much good because they won't know the many hashing with various hashing algo's in what order because that was all done on the server code. The only way they would see that is by reading the source code to the server program (which wouldn't be on the server) or taking the server program itself and hacking into the exe to see what exactly it's doing. That seems pretty secure to me though. Am I missing anything?
I would rather slightly risk one off client based man in the middle hacking of sending hashed pw + salt then server side. I can't have this many times hashing algo on the client as hackers could just "read" the client code to see what it's doing and then they would know what to do with the data in the DB if they got it. It just seems like having the "key" being the server side program itself is more secure since you would hope it would be harder to actually get on your server for a hacker.
Thoughts?
online games password security
So with this technique if the DB becomes compromised in any way (they hack the server directly or sql injection to query it) it won't do much good because they won't know the many hashing with various hashing algo's in what order because that was all done on the server code. The only way they would see that is by reading the source code to the server program (which wouldn't be on the server) or taking the server program itself and hacking into the exe to see what exactly it's doing. That seems pretty secure to me though. Am I missing anything?
If your server is compromised, you can assume they can read the program. The exe of the server program is no harder to read than the source code for an experienced hacker.
However, it is probably much easier to just change the password in the first place, if you have sufficient access to the server.
However, the one thing you should think about when doing crypto: Don't Invent It Yourself!
If you want to protect against hash based attacks, try bcrypt().
If you want to protect against sniffing, try SSL.
Even if you use UDP for the gaming part, establish a key for a common cypher (AES?) and a one-time-pad schedule over an initial SSL connection -- if you think that game traffic is at all vulnerable to sniffing/injecting, which it may not be.
The first lesson in any encryption or security system is to assume that the entire process is known to everyone. Off this assumption, you begin. The purpose of encryption is not to make something impenetrable --because that is impossible-- but to make the problem so difficult and time consuming that by the time a result is obtained, the information is no longer relevant. You must accept this before you can move on, if you do not, you will end up creating flaws in your system.
Having said that, hashing the passwords in you servers database is a good idea because it will prevent anyone who is able to gain access to it no data that is usable(read below for more). To use this, the client should send their login and password through an encrypted channel. Once the server receives the data, it hashes the password and compares the hashed value with the databases stored hash value. If they are equal, grant access, if not, do not grant access. All the stuff about hashing multiple times, with added salt and sending the salt to the client, and back again sent my head spinning. Encryption and data security has been researched thoroughly, so before thinking of a better way --don't. Use methods commonly known, studied and follow them exactly. Introducing small tweaks, however much you think they will help, most likely will not help, but cause the opposite.
In summary:
servers store the hashed passwords sha256 is very good --hashing multiple times does not add extra security Multiple hashing of passwords
Client and server setup an encrypted channel of communication preferably one with authentication to prevent a man-in-the-middle attack
Client encrypts the login/pass send it to the server who hashes the password and compares it with the one in the database.. DO NOT have the client hash the password then send it because if the database is compromised, the attacker can then send the hashed password stolen from the database to login.
done..
Having said that, hashing the passwords in you servers database is a good idea because it will prevent anyone who is able to gain access to it no data that is usable(read below for more). To use this, the client should send their login and password through an encrypted channel. Once the server receives the data, it hashes the password and compares the hashed value with the databases stored hash value. If they are equal, grant access, if not, do not grant access. All the stuff about hashing multiple times, with added salt and sending the salt to the client, and back again sent my head spinning. Encryption and data security has been researched thoroughly, so before thinking of a better way --don't. Use methods commonly known, studied and follow them exactly. Introducing small tweaks, however much you think they will help, most likely will not help, but cause the opposite.
In summary:
servers store the hashed passwords sha256 is very good --hashing multiple times does not add extra security Multiple hashing of passwords
Client and server setup an encrypted channel of communication preferably one with authentication to prevent a man-in-the-middle attack
Client encrypts the login/pass send it to the server who hashes the password and compares it with the one in the database.. DO NOT have the client hash the password then send it because if the database is compromised, the attacker can then send the hashed password stolen from the database to login.
done..
Author
So it looks like there is a .net implementation of bcrypt(), which is good because I'm using .NET. It's interesting how it's setup to just be slower and therefore take years to crack what hashing would take seconds. Very cleaver indeed.
1) OK, so bcrypt() for hashing passwords, then store that value in the DB. Now if someone can read the DB it would take them a long time to break any passwords with brute force or rainbow tables. Having the algorithm take .3 seconds doesn't seem all that bad for when valid clients are trying to connect
2) Then when clients login send their password to server over SSL. I don't know anything about SSL and the thing that worries me is that I'm using a .net socket library that makes working with sockets so simple but I don't have the code just DLL's. What is involved with sending things over SSL and can it be used with any networking library?
Does using SSL mean clients have to install certificates on their side? Is that something the client actually has to do? Do those certificates expire and I'd have to release me ones? Does any actual online game today do this?
1) OK, so bcrypt() for hashing passwords, then store that value in the DB. Now if someone can read the DB it would take them a long time to break any passwords with brute force or rainbow tables. Having the algorithm take .3 seconds doesn't seem all that bad for when valid clients are trying to connect
2) Then when clients login send their password to server over SSL. I don't know anything about SSL and the thing that worries me is that I'm using a .net socket library that makes working with sockets so simple but I don't have the code just DLL's. What is involved with sending things over SSL and can it be used with any networking library?
Does using SSL mean clients have to install certificates on their side? Is that something the client actually has to do? Do those certificates expire and I'd have to release me ones? Does any actual online game today do this?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
