[RESOLVED] Are my passwords safe?

[tcp]

I currently run ad list where the ads are stored in a flat file. Users create an 'id' and a password. The password is encrypted. Users frequently forget their passwords so they can't deleted their ad. I then have to manually edit the txt file deleting their listing. The list has over 700 submissions a month now so this is a problem.

I have switched part of service to a MySql database and have created a table to store login information, username and password. The passsword is NOT encrypted this time. If a user forgets his password forgot_password.php emails his password to him.

:eek: Should I have encrypted the passwords? If I encrypt the password, will I still be able to retrieve it?

Thanks

[laserlight]

Assuming that your database is never compromised, the passwords are safe. Of course, this is not a reasonable assumption, since "never" is too strong a guarantee to uphold unless you do not have a database in the first place.

Instead of encrypting passwords, which would require you to think about key management, a simple solution is to compute and store a hash of the password. When the user authenticates, you compute the hash of the password provided, and compare it with the hash stored.

As an absolute minimum, you should store salted passwords. Read this article on Password Hashing for more details. There are more comprehensive ways than just a salt, read Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes for yet more details.

Of course, since you do not store the original passwords, you cannot email the password to the user. You should then generate a new random password and email it to the user. Of course, you have to avoid denial of service attacks by only changing to the newly generated password when the user attempts to login with that password.

[visualAd]

tcp wrote:

I currently run ad list where the ads are stored in a flat file. Users create an 'id' and a password. The password is encrypted. Users frequently forget their passwords so they can't deleted their ad. I then have to manually edit the txt file deleting their listing. The list has over 700 submissions a month now so this is a problem.

I have switched part of service to a MySql database and have created a table to store login information, username and password. The passsword is NOT encrypted this time. If a user forgets his password forgot_password.php emails his password to him.

:eek: Should I have encrypted the passwords? If I encrypt the password, will I still be able to retrieve it?

Thanks

The easy answer is "it depends". It depends on how secure you want it to be. What damage would be caused if someone were to break into your database and steal all the passwords? How much will it cost you in money? How much will it cost you in time? Does the amount it will likely cost warrant the effort required to encrypt the data and the inconvenience experienced to your forgetful users?

My personal opinion would be Yes. Hash the passwords using md5 of sha1 and store them hashed. When the user forgets their password send them an email containing a link to a reset your password page. If you want more security still then you can also use a memorable question. Generally it is not a good idea to do anything with plain text passwords except hash them as soon as reasonably possible.

[Piranha]

When you think about the damage done if someone manage to steal the passwords think not only about your time and money. Also remember that users normally are lazy and use the same password on several sites. That means that if your site is compromized there is a big risk that the person can log in to other pages, like facebook. And even bank accounts. A scary thought.

If something like that happens you would get a bad reputation. You would have to announce that the database is compromized and users should change passwords, probably both by mail and on the site itself. And you would risk legas issues. I have no idea about the legal part of it, but the risk is enough for me.

To make it simple: At least hash the passwords. And do it with salted passwords as laserlight says. It's an easy way to guarantee that you have the security needed.

[laserlight]

When you think about the damage done if someone manage to steal the passwords think not only about your time and money. Also remember that users normally are lazy and use the same password on several sites. That means that if your site is compromized there is a big risk that the person can log in to other pages, like facebook. And even bank accounts. A scary thought.

Oh yes, I forgot about the other assumption. If your users never reuse their passwords, or never reuse any other identifying detail such as username and email address, then even if your database is compromised, it does not matter. The damage would already be done, and hashing the passwords would not help.

But of course, this assumption is again unreasonable, so hashing the passwords help.

[tcp]

Now I know why I was having that sinking feeling this morning when I looked at the last 30 entries in my user_table. Four had use the same password as username, one had used his telephone number which presumably will appear in the ad. 11 others had used dictionary words.

I need to encrypt.

Can I modify the existing password to an encrypted version and when user logs in, I use something like...

if ($submit) {
// $password is the password submitted
$str = "$password";
$hashed_password = md5($str);

...now compare to database to authenticate.
}

[tcp]

..but then again, encryption isn't going to do anything to help username = test password = test. Nor will it help the password = MyTelephoneNumber user or the guy who's password is apple.

So do I have this correct, encryption secures the data in that one cell of the account but not necessarily the account itself nor the database?

