Forum Moderators: open
I was storing & checking user passwords using PHP/mySQL password() functions. This stopped working with the upgrade, and I learned that password() is really only supposed to be used for mySQL passwords.
I trying to decide if I should switch to sha1() hashing or if I need to encrypt user passwords at all (it has been a headache on several fronts).
None of the information I collect is sensitive. There especially is no payment information. Is it all right to store passwords without any encryption and just leave them in the clear.
I know people recycle passwords, so the ones they enter into my system will likely be the same as forother uses, but does that create a big security flaw?
I think you're fine to put unencrypted passwords into your database.
Encrypt your passwords before they hit the DB if MySQL no longer supports it. But, for the love of security, KEEP THEM ENCRYPTED. "Sensitive" data or not, it's just good practice. Plus, you can help save users from themselves, for the ones who reuse passwords across multiple sites.
Chip-
common practice is to store the MD5 of the password, then when they enter their password in your login form you MD5 that and compare it to what is stored in your database.
So long as the users have email addresses, this system is mostly maintenance (and headache) free.
You have to design your security system based on your own unique risks etc.
My advice would be not to store passwords in relational databses, or if you decide the risk is low enough to do so, then theres no gain from encypting them.
then provide a self service "send me a new temporary password"
Also, the "new" and "temporary" was intended to convey that their original password (whatever it was, the point in one-way encrypting it is it is not retrievable by anyone) is not being sent. The script generates a random password that is emailed to the user. Write the script so that the random password is only valid for a limited time period. You can also require that they immediately choose a new password.
I've seen sites that send a one-time use URL to a "set a new password" page to the user's email account, but I fail to understand how that is any more secure than sending a new temporary password to the user's email account.
My advice would be not to store passwords in relational databses
Where do you recommend storing them?
Use SSL and protect all data transfered. If you need to remind people of their passwords there are ways but I think you will find that several of even the major companies / sites will straight up email you your password after you jump through a few hoops. I mean you could sent off a PGP key to them then send them the password in a PGP Singed Message.
Reduce your liablity with disclamers. You aren't doing anything wrong by storing them unencrypted as long as your server has sys admin that knows what he is doing.
You could consider an object oriented database rather then a relational one.
what happens in this scenario:
your DB gets compromised and you are storing passwords in clear text. OK, the hacker has access to your users' accounts, but that is moot since they have access to all the data anyway.
BUT - now they have email addresses/usernames with associated passwords. How many people use the same username/email/password for web stuff? A ton.
By encrypting your passwords in the DB, you remove this viral security hole.
Chip-
If they gain access to the DB then they have access to the decryption keys. So what has encypting done for you other then make plain text recoveries of the password more difficult?
what happens in this scenario:
your DB gets compromised and you are storing passwords encypted. OK, the hacker has access to your users' accounts and the backend goodies that the database uses for encryption including the keys for decrypting said passwords. Making the encyprtion moot.
How is this better? If your server is hacked you are in trouble, PERIOD. You can make it harder for them but don't make the mistake of thinking because you have encrypted that it that it is hack proof. Like I said your passwords are as safe as the server machine they live on.
You don't ever want to be in a position where you, as a developer, can unencrypt some one's password. Certainly not so that it can be emailed to the user. Email isn't secure enough to have your primary passwords being emailed around.
But you bring up a good point - databases and web servers don't belong together unless really constrained by money. Your DB server shouldn't be accessible from the web. That's a strong layer of security right there :)
Chip-
PS: I can't think of any large sites that email you out your primary password. what are some?
Re the comment about email addresses - this is a completely different issue to a password for a guestbook or free forum. Under UK Data protection law and EU directives you have a legal responsibility to take proper care of customers personal data which includes thier email adresses.
I still don't see the point of encrypting, if someone gets into your server and the DB is on there. Then what are they going to do with passwords? They are in the server. I doubt they are going to log out as root or whatever they have gained as then start logging into the website as users. They have the database and the server, they can do already do whatever they want.
I was thinking of this like a bank. Let's say you rob a bank, you get in the building(the server) you crack the safe(database) you gain entry and then there is a little puzzle box(encypted passwords)in the vault that has all the good stuff. Would the robber then throw up his hands and be like,
"Well I got this far but this stupid puzzle box is here so I guess I'll give up"
Someone who spends the time getting that far is going to figure out a way to smash the box open and get want he wants. No one who has the knowlage to get that far is going to give up simply because some form of encryption is there.
If your hacked your F***ed.
For major creit card companies and the like then they have to take the steps to reduce liabilty. But for things where a company has members and an intranet why would you bother?
because it's the right way to do it. Reduce risk.
>> no onger email your password, they simply allow you to set a new one once you have jumped through their hoops.
exactly how it should be done
also rememver that if your employees have access to db then they would be able to see clear text passwords and then could log into someone's account. Protection isn't only from the outside.
hacked is also a bad term and people use it interchangably for a lot of things.
yes if your server is hacked you are in big trouble but if the passwords aren't available then a simple theft of passwords can't happen.
>> 6I doubt they are going to log out as root or whatever they have gained as then start logging into the website as users
yes they actually might depending on what your business is, the simple theft of the passwords could be the goal.
try passing a security audit storing plain text or decryptable passwords, won't happen.
As opposed to sitting on the server and trying to figure out how to move funds via SQL or something.
It just good practice.
I also said if it is some intranet thingy then why bother, because really what can they do with the passwords, if they have gained to the server or database?
Anything they can log on to the site and can do with a members username and password they can do with root access on that same server machine which is why I said if someone gains access to your server machine as root then they can already do everything. Anything the website will serve up lives in code on that box and using the web interface is not needed once you have gained full access. I mean if they have access to the database and they want to use the web interface and the database is the look up for roles and member account info they can just creat themselves an account with the highest role and have their way in the web interface as well.
If anything, encrypt the emails because that and CC numbers are what most are people are after, that or your servers processer and bandwidth resources.
Other then, "it is the right way to do it" I haven't heard any compelling arguments to encrypt. Unless there is something valuble to protect, I don't see the point. Reduce your liablity on what? He said there is nothing other then some personal info and if that is stored in the database on the server then encypting user passwords is not going to make it safer. Nor will it make the PDF that is behind the logged in area safer. Because that is on the server too, and if they have gained access to the server they already have what they need.
But 100% for sure if you do encrypt it might as well be one way.
Reason to encrypt.
- The password could be the same password someone uses everywhere and could be used to gain access to personal PCs or other things.
- If an SQL injection can be executed that someone could pass in a select statment "select password from member;" then this would not give up anything and the server has not been hacked.
MMMmm crow.
I always look at it the opposite way
when it is so easy to do, why wouldn't you?
Unless you understand security and the real risks you will make the wrong decisions.
Poor Example:
$hash = md5( ($_POST['password'].'somestringyouappendeverytime') );
Added: Because when it's an md5 hash of the input you wouldn't even need the exact password -- just another string that evaluates to the same hash. (There's an infinite number of string variations, and only 3632 possible md5 results.)
I think it was most of the same people in the thread too ;)
