Trying to prevent the browser from storing passwords is not a recommended thing to do. There are some workarounds that can do it, but modern browsers do not provide this feature out-of-the-box and for good reason. Modern browsers store passwords in password managers in order to enable users to use stronger passwords than they would usually.
Modern browsers implement integrated password management: when the user enters a username and password for a site, the browser offers to remember it for the user. When the user visits the site again, the browser autofills the login fields with the stored values.
Additionally, the browser enables the user to choose a master password that the browser will use to encrypt stored login details.
Even without a master password, in-browser password management is generally seen as a net gain for security. Since users do not have to remember passwords that the browser stores for them, they are able to choose stronger passwords than they would otherwise.
For this reason, many modern browsers do not support autocomplete="off" for login fields:
If a site sets autocomplete="off" for a form, and the form includes username and password input fields, then the browser will still offer to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.
If a site sets autocomplete="off" for username and password input fields, then the browser will still offer to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.
This is the behavior in Firefox (since version 38), Google Chrome (since 34), and Internet Explorer (since version 11).
If an author would like to prevent the autofilling of password fields in user management pages where a user can specify a new password for someone other than themself, autocomplete="new-password" should be specified, though support for this has not been implemented in all browsers yet.
I think it is not possible in the latest browsers.
The only way you can do that is to take another hidden password field and use it for your logic after taking value from visible password field while submitting and put dummy string in visible password field.
In this case the browser can store a dummy string instead of the actual password.
While the previous solutions are very correct, if you absolutely need the feature then you can mimic the situation with custom input using text-field and JavaScript.
For secure usage, you can use any cryptography technique. So this way you will bypass the browser's password saving behavior.
If you want to know more about the idea, we can discuss that on chat. But the gist is discussed in previous answers and you can get the idea.
One way would be to generate random input names and work with them.
This way, browsers will be presented with the new form each time and won't be able to pre-populate the input fields.
If you provide us with some sample code (do you have a JavaScript single-page application (SPA) app or some server side rendering) I would be happy to help you in the implementation.
One thing you can do is ask your users to disable saving the password for your site. This can be done browser wide or origin wide.
Something else you can do is to force the inputs to be empty after the page is loaded (and after the browser auto completed the fields). Put this script at the end of the <body> element.
I resolved the issue by just adding readonly & onfocus="this.removeAttribute('readonly');" attributes besides autocomplete="off" to the inputs as shown below.
I needed this a couple of years ago for a specific situation: Two people who know their network passwords access the same machine at the same time to sign a legal agreement.
You don't want either password saved in that situation because saving a password is a legal issue, not a technical one where both the physical and temporal presence of both individuals is mandatory. Now, I'll agree that this is a rare situation to encounter, but such situations do exist and built-in password managers in web browsers are unhelpful.
My technical solution to the above was to swap between password and text types and make the background color match the text color when the field is a plain text field (thereby continuing to hide the password). Browsers don't ask to save passwords that are stored in plain text fields.
Note: Works in Firefox but CSSmoz-text-security is
Deprecated/Removed. To fix this create a CSSfont-face made only of
dots and use font-family: 'dotsfont';.
As far as I have tested this solution works for Chrome, Firefox version 59.0 (64-bit), Internet Explorer version 11.0.9600 as well as the IE Emulators Internet Explorer 5 and greater.
By default, there is not any proper answer to disable saving a password in your browser. But luckily there is a way around and it works in almost all the browsers.
To achieve this, add a dummy input just before the actual input with autocomplete="off" and some custom styling to hide it and providing tabIndex.
Some browsers' (Chrome) autocomplete will fill in the first password input it finds, and the input before that, so with this trick it will only fill in an invisible input that doesn't matter.
In such a situation, I populate the password field with some random characters just after the original password is retrieved by the internal JavaScript code, but just before the form submission.
NOTE: The actual password is surely used for the next step by the form. The value is transferred to a hidden field first. See the code example.
That way, when the browser's password manager saves the password, it is not really the password the user had given there. So the user thinks the password has been saved, when in fact some random stuff is what got saved. Over time, the user would know that he/she can't trust the password manager to do the right job for that site.
Now this can lead to a bad user experience; I know because the user may feel that the browser has indeed saved the password. But with adequate documentation, the user can be consoled. I feel this is the way one can fully be sure that the actual password entered by the user cannot be picked up by the browser and saved.
<form id='frm' action="https://google.com">
Password: <input type="password" id="pwd" />
<input type='hidden' id='hiddenpwd' />
<button onclick='subm()'>Submit this</button>
</form>
<script>
function subm() {
var actualpwd = $('#pwd').val();
$('#hiddenpwd').val(actualpwd);
// ...Do whatever Ajax, etc. with this actual pwd
// ...Or assign the value to another hidden field
$('#pwd').val('globbedygook');
$('#frm').submit();
}
</script>
I would create a session variable and randomize it. Then build the id and name values based on the session variable. Then on login interrogate the session var you created.
At the time this was posted, neither of the previous answers worked for me.
This approach uses a visible password field to capture the password from the user and a hidden password field to pass the password to the server. The visible password field is blanked before the form is submitted, but not with a form submit event handler (see explanation on the next paragraph). This approach transfers the visible password field value to the hidden password field as soon as possible (without unnecessary overhead) and then wipes out the visible password field. If the user tabs back into the visible password field, the value is restored. It uses the placeholder to display ●●● after the field was wiped out.
I tried clearing the visible password field on the form onsubmit event, but the browser seems to be inspecting the values before the event handler and prompts the user to save the password. Actually, if the alert at the end of passwordchange is uncommented, the browser still prompts to save the password.
function formsubmit(e) {
document.getElementById('form_password').setAttribute('placeholder', 'password');
}
function userinputfocus(e) {
//Just to make the browser mark the username field as required
// like the password field does.
e.target.value = e.target.value;
}
function passwordfocus(e) {
e.target.setAttribute('placeholder', 'password');
e.target.setAttribute('required', 'required');
e.target.value = document.getElementById('password').value;
}
function passwordkeydown(e) {
if (e.key === 'Enter') {
passwordchange(e.target);
}
}
function passwordblur(e) {
passwordchange(e.target);
if (document.getElementById('password').value !== '') {
var placeholder = '';
for (i = 0; i < document.getElementById('password').value.length; i++) {
placeholder = placeholder + '●';
}
document.getElementById('form_password').setAttribute('placeholder', placeholder);
} else {
document.getElementById('form_password').setAttribute('placeholder', 'password');
}
}
function passwordchange(password) {
if (password.getAttribute('placeholder') === 'password') {
if (password.value === '') {
password.setAttribute('required', 'required');
} else {
password.removeAttribute('required');
var placeholder = '';
for (i = 0; i < password.value.length; i++) {
placeholder = placeholder + '●';
}
}
document.getElementById('password').value = password.value;
password.value = '';
//This alert will make the browser prompt for a password save
//alert(e.type);
}
}
#form_password:not([placeholder='password'])::placeholder {
color: red; /*change to black*/
opacity: 1;
}
window.onload = function () {
init();
}
function init() {
var x = document.getElementsByTagName("input")["Password"];
var style = window.getComputedStyle(x);
console.log(style);
if (style.webkitTextSecurity) {
// Do nothing
} else {
x.setAttribute("type", "password");
}
}
the onInputPassword function is like this:
(assuming that you have the "password" variable defined somewhere)
onInputPassword( event ) {
let key = event.key;
event.preventDefault(); // this is to prevent the key to reach the input field
if( key == "Enter" ) {
// here you put a call to the function that will do something with the password
}
else if( key == "Backspace" ) {
if( password ) {
// remove the last character if any
yourInputElement.value = yourInputElement.value.slice(0, -1);
password = password.slice(0, -1);
}
}
else if( (key >= '0' && key <= '9') || (key >= 'A' && key <= 'Z') || (key >= 'a' && key <= 'z') ) {
// show a fake '*' on input field and store the real password
yourInputElement.value = yourInputElement.value + "*";
password += key;
}
}
so all alphanumeric keys will be added to the password, the 'backspace' key will erase one character, the 'enter' key will terminate, and any other keys will be ignored
don't forget to call removeEventListener('keydown', onInputPassword) somewhere at the end
I'm making a PWA using React. (And using Material-UI and Formik on the component in question, so syntax may seem a bit unusual...)
I wanted to stop Chrome from trying to save login credentials (because devices are shared with many users in my situation).
For the input (MUI TextField in my case), I set the type to "text" rather than "password" in order to get around Chromes detection for the store-credentials-feature. I made input-mode as "numeric" to get the keypad to pop up as the keyboard, because users will input a PIN for their password.
And then, as others here described, I used text-security: disc; and -webkit-text-security: disc;
Again, careful of my code's syntax, as it's using React, MUI, etc. (React uses capital letters and no dashes, etc.)
See the parts with the // comment; the rest is just bonus for context.
<TextField
type="text" // this is a hack so Chrome does not offer saved credentials; should be "password" otherwise
name="pincode"
placeholder="pin"
value={values[PIN_FIELD]}
onChange={handleChange}
onBlur={handleBlur}
InputProps=\{\{
endAdornment: (
<InputAdornment position="end">
<RemoveRedEye
color="action"
onClick={togglePasswordMask}
/>
</InputAdornment>
),
inputProps: {
inputMode: 'numeric', // for number keyboard
style: {
textSecurity: `${passwordIsMasked ? 'disc' : ''} `, // part of hack described above. this disc mimics the password *** appearance
WebkitTextSecurity: `${passwordIsMasked ? 'disc' : ''} `, // same hack
},
},
}}
/>
As you can see, I have a toggle that lets you hide or show the pin (by clicking the eye icon). A similar function could be added as appropriate / desired.