[laserlight]

Can I modify the existing password to an encrypted version and when user logs in, I use something like...

Yes. Note that encryption and cryptographic hashing is not exactly the same.

..but then again, encryption isn't going to do anything to help username = test password = test. Nor will it help the password = MyTelephoneNumber user or the guy who's password is apple.

That is true. The only way to help such people is to conduct a strength test of the password and reject attempts to use a weak password.

So do I have this correct, encryption secures the data in that one cell of the account but not necessarily the account itself nor the database?

Yes, password hashing protects your users' passwords in the event that your database is compromised. It does not prevent your users' passwords from being intercepted en route to your server (you need SSL/TLS for that), or increase the security of your database/server in any way.

[Piranha]

First there is a big difference between encryption and hashing. When you encrypt something you can decrypt it to get the information back. When you hash it you store a mathematically computed number that can't be reverted back to the information. In other words, you can't retreive the password if you hash it, that's why it is preferred. Everything talked about in this thread this far is hashing, not encryption.

Hashing of passwords doesn't solve the problem with stupid users. For example users using their username as password, phone number, childs name, dictionary words or something simular. It can't secure the database either, it is simply impossible. If someone gets the password in the database (hashed or not) the database is already "hacked" and all the information in it is visible to the "hacker".

What hashing passwords do is exactly what I talked about in an earlier post. It saves your users passwords since they probably use them in other places as well.

Oh, another thing you should look at is "SQL injection" or "database injection". It is a way for users to get information from your database that you didn't want to give them, it could even be used to change or delete your database.

[tcp]

Thanks, I should have understood there was a difference between encryption and hashing from the previous posts.

Consider the following plan:

1) Hash existing passwords saved as plain text.
2) Hash all new passwords as they are created.
3) Implement a script where the user can reset his "forgotten" password.

I am afraid to ask. My user_table is in the same database (different table) as the ad listing information. Is this ok from a security stand point?

[laserlight]

Consider the following plan:
1) Hash existing passwords saved as plain text.
2) Hash all new passwords as they are created.
3) Implement a script where the user can reset his "forgotten" password.

Sounds good.

I am afraid to ask. My user_table is in the same database (different table) as the ad listing information. Is this ok from a security stand point?

Yes, since the user may access the user_table to authenticate, change passwords and such anyway.

[visualAd]

tcp wrote:

Thanks, I should have understood there was a difference between encryption and hashing from the previous posts.

Consider the following plan:

1) Hash existing passwords saved as plain text.
2) Hash all new passwords as they are created.
3) Implement a script where the user can reset his "forgotten" password.

I am afraid to ask. My user_table is in the same database (different table) as the ad listing information. Is this ok from a security stand point?

In addition and especially if you are not using SSL to encrypt communications; I would suggest the use of a Javascript to hash the password on the client and to add a little more security send a session salt along with the login page which will help prevent replay attacks and prevent a man in the middle attack whereby the hashed password is required.

• User makes request for logon page.

• The server generates a logon salt which is sent as a hidden field within the logon page as a hidden field and stored in a session variable.

• The user enters the password and user name and presses the submit button.

• JS intercepts the submit, concatenates that salt and password then applies a one way encryption function to generate the hash.

• The hashed password and salt are sent to the server along with the user name but not the entered password.

• The server hashes the password and the logon salt when the request is received and compares them.

While this helps secure the communications somewhat it does prevent you from storing the password with salt in the database. But there is a way of sending both salts together:

• User makes request for logon page.

• The server generates a logon salt which is sent as a hidden field within the logon page as a hidden field and stored in a session variable.

• Server uses user password and the logon salt to encrypt the password salt and sends this in another hidden field.

• The user enters the password and user name and presses the submit button.

• JS intercepts the submit and uses the password and logon salt to decrypt the database salt.

• The logon salt, database salt and password are then concatenated and a one way encryption function is applied to generate the hash.

• The hash of the password, logon salt and database salt are sent to the server along with the user name but not the entered password.

• The server hashes the password and the two salts when the request is received and compares them.

You could see the above as a challenge response like protocol, although these usually include a three-way handshake. The problem with these solutions is they do rely on Javascript; so in all cases SSL is the better option, worth the investment and eliminates possible bugs with any security mechanisms you may implement.