Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Given is a system of PHP and MySQL on a virtual server.

I want to save passwords there. Frequently you hear people speak about their system being hacked and credit card information being stolen.

According to current knowledge where should you store passwords on your server and how do you protect them?

share|improve this question

migrated from Nov 29 '12 at 0:13

This question came from our site for professional and enthusiast programmers.

up vote 1 down vote accepted

If you are storing user passwords I recommend using Salt.

Essentially you have two tables

tblUser(userID, userPassword)

tblUserKey(userID, userKey)

store a hashed user password in tblUser and a hashed Key in tblUserKey table.
The user password is decrypted using the individual users hashed key.

This makes each password completely unique and would be much more difficult for a hacker to decrypt if they would get access to your tables.

Salt Password Hashing Walk-through on a variety of platforms

share|improve this answer
Please elaborate this further. I created the two tables. So let's say I want to create the userpassword. How do I create it? I found salt to be dealt with differently at…. What is your approach exactly? – Peter Fren Nov 28 '12 at 18:24
Shouldn't crypt() be sufficient? – Peter Fren Nov 28 '12 at 18:30
@PeterFren the example you linked too looks fine. I agree that the salt should be randomly generated. I store my salts in another table for the added security of a potential hacker needing to have both tables in order to crack the passwords. – Malkus Nov 28 '12 at 19:03
How do you use – Peter Fren Nov 28 '12 at 22:05

You just need to know some basic details:

  • Hackers can't access database's column name, so never name your password's column password or pass, use something nobody can guess
  • To store some important/sensible data in your database like password or credit card numbers, you should use a one-way encrypt function, like md5() or sha1(), when an user store his password in the database, you hash it THEN store the encrypted data in your database, when your user want to login, you hash again and then compare with the one you stored before, this way, even if a someone hack your database, he will only get some encrypted data, and won't ba able to decrypt because this is one-way crypting.
  • Don't forget to puts a login, a password and access rights on your SQL server, default is root:'' so if you got an interface like PhPmyadmin, anyone could just connect on it and access your databases data
  • Hashed passwords aren't secure nowadays, so you might want to "salt" your hashed data, To salt a hash, just add some caracters before the hashed data, like XYZ for instance so even if your hashed string is cracked, the hacker will not be able to find the XYZ you put before it
share|improve this answer
Replace "encrypt" with the word "hash". – jishi Nov 28 '12 at 14:54
I got phpmyadmin on the server. When I login to my server via plesk I can access phpmyadmin without addition pw and username. when I connect to the db via php I use a pw and username. So is it protected or not? – Peter Fren Nov 28 '12 at 15:01
Ask yourself: can someone who don't know anything about your server type an url and instant-access your phpmyadmin page ? – Weacked Nov 28 '12 at 15:03
-1 because "hackers can't access database's column name" isn't necessarily true and because md5 and sha1 have been bad ways to hash passwords for a long time now. Also phpMyAdmin, in my experience, hasn't been available to the world. – arxanas Nov 28 '12 at 15:28
A friend of mine read out my entire database, printed it out and showed it to me, just to prove that he could. It included column names. He was able to access it over a numeric id I was using to fetch various pages. – primo Nov 28 '12 at 18:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.