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?

  • 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 stackoverflow.com/questions/420843/…) or both. Commented Nov 9, 2011 at 20:09
  • Check out the OWASP website (owasp.org). They have lots of very useful security information, including "cheat sheets" for various protocols.
    – Ralph
    Commented May 24, 2013 at 14:46
  • There's some guidelines for forms based website authentication here stackoverflow.com/a/477578/463478
    – Only You
    Commented Oct 30, 2015 at 7:20

5 Answers 5


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.

  • 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. Commented Jun 1, 2011 at 22:09
  • This is good checklist. I'm surprised that there arn't more up-votes on it. Commented Oct 11, 2011 at 15:46
  • 2
    @Mr.Jefferson I'd say 99.999999% of the time you NEVER want to "roll your own encryption". Commented May 8, 2015 at 12:32
  • 1
    @Zach Leighton by roll your own do you mean using Microsoft's AES-256 .Net library to encrypt a file, or actually creating your own ZachL-296 algorithm. (The former, I didn't think of as rolling your own, the later, that's just insanity incarnate)
    – Reahreic
    Commented Feb 22, 2023 at 14:17
  • @Reahreic as long as you don't use ROT26 :-) Commented Feb 23, 2023 at 16:52

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


  • 1
    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. Commented May 23, 2011 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.

  • 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
    Commented May 23, 2011 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
    Commented May 23, 2011 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".


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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