38

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

gislikonrad
  • 3,401
  • 2
  • 22
  • 24
  • Have you tried putting `autocomplete="off"` in the `
    ` tag?
    – John Conde Mar 17 '14 at 14:44
  • 4
    I think this battle will not end any time soon. Browser developers feel strongly that password managers are more secure. I agree with their argument - I have over 200 passwords memorized in my Chrome password manager, and they're all different, many are random. By blocking autocomplete, your bank will force people to make a password they can remember (or they'll constantly be requesting new passwords). Read more about the debate at https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/wYGThW5WRrE/qiWrKwJ79S4J – Fuhrmanator Sep 19 '15 at 14:42
  • 2
    I found this question for another reason. Browsers do a bad job when it comes to unusual uses of a `type="password"` field. They autofill in places where they should not, which is also a kind of security risk. Moodle LMS has a lot of forms where this is a problem: https://tracker.moodle.org/browse/MDL-51083 Passwords are used in perhaps unusual ways, for example, to add a level of access control to a time extension for an online quiz. Browsers think such password fields are part of a site login, but they're not. – Fuhrmanator Sep 20 '15 at 19:36
  • 1
    Also for user-initiated password change - you want to make sure the users IS the user, by re-entering the old password, and then the new one. Suggestions at this point are.. wrong! – T4NK3R May 06 '17 at 06:01
  • https://github.com/noppa/text-security – But those new buttons though.. Apr 14 '21 at 10:53

8 Answers8

63

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.

Community
  • 1
  • 1
rafaelcastrocouto
  • 11,781
  • 3
  • 38
  • 63
  • 11
    Your post is a fairly good answer on the question, but I am a little frightened what happens if I give you an upvote and others are going to use this in real life... – Patrick Hofman Mar 17 '14 at 15:08
  • Yeah, I agree... It's a "solution" but as Rafael suggests, the answer raises different security concerns... – gislikonrad Mar 18 '14 at 10:29
  • 1
    Note that the DEMO does not work because the font is loaded from a different domain. It would work when the code and the form are loaded from the same domain. – NineBerry Jan 30 '17 at 23:22
  • I almost deleted this answer since it's actually a bad thing to do. I'm gonna leave the code not working intentionally in order to discourage copy and paste. – rafaelcastrocouto Jan 31 '17 at 00:51
  • 6
    You should mention what your security concerns are – Savage May 18 '17 at 07:36
  • This actually resolves the issue regarding chrome's autofill crap, as the field can be a text field (vs password). Which security issues does this raise? – Mike Purcell Aug 30 '17 at 15:57
  • 4
    The content can be copied/transferred somewhere else since it's plain text – rafaelcastrocouto Aug 31 '17 at 21:31
  • @rafaelcastrocouto: Confirmed. This solution should actually be deleted. – Mike Purcell Sep 07 '17 at 15:34
  • 31
    @rafaelcastrocouto - I don't agree that this should be deleted. It is the only answer out there that I have seen that reliably allows the entering of hidden text without the password manager getting involved. While in certain use cases it may be considered insecure, there are plenty of other cases where it is very useful for a user to be able to enter text that is neither visible to someone standing behind them nor a security camera - without the darned password manager popping up. This is not in fact limited to passwords. I am finding this wet nurse approach by browsers VERY annoying. – Pancho Sep 15 '17 at 15:05
  • 2
    This has legitimate and safe uses. e.g. password protected backend, where manager enters access credentials for new employee. In such case registration for user is rarely warranted. Usually such password needs no visual obfuscation, but sometimes it may be requested. PROBLEM arises, when you have placeholder in that input field ;) – Jeffz Apr 15 '18 at 12:01
  • 1
    @rafaelcastrocouto regarding the font provided in the demo. Did you purchase, download or create that font? I'd like to use it, however the license on the font states a monotype license agreement. If you created it yourself by editing an existing font then I'm not sure if the license stands. If you created it can you change the license to something that can be used. If purchased from monotype I'll consider picking this up with them. This also stands as a note to anyone else who considers using the demoed font without appropriate licensing. – Adam Willden Apr 03 '19 at 14:40
  • I've found it online in a fast google search 5 years ago. I don't remember where I got it from but you can create one for yourself quite easily and even choose the shape of your single char. Please keep in mind all the security issues raised here. – rafaelcastrocouto Apr 03 '19 at 17:08
  • a shame that spaces don't show the circles but actual empty space... is there a workaround for this? – usernotnull Oct 17 '20 at 09:17
  • you can make your own font @RJFares, it ain't hard. – rafaelcastrocouto Oct 18 '20 at 11:23
  • @Pancho Yes. I found this post because I wanted to get rid of the password manager, as well as the warnings given by the browser when you $_POST[] it to another page, which actually processes the pw. This is very annoying when you want to develop a semi-formal account system. But there is one flaw - the space character doesn't get replaced. – Azure Apr 16 '21 at 13:02
  • Beautiful. very beautiful – Intaek Aug 11 '23 at 08:19
  • This is perfect in "KIOSK" scenario, where you have one browser app on some public box people line up. So the guy in front of you sets up some password, your turn, and you shouldn't see the previous person's stored passoword. This is the case that google diehards completely pretends does not exist. The "password manager is safe" argument assumes the screen is on someone's device, and whoever sits in front of it can be tied to the identity. A person's phone, a person's PC. There are applications where the same app keeps running on the same session, and the user rotates like a hospital kiosk. – Jun Sato Aug 30 '23 at 06:02
17

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.

Fuhrmanator
  • 11,459
  • 6
  • 62
  • 111
  • Yeah, we did do this, but ultimately decided to bow to the browser manufacturers will on this one. Upvoting you anyway for a fine answer. – gislikonrad Sep 30 '15 at 15:30
  • Clever, and actually addresses the title question. Thank you! – Geoffrey Hale Jun 15 '16 at 18:37
  • This works well on Firefox and Chrome but will throw an error in IE. – Jason L. Jun 22 '16 at 20:09
  • 1
    Chrome will autoselect the first option in the list when the event is triggered, not a good user experience. – Mike Purcell Aug 30 '17 at 15:58
  • Clever answer at the time it was posted but not currently working – YeinCM-Qva May 16 '18 at 20:06
  • @YeinCM-Qva My Chrome (today) still shows the proper behavior of the JSFiddle I posted. Why do you say it's not working? Which browser? – Fuhrmanator May 17 '18 at 01:08
  • @Fuhrmanator yes it actually works in jsfiddler environment but it doesn't when you implemented in real live example. I could make it work on IE with a couple of tweaks but it's not working for Chrome (always saves the password) neither FF. It's a matter of browser specs I think – YeinCM-Qva May 17 '18 at 16:31
  • For chrome I just did: 1) add id=psw to current input=text and 2) add CSS style: #psw {-webkit-text-security: circle;} hope this help ;) – YeinCM-Qva May 17 '18 at 20:43
3

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.

1

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.

Spudley
  • 166,037
  • 39
  • 233
  • 307
1

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!

SlickRed
  • 143
  • 6
  • Regarding the last point you could set the `color` of the `input` to `rgba(0, 0, 0, 0)` and only change it to `rgba(0, 0, 0, 1)`, once the `type` has changed to `password`. – Rounin Jun 23 '23 at 14:36
0

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

Jesse
  • 799
  • 5
  • 6
0

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);
Jonny Roller
  • 106
  • 4
0

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.

Shahnwaz Alam
  • 23
  • 1
  • 1
  • 6