I’m really sorry if this question has nothing to do on this site, but I thought since there’s alot of great minds here.
In the near future I’m going to create a program where users will have their own accounts, so I’ve started to think about the security, which is why I have to ask since there’s a few aspects that I thought about and I’m extremely concerned.
-
Obviously, I shouldn’t store cleartext passwords in my database, the program that the user will send their information from will encrypt it, is it this encrypted password that I store, or should the server encrypt it again and store that one instead? Or some other solution.
-
When validating, should I simply compare the encrypted password that I got with the one stored or should there be some decryption going on?
That pretty much covers my wonderings about how I should handle passwords, but I have a problem with the potential problem of hackers.
-
Is it possible for a person to intercept any traffic going on in the world, or only the local network?
-
Let’s say a hacker get a hold of all packages beeing sent to the server, the password is encrypted so there is no way he can get the cleartext password, but wouldn’t it be possible to resend the packages and thereby tricking the servers to login the hacker?
If the answer to the last question is yes, in my mind there’s no way of keeping things secure no matter how good you encrypt it since the data is still useful.
Someone that know how things work? Maybe work as a security administrator (or such) that can tell how they do it in your company (of course don’t reveal sensitive information!)? I don’t ask for encryption methods, but for the logic behind keeping things secure from unauthorized people.
* EDIT *
I actually found how to process and store passwords, so that’s no longer a problem. I’m still curious about resending packages though.
I will walk down each of your points and provide the baseline for what you should be doing and then the “more secure” way of doing things.
You should never, ever store encrypted passwords in the database, use a hash.
So the baseline way of doing things like this is to use an MD5 hash over the users password. The more secure way of doing this type of hashing is to use a cryptographic hash such as SHA-2. The reason why we don’t store encrypted passwords is that you can reverse encryption, but you cannot reverse a hash. You can only find a collision. Now the fact I said MD5 will cause a lot of griping in both this and the security community. MD5 is not as broken as many would like you to believe, but it is far less secure than SHA-2. USE A SALT
Refer to the above.
Both. If I am on your network, irrespective of it’s location, I am on the local network. If you are broadcasting your data in an insecure manner I can most definitely intercept it.
I believe you mean packets. The password is encrypted does not prevent me from getting the clear text password. It just slows me down, because if I have intercepted the correct packets I can break the password offline. A replay attack, as it is known, would not allow for the system to “be tricked” into logging someone else in. However, once I retrieve the clear text password, I would just use the username associated with it and log in. Now this is not to say things like SQL injection would not allow me to circumvent the need to grab packets. So a replay attack is not going to work unless you are doing client side encryption (please jeebus don’t do this) and not uniquely identifying the requests coming into your system. So imagine I am attacker A and I have intercepted an encrypted password. I can work some magic and get into the system. Now if we take this a step further and apply a randomly generated value that uniquely identifies the original packet we can determine that it does not match the expected input. Essentially encryption alone does not save you.