Question

So I have a problem with newer browsers saving passwords. Say I have a password box like so:

<input type="password" autocomplete="off" />

New browsers like IE11 and Safari in iOS 7.1 have started ignoring the autocomplete="off" in password boxes specifically and offer the user to save the password. In my company (a bank), we view this as a security concern.

I was wondering if anybody has solved this problem yet. Maybe somebody has written a javascript plugin that masks a normal input[type=text] so that the autocomplete="off" attribute will be respected.

Update:

For a little more information, here is the documentation for autocomplete on msdn: http://msdn.microsoft.com/en-us/library/ie/ms533486%28v=vs.85%29.aspx

Was it helpful?

Solution 4

Firstly, autocomplete = "off" should be on the <form> element, not the individual fields. This is because browsers typically store the values for all fields in a given form together (eg to allow for saving multiple username/password combinations for the same site).

Set it in the form, and it should work just fine for you. (although passwords already saved will typically still be auto-completed, so clear your password store before testing)

However, I would suggest that you're probably chasing the wrong target if this is considered a security concern.

The reason browsers offer this feature is because users want to be able to store their login credentials. Preventing them from doing so won't stop them wanting to, and if users really want to, there are still a number of ways they can get around it -- there are browser plug-ins explicitly designed to kill thew autocomplete = "off" feature and allow all passwords to be saved.

How your user stores the password at their end is ultimately not your security concern, and not something you really have any control over anyway.

In fact, if we prevent people from storing their passwords, it is more likely that they will use the same password in multiple places (simply because people don't have the capacity to remember different passwords for every site they use), so by preventing them from saving it, you might actually be making your users' passwords less secure.

If your site has a genuine need for security that cannot allow a password to be saved, then you will need to consider an alternative mechanism entirely. For example, bank logins these days often require users to enter specific numbered characters from their password -- eg "Please enter the fifth, eighth and twelfth characters from your password".

However, these schemes are more aimed at securing the transmission of the password rather than the storing of it: by only entering certain given characters, we don't have to input or transmit the entire password at all, so there is no chance of it being hacked en-route. It is still assumed that the user will probably have the password noted down somewhere (especially if they have to work out which is the twelfth character in the string)

This kind of scheme can be a real pain for users, but does offer a genuine level of login security without having to actually input or transmit the password. The additional level of difficulty it adds to the login process, however, means that only really high-security sites like banks are likely to use this kind of scheme over a regular password.

OTHER TIPS

You can make a fake password input with type text using a custom font:

@font-face {
  font-family: 'password';
  font-style: normal;
  font-weight: 400;
  src: url(https://jsbin-user-assets.s3.amazonaws.com/rafaelcastrocouto/password.ttf);
}

input.key {
  font-family: 'password';
  width: 100px; height: 16px;  
}
<p>Password: <input class="key" type="text" autocomplete="off" /></p>

JSBin Demo

Notice that this only raises more security concerns.

Here's an idea, but I'm suggesting it for cases where browsers get the autofill wrong for passwords that aren't used for logins. There probably needs to be a better standard for identifying login screens so browsers don't have to use heuristics looking for fields with type="password".

Load the form with the password field with type="text", so browsers' autocompletion algorithms will ignore it. When the user inputs something in that field, switch its type="password".

I'm not much of a JavaScript programmer, but I hacked a JSFiddle to show how it theoretically works.

Perhaps onfocus would be a better way to go, too, but I didn't try it.

The solution that worked for me was like this :

First input type should be text

At the focus event turn input type to password

Listen for user inputs and if input field value is empty set type to text again

This way at the start and when input field is empty browser will not show suggestions.

I struggled with this for quite some time, but here is a solution that solved the issue for me.

Initially, create the password input as a 'text' input:

<input type="text" name="mfa_psw" id="mfa_psw" autocomplete="off">

Then use Javascript to listen for keystroke events. If the password input is not null, convert the type to 'password'.

<script type="text/javascript">
var pswInput = document.getElementById("mfa_psw");

pswInput.onkeyup = function(e){
    if(e.keyCode == 13){
        mfa(); // enter key pressed, call next function (i.e. log in)
        return false;
    } else {
        if (pswInput.value==null) {
            pswInput.type = 'text'; 
            // input is empty, covert to 'text' to prevent password autofil
        } else {
            pswInput.type = 'password'; 
            // input is not empty, convert to 'password' to hide text entry
        }
    }
}

Note: this solution does mean that the first character of the user's password is exposed for a moment before the input type is changed to 'password'. However, assuming the user's password is longer than 1 character, this really shouldn't be an issue!

Have you tried changing the name attribute to something ridiculous? I believe the autocomplete functionality is based off the name attribute. I'm not 100% sure but in the limited testing I did changing the name attribute was changing what type of autocomplete data was being presented.

Obvious example just to be clear: name="username" was showing my username while name="email" was showing my previously entered email addresses. When I switched to name="browsersAreStupidForImplementingThisFeature" I didn't get any autocomplete data.

Needs further testing but might be a good place to start? Good luck

We had a use case where admins could view other user records and make changes. One of the fields was that other user's password. In this instance, letting the password manager pre-fill the field was a "bad thing". So what we ended up doing was waiting a short period of time after the page had loaded and then cleared out the password field...

// After the page has loaded...
window.addEventListener('load', setTimeout(function() {
  // Wait a bit and then clear out the contents of the field
  document.getElementById('other-password').value='';
}), 100);

Use Javascript to listen for keystroke events. If the password input is not null, convert the type to 'password'.

  <input type="text" name="keybrd" id="keybrd" autocomplete="off">



<script type="text/javascript">
var keybrd = document.getElementById('keybrd');
        keybrd.onkeyup = function(){
                if (keybrd.value==null) {
                    keybrd.type = 'text'; 
                    
                } else {
                    keybrd.type = 'password'; 
                       }
            }

Note: It's easiest way to mask the password input for all browser type.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top