Website login system security

March 10, 2008 8:10 AM

Security requirements for a php website login system.

I am building a website which will have a member login system. In my prototype, the user had to confirm via email before they were registered. The client wants to miss this step, and have them immediately access the members area. My 'forgot password' had a random temporary password sent to the account email address, which the user would login with, my client wants the actual password sent out. Finally, the client wants to use the email address as the login/user name, and wants the user to be able to change this email address.

I have a feeling that doing things the clients way will not be good security, but am having trouble articulating exactly why. Can anyone help me define the flaws (or tell me I am being overcautious). The members area will have details like address, phone number etc if that has implications.

posted by zingzangzung to computers & internet (9 comments total)

Obviously, the only safe thing is to encase the web server in lead and sink it to the bottom of a well.

But seriously, you need to tell the client what could go wrong and see if it is OK.

"Someone could obtain access to customer email, then change the username and become them."

"Since passwords would need to be stored using reversible encryption to send them to the user, (you ARE at least encrypting them, right?) then an unscrupulous admin (or password reset customer service monkey) could obtain the password and masquerade as the user. We couldn't detect this."

Does the random temporary password work in addition to the old password or does it replace the old one? if it replaces, then an evildoer can deny anybody access to the site by telling it that the target user lost his/her password, thus resetting it. Temporary, but annoying.

We generally prefer to email reset codes to users who lose their passwords. The link is unguessable and is only good for 24, 28 whatever hours. The old password still works if they reset code isn't picked up.

It isn't perfect (see encased in lead above), but it is usually a tradeoff we can live with. Oh, and we log absolutely everything related to logins.
posted by mrbugsentry at 8:22 AM on March 10

Well, you can't really just have the email address as the key for the account record, otherwise by switching the email address and not requiring confirmation someone could take over another's account.

Also, if the email address is displayed to identify the user in a forum or something, by not requiring the email confirmation someone would be able to impersonate an email address they aren't the owner of.

You might consider OpenID, which would allow a user with a Yahoo mail or Google mail or various other OpenID-supported email addresses to simply log in via their email account. If you require OpenID you're getting to basically offload many of your security concerns to the OpenID provider, which if you prominently display your other users will be able to evaluate on their own. Here's a fabulous Google Tech Talk on OpenID.
posted by XMLicious at 8:28 AM on March 10

The problem with sending the password via email is that many people use the same password for everything. You could be sending their bank password in clear text. That's why it's good practice to hash/encrypt passwords in the database, too. I'm not sure you'd be liable in case the password fell into malicious hands, but why take a chance?
posted by bricoleur at 8:59 AM on March 10

I'm with your client. The email confirmation is old school. All you are verifying that the email was valid for those few minutes, and it's just an extra hoop for the user to jump through. It certainly doesn't protect against spambots or fake registrations. Personally, I use temporary inbox whenever a site requires email validation. Also, many people have an email address dedicated for signups.

(btw, if you offered to send something useful, then there is an incentive to provide an email adresss that is regularly checked.)

storing passwords "encrypted" (e.g. md5) is nice. and of course you can't send out the password if they forget it, so you'll need to use a the temporary password feature that mrbug outlines. It basically is an extra column in the db where a random password is stored.
posted by kamelhoecker at 9:09 AM on March 10

but i disagree with the client that you should send passwords out in plaintext.
posted by kamelhoecker at 9:10 AM on March 10

md5 is good, but google is making it easier to turn a md5 hash back into a plaintext password.

Moral of story: use a good password, numbers, letters, punctuation, caps, symbols... and nothing directly from a dictionary.

ideally you'd store the hash of the password plus some other string (known as a 'salt').
posted by Wild_Eep at 9:37 AM on March 10

For god's sake don't roll your own password library. These problems have been solved, for example.

The usual rationale for requiring a valid email address is to reduce trivial bot-signups. Email addresses are easy to get but substantially harder to get in plausible bulk that's not easily block-able. Especially if your accounts are free (i.e. no manual intervention) and doubly, triply so if those accounts can post publicly-viewable content somewhere on your site. XSS/XSRF attacks are the New Hotness and they're not trivial to filter for.
posted by Skorgu at 10:38 AM on March 10

The reason it's better to send out a password reset request, or a randomly generated password to the registered user is for two reasons, one highlighted by bricoleur, the other being that someone using that persons computer could request a password, read it, delete the email. Now that person has full access, but the real user has no way of knowing. If instead a password reset, or random is sent, then the real user is locked out and therefore has a reason to investigate why.

Using emails for usernames is perfectly fine. A number of big sites do it-- XMLilicious mentioned that people changing emails could cause problems, but really? What minisule percentage of people does that happen to? Certainly not enough to care. People might collect a couple of email addresses over their 'net lifetime, but they rarely, if ever, delete them (even if they could)-- you also save on the frustration of people trying to find usernames that aren't taken. Hello Roberttt19278.


Wild_Eep:md5 is good, but google is making it easier to turn a md5 hash back into a plaintext password.

Not really, you're assuming you have the MD5 hash in your hands. If you do have that, then you've already broken right into the depths of the database and the site owner is in far, far more trouble, since from that level you've got access to everything.

In reality all you have is a true or false. When you submit the password field, it gets turned into an MD5 hash and a compare is done, all that's returned is 1 or 0. So you can only brute-force the password, there's no reverse engineering possible because the hash is hidden to you.
posted by Static Vagabond at 10:57 AM on March 10

Static Vagabond: merely asking this question leads me to assume that the asker has little experience with online security, meaning silly things like validating with javascript on the client or a bug leaking hashes aren't out of the question. Better to assume the worst case in situations like this, especially when it's no harder to implement.
posted by Skorgu at 11:33 AM on March 10