Forum Thread: How Do Sites Keep Their SQL Passwords?

Hi which language are you using to connect to the database? if you are using php then the best way to store your username and password would be in a seperate connection.php file it doesn't matter that it is in plain text as you cant view php code like you can html source your best way to be secure would be to make sure that the user that connects from the site only has the permissions that it needs I hope this helps

It depends on the language you're writing in. In your connection code, you should at least consider encrypting the MySQL password in the state you have saved as text (so the password its self is not human readable), and decrypt it in memory during init. Obfuscation is another simple step you can take when dealing with code that does not compile to help keep the undetermined out (for a starters, don't name your file "connection.php"). While the text of your source code is typically safe if you've locked down your environment, you never know when a new exploit may be discovered that could give someone access to the files that contain your connection string. A skilled programmer will probably still figure it out fairly easily if determined to get in... But at least the bots/script kiddies won't. Hopefully in such an event, the extra hoops will buy you enough time to change your passwords.

Thank you two. It is in python. I am thinking about having a file that only the account the scripts are running on can read it. That should help.

Yes. Also wise to lock down MySQL to run on a non standard port and only accept connections from your web server (or a private VIP if running on the same machine). All speedbumps, but buying time in case of an intruder is wise.

I already have the server itself locked down, also only allows accepting from localhost and changed the port to outside of 10,000. If you know the workings of nmap you know why.

Here is how most sites do it. They use a thing called a hash. A hash is like an encryption, but it is a one-way encryption. This means it is impossible to decrypt without brute forcing (trying every possible combination of something until you get a hash matching the one you just stole from a database, if you're a hacker). Think of it like this: 1 + 2 = 3. So sure, we know 1 + 2 and 2 + 1 both equal 3. But which combination was the original password. Hashes are like this in the sense that they cannot be decrypted. However, with this logic, both 1 + 2 and 2 + 1 could be considered to be the correct password. This is why hashes are much larger, and much more complex. So basically, the chances of two passwords producing the same hash are almost non-existent. So how does this all work? Well, when a user registers, they input a password. Your php code will then convert the plain text into a hash. For the longest time, and even today, MD5 has been used. But the most secure will be something like SHA or SHA2, but the idea is the same. So the person enters their password, the code converts it to a hash. The hash is stored in the database. When the user logs in, the password they input is converted into a hash. The same password means the same hash will be generated, so you just compare the hash made from the login password with the hash in the database. Are they the same? If so, the password is correct. This, of course, has a downside. If a user forgets their password, the ONLY WAY to fix it is to reset the password to something random, give that random password to the user (usually via email), and then tell the user to log in and immediately change their password. Also, what others have said about properly securing the databases also applies. Someone with enough computing power could use software to brute force a password from the hashes. Of course, doing so would take a VERY long time.

While that's a great first step in storing user passwords (hopefully most sites at least use a salt as well to help mitigate rainbow tables), OP was asking about how to securely store the password his/her code uses to connect to the DB in the first place.

Yes I know how to hash and yes my database does hash things.