Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

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

I got a question today from my manager asking me my thoughts on what is considered an acceptable design for authentication of a web form application, especially in regards to the nature of many popular browsers to "Remember Password" for your typical user name password login fields.

I am having trouble coming up with an answer that I feel is acceptable. In light of Sony's embarassing security flaws, I really want to be careful, even though the data being stored on people is of a lower sensitivity. We are not storing social security numbers or even addresses however we are storing phone numbers, email addresses and a photo of a visitor.

He is concerned that a user can simply Remember Password on a public terminal, then someone can simply jump on this terminal and begin viewing or modifiy data in an unauthorized way. I am fairly certain however that at least on Windows workstations that the browser will not "Remember Password" across Windows user accounts.

Beyond this I am implementing a one way password encryption at the server side (store encryped password in the database, encrypt user supplied password on the server, compare to encrypted string from database). There are no immediate plans to incorporate SSL encryption however this is still an option.

Are there are any major security flaws with this approach? Do you have any better suggestions?

share|improve this question
When storing the one-way encrypted (i.e. hashed) password, make sure you either use a strong hash (i.e. not MD5) or salt the password (see…) or both. – Jordan Reiter Nov 9 '11 at 20:09
Check out the OWASP website ( They have lots of very useful security information, including "cheat sheets" for various protocols. – Ralph May 24 '13 at 14:46
There's some guidelines for forms based website authentication here – Only You Oct 30 '15 at 7:20
up vote 11 down vote accepted

Some high level tips:

  1. Store only the data you need
  2. Always encrypt sensitive data (SSN, password, credit card #, etc.) when you store it
  3. Always encrypt traffic using SSL when transmitting/receiving sensitive data
  4. If in doubt about the sensitivity of information, encrypt it
  5. Don't trust user input (someone will try to enter something bad)
  6. Don't trust your data (someone can change it in the database - injecting malicious script for example)
  7. Don't roll your own encryption
  8. Secure the servers hosting the applications / databases
  9. Increase the burden on end users for the sake of security (password restrictions, never expose passwords, don't send URLs in email, reduce session time, etc.)

My suggestion to you would be to get a book on securing Web applications. There is just too much information to convey in a single answer / blog / article. The topic of encryption alone is substantial.

share|improve this answer
Thanks, that is a good checklist. – maple_shaft May 23 '11 at 19:09
What's the reasoning behind using SSL instead of rolling one's own encryption? Would you consider using something like WS-Security rolling your own encryption? Setting up SSL can be a pain. – Mr. Jefferson Jun 1 '11 at 22:09
This is good checklist. I'm surprised that there arn't more up-votes on it. – Kristofer Hoch Oct 11 '11 at 15:46
@Mr.Jefferson I'd say 99.999999% of the time you NEVER want to "roll your own encryption". – Zach Leighton May 8 '15 at 12:32

You can attempt to over-ride the browser behavior - some good advice here:

share|improve this answer
Good link. I personally don't think it's our business as developers to override user choices like that, but I have done a site for a client who demanded it, so it's important to know how to do it. – Carson63000 May 23 '11 at 21:03

I'd say you should be fine.

Most users are going to be bright enough to not save their password on a public terminal, and the passwords are going to be stored per profile. Keep in mind they could just as easily write it on a sticky note or use a weak password.

If the login page is not encrypted over SSL it wouldn't be too hard for an attacker to sniff that password as it travels over the network. Good job hashing the password in the database though, that will prevent a potential attacker from seeing everyone's passwords (which they could use with the email address to attempt to log into other sites the user might be on.)

If you'd still like to, there are ways to disable the browser's behavior as Chad has pointed out. I've only seen this myself on my bank's website and Microsoft's Live system.

share|improve this answer
Great post, I forgot to add though that the username will not be the email address, however a user will have an email address stored in the system. Funny you mention this though because even popular sites like Facebook are susceptible to packet sniffing for email addys and passwords. – maple_shaft May 23 '11 at 18:49
I also want to add that I am not pointing out the security flaws in Facebook as an "excuse" necessarily for a poor security model in my application. Just because Joey's mom lets him watch rated R movies doesn't make it right :) – maple_shaft May 23 '11 at 18:51

At a certain point, you can't (and are not legally required to) protect a user from themselves. "Remember password" functionality may be risky, but it's a risk assumed by the user. Likewise, if the user decides to reuse their password for multiple services, they assume that risk as well. You are also not required to warn them not to write their password down on a sticky note and stick it to their monitor, even though users often do this too.

That is, until someone successfully litigates and changes the rules. See also: "Warning: contents may be hot".

share|improve this answer

I dont think you can reliably control whether or not the browser remembers a password. Its simply out of your hands whether the browser does that or not. Nor is it necessarily a huge security risk for you. You should always assume that attacks can be made from valid logins. Dont assume because someone has a valid login user/pass that they wont be up to no-good. There are many ways passwords can fall into the wrong hands, after all.

I guess What you could do is randomize the field names in your login form each time. Instead of <input name="username", use something like <input name="user658667587". That would make cached usernames fairly useless. But I dont know if the overhead would be worth it. Not to mention inconveniencing users who arent on public machines.

If you are in an extremely security sensitive situation (banking, investing) you could simply ask people during logon whether its a public machine. You can also cache known IP addresses when people log in, and if they login from a different location require a non typeable pin number (ex, click the images) in addition to normal user/pass. My bank does something akin to that.

share|improve this answer

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.