0

I have a Progressive Web App. First page is the login page. From there user is redirected to the other/final page (based on the user type). This last page is a Single Page Application. So, in this SPA there are some sections where user can change sensitive data. To be sure about the identity of user I request the password for confirmation. So far so good.

My problems appears with Chrome who wants to autocomplete the password field used for confirmation of the user. I ask nicely Chrome to stay away from those fields:

<input id="pass" value="" autocomplete="off" type="password">

I try without a form to discourage browser to fill those fields, I try to use <form autocomplete="off"> - no chance. Even more, after SPA is loaded, Chrome is filling password field despite the fact this section is HIDDEN! I do not want to Create Amazing Password Forms, I do not want to Help users checkout faster with Autofill, I want Chrome to let some password fields in peace without being forced to do all kinds of tricks in this regard. I know when to "Create Amazing Password Forms", but this is not the case. I believe this behaviour is dangerous and it is against any notion of security.

My question is: what is the best approach to avoid Chrome's behaviour? I want autocomplete="off" option to be respected. new-password and off are two totally different things.

This question can be quickly marked as duplicate for this or this questions but now is 2020 and I cannot find an elegant solution for my problem. I believe also that Chrome will not fix this bug (sorry, this feature) and will put "user experience" in front of any reasonable security measures.

So, dear Chrome, how can translate to you those little things:

  1. Stop filling in password field when a page is loaded. The field is not even visible to the user and may even be disabled. I told you I do not want you to do this. But you don't care.
  2. Stop filling in a password when I tell you that I use that field to see if that user is the authorized user to make some important changes to the account. Then what's the point of verifying the user's identity? Let's let anyone who finds us logged in on the web page to do what they want with that account!
  3. Did you see that I'm a good boy ?! I let you auto-complete the PASSWORD fields (marked with autocomplete = "new-passord") when the user changes the password. This way you can make suggestions for choosing a more complicated password and even save the new password (which is left free to auto-complete at login). But in THIS form I do NOT want to fill in the current password. It's clear? What do you not understand from autocomplete = "off"?
  4. Stop suggesting saving all sorts of passwords when the user has clicked the back button. By pressing the back button the user gave up what changes he wanted to make. He gave up. He doesn't want to save anything. OK? Can we get along?
Junior
  • 315
  • 2
  • 11
  • There probably is no elegant solution here. The suggestion from one of your links seems reasonable though: `If you generate unique random autocomplete names you disable auto complete`. It's a total hack, but I don't think we'll be convincing chrome to change anytime soon. We just have to deal with these crappy workarounds and get on with things. – CRice May 06 '20 at 20:00

1 Answers1

2

So the autocomplete attribute is no longer supported by some browsers, but you can try clearing the field (rendering the tag inaccessible by chrome) using javascript like this:

<input id="pass" value="" autocomplete="off" type="password" onfocusout ="this.setAttribute('readonly','readonly');" onfocus ="this.removeAttribute('readonly');">
dqve
  • 646
  • 5
  • 17
  • I already set all password fields to `readonly` to resolve the first problem. As any other solutions that have worked before, it is a problem of time till Chrome will find this and "fix" it. I want to be able to use passwords fields to confirm user identity. Can I do this with Chrome? And yes, the fact that Chrome is in a hurry to fill a non visible & disabled password field in a SPA is a big security issue (from my point of view). – Junior May 06 '20 at 20:26
  • 1
    This is my current implementation with all passwords fields set as `readonly` from loading time:`$(document).on("focusout", "input[type=password]", function(){ $(this).prop('readonly', true); }); $(document).on("focusin", "input[type=password]", function(){ $(this).prop('readonly', false); });` – Junior May 06 '20 at 20:42
  • This does work yeah? You're looking for an ”elegant” solution instead? – dqve May 06 '20 at 20:45
  • Thank you for quick response, but there are a lot of implications of Chrome behaviour. Please take a look at original question for all those 4 points. As just one big problem, those can be concatenated as: "I want to be able to use passwords fields to confirm user identity" – Junior May 06 '20 at 20:52