I remember seeing a way to have an such that the browser will not prompt the user to save the password. But I'm drawing a blank. Is there an HTML attribute or some JavaScript trick that will do this?
I also agree this should cover any field that contains truly private data. I feel that it is alright to force a person to always type their credit card information, CVC code, passwords, usernames, etc whenever that site is going to access anything that should be kept secure [universally or by legal compliance requirements]. For example: purchase forms, bank/credit sites, tax sites, medical data, federal, nuclear, etc - not Sites like Stack Overflow or Facebook.
Other types of sites - e.g. TimeStar Online for clocking in and out of work - it's stupid, since I always use the same PC/account at work, that I can't save the credentials on that site - strangely enough I can on my Android but not on an iPad. Even shared PCs this wouldn't be too bad since clocking in/out for someone else really doesn't do anything but annoy your supervisor. (They have to go in and delete the erroneous punches - just choose not to save on public PCs).
Here's the best answer, and the easiest! Put an extra password field in front of your input field and set the display:none , so that when the browser fills it in, it does it in an input that you don't care about.
In the case of most major browsers, having an input outside of and not connected to any forms whatsoever tricks the browser into thinking there was no submission. In this case, you would have to use pure JS validation for your login and encryption of your passwords would be necessary as well.
All of these are within the forms section. "person" and "mypswd" are what you want, but the browser will save "userid" and "passwd" once, and never again since they don't change. You could eliminate the "person" field if you don't really need it. In that case, all you want is the "mypswd" field, which could change in some way known to the user of your web-page.
It seems that this html code needs to be standardized with the browsers. the form type = password should be revised so that it overrides browser settings. The only issue I have is that I lost my input masking. But on the bright side the annoying "this site is not secure" is not showing up in firefox.
But I have noticed a behavior in modern browsers, such as Chrome/Firefox, which shows up a notification bar to save the user name/passoword even though that particular web page does not have any "remember password" check box.
The "save password" part comes from the browser's password manager whenever it sees an that looks like it really is asking for a password. You can use the autocomplete attribute to suppress this in most browsers:
The "remember me" part is completely separate from the browser's password manager. The "remember me" flag is the server's business and all it does is fiddle with the expiry date on the cookie that it sends back. The server will always send a cookie back (unless they're not using cookies for tracking sessions but that's rare and wouldn't need a "remember me" anyway) with something inside it to identify the client user.
If you check "remember me" then you're telling the server that you want a persistent session. To achieve this, the server will include an expiry date with the cookie and that expiry date will be some time in the future. When the date arrives, the browser will expire and delete the cookie; without the cookie, the server won't know who you are anymore and you'll have to login again.
If you don't check "remember me" then you'll get a session cookie. Session cookies don't have expiry dates on them so automatically expire when the browser exits. Session cookies are useful for shared machines.
The session id is stored in the cookie. AFAIK, the password, or the hash of it is not stored. A session is created on the server side whenever you log in. If you logged in with "Remember Me" checked, the server passes a cookie with the session id (or encrypted session id, or something that uniquely identifies the user session) and this cookie is saved on the client side.
When you login for the next time, the server checks whether there is a cookie with the session, if it is there (and the session has not been killed/expired - see point 2 below) then the server identifies you as "Veera" and lets you in the site.
The difference between the server remembering you and the browser remembering your password is whether your password is saved or not. And combined with the option of "Logging out all sessions" this is a lot better than letting the browser save your password.
You will need a way to know who the user is. Normally this is done by saving a cookie on the users browser. You should only use something that is not easily spoofed and so encryption should be used. You could use local storage, so long as you are confident that all browsers that will be used on your site support it.
One of the joys of working for a government healthcare agency is having to deal with all of the paranoia around dealing with PHI (Protected Health Information). Don't get me wrong, I'm all for doing everything possible to protect people's personal information (health, financial, surfing habits, etc.), but sometimes people get a little too jumpy.
Case in point: One of our state customers recently found out that the browser provides the handy feature to save your password. We all know that it has been there for a while and is completely optional and is up to the end user to decide whether or not it is a smart decision to use or not. However, there is a bit of an uproar at the moment and we are being demanded to find a way to disable that functionality for our site.
Question: Is there a way for a site to tell the browser not to offer to remember passwords? I've been around web development a long time but don't know that I have come across that before.
The easiest and simplest way to disable Form and Password storage prompts and prevent form data from being cached in session history is to use the autocomplete form element attribute with value "off".
@Joseph: If it's a strict requirement to pass XHTML validation with the actual markup (don't know why it would be though) you could theoretically add this attribute with javascript afterwards but then users with js disabled (probably a neglectable amount of your userbase or zero if your site requires js) will still have their passwords saved.
I had been struggling with this problem a while, with a unique twist to the problem. Privileged users couldn't have the saved passwords work for them, but normal users needed it. This meant privileged users had to log in twice, the second time enforcing no saved passwords.
With this requirement, the standard autocomplete="off" method doesn't work across all browsers, because the password may have been saved from the first login. A colleague found a solution to replace the password field when it was focused with a new password field, and then focus on the new password field (then hook up the same event handler). This worked (except it caused an infinite loop in IE6). Maybe there was a way around that, but it was causing me a migraine.
Finally, I tried to just have the username and password outside of the form. To my surprise, this worked! It worked on IE6, and current versions of Firefox and Chrome on Linux. I haven't tested it further, but I suspect it works in most if not all browsers (but it wouldn't surprise me if there was a browser out there that didn't care if there was no form).
Well, its a very old post, but still I will give my solution, which my team had been trying to achieve for long. We just added a new input type="password" field inside the form and wrapped it in div and made the div hidden. Made sure that this div is before the actual password input. This worked for us and it didn't gave any Save Password option
You can prevent the browser from matching the forms up by randomizing the name used for the password field on each show. Then the browser sees a password for the same the url, but can't be sure it's the same password. Maybe it's controlling something else.
Note: this will effectively stop password autofill, because FF will "save" the value of #prevent_autofill (which is empty) and will try to populate any saved passwords there, as it always uses the first type="password" input it finds in DOM after the respective "username" input.
Also, add two methods. one for validation "validateLogin()" and another for listening enter event while click enter in textbox/password/button "checkAndSubmit()". because now login form does not have a form tag, so enter event not working here.
Not really - the only thing you could realistically do is offer advice on the site; maybe, before their first time signing in, you could show them a form with information indicating that it is not recommended that they allow the browser to store the password.
Having a browser save your passwords actually increases protection against keylogging, so possibly the safest option is to save passwords in the browser but protect them with a master password (at least in Firefox).
You could make a custom font hack. So, make a custom font, with all the characters as a dot / circle / star for example. Use this as a custom font for your website. Check how to do this in inkscape: how to make your own font
The simplest way to solve this problem is to place INPUT fields outside the FORM tag and add two hidden fields inside the FORM tag. Then in a submit event listener before the form data gets submitted to server copy values from visible input to the invisible ones.
My js (jquery) workaround is to change password input type to text on form submit. The password could become visible for a second, so I also hide the input just before that. I would rather not use this for login forms, but it is useful (together with autocomplete="off") for example inside administration part of the website.