Auto-fill issue using sign in form at secure.login.gov

beausmith
beausmith
Community Member
edited November 2018 in 1Password in the Browser

I'm having trouble using the 1Password browser extension to auto-fill the sign in form on http://secure.login.gov

I'd like to determine if the issue is caused by me, the website, or 1Password.

Setup

  1. Go to http://secure.login.gov
  2. Create an account with one time password
  3. Save as login in 1Password
  4. Then sign out.

Happy Path Works

  1. Go to http://secure.login.gov
  2. Hit auto-fill keyboard shortcut (⌘ \). Email and password fields will be auto filled correctly.
  3. Click "Next"
  4. Enter your one time password
  5. Click "Submit"
  6. You are successfully signed in.
  7. Click "Sign out". You will be back at the Sign In form.

Issue Repro Steps

  1. Go to Sign In form at http://secure.login.gov (sign out if signed in)
  2. Check the "Show password" checkbox. Password input will no longer be masked.
  3. Hit auto-fill keyboard shortcut (⌘ \). Email will be auto filled correctly, password field will revert to masked password field and "Show password" checkbox is now unchecked.
  4. Check the "Show password" checkbox again.

Result

The Password input now contains the email value.

Expected

The Password field contains the password value.

Questions

  • Can this be fixed by updating the login record in 1Password? If so, how?
  • Can this be fixed by updating the html of the form? If so, how?
  • Can this be fixed via 1Password software update?
  • Should this be fixed by me, Login.gov, or by Agile Bits?

1Password Version: 7.1.2 (70102000)
Extension Version: 4.7.3.90
OS Version: OS X 10.13.6 (17G65)
Sync Type: Not Provided
Referrer: forum-search:"login.gov"

Comments

  • AGAlumB
    AGAlumB
    1Password Alumni

    @beausmith: This is actually pretty simple, but I thank you for the clear explanation as I might have been looking for the wrong thing for a long time. :)

    Suffice to say that what's happening here is that 1Password can easily fill the username and password fields because those are pretty standard...but when you click "show password", the password field becomes not a password field -- just a regular text field -- and 1Password, I'd argue correctly, refuses to fill a password there, since it's not a password field.

    I can't say that either you, 1Password, or the website are really doing anything wrong. I can appreciate your desire for stuff to just work, our own to avoid filling passwords into non-password fields, and also the website's interest in having a way for the user to see what they're typing. But I do think it's not necessarily the best practice to eschew the benefits of Secure Input by not using a standard password field. On the other hand, it isn't that way by default, and the user has to explicitly enable that option, so I sort of have to let the website off the hook here too.

    At the end of the day, to actually answer your questions, this certainly can be "fixed" a number of ways, from different angles. But I'm not sure that it should. My advice would be to not click that checkbox, both to maintain a small amount of added security, and also so that 1Password is able to work the way you want it to here. That seems reasonable to me, but let me know what you think. :)

  • beausmith
    beausmith
    Community Member

    Thanks @brenty. Your explanation makes sense.

    As a curious web developer (not related to login.gov), I still have the following questions:

    1. Why does 1Password fill out the "text" password field with the email address if there is an email address input above?
    2. What is the ideal way to make an html form to work with 1Password where the form has a feature to show the password such that the password can be filled in when the password is shown?

    Thank you.

  • AGAlumB
    AGAlumB
    1Password Alumni
    edited November 2018

    @beausmith: Great questions! I'd be curious about that too. :)

    Why does 1Password fill out the "text" password field with the email address if there is an email address input above?

    Because you told it to. ;)

    That's a bit glib, so I'll add that this is something we've gone back and forth about. On the one hand, there's certainly an argument to be made that 1Password should not fill in silly places. In fact, doing otherwise sounds absurd...until we take a step back and look at the bigger picture. Obviously we don't want 1Password to fill in the wrong place. A common example is search fields. We go to a lot of trouble to have it not fill in those, as that's usually not only not what the user wants, but also just a bad idea. So if you find a web page with a search field and login form, and 1Password is filling the wrong thing, we definitely want to hear about it.

    However, 1Password should probably not do nothing when the user explicitly tells it to. So you hit ⌘ \, but there's no login form on the page? 1Password should try its best to comply. After all, many, many websites have "interesting" non-login-form login forms. An extreme example is when they make a "login form" using tables. Not common, and you'd be forgiven for, as a web developer, taking a wretch into a bucket as you read this; but yes, that is a thing.

    So, suffice to say, while we absolutely appreciate the absurdity that can occur at times when 1Password is told to fill and, since there is no perfectly suitable place to do so, it kind of muddles through anyway, we do think that is better than it seemingly ignoring user intent. It's something we'll continue to evaluate though. Always makes for a fun discussion! :lol:

    What is the ideal way to make an html form to work with 1Password where the form has a feature to show the password such that the password can be filled in when the password is shown?

    We've got some good general "best practices" on our support site:

    Design your website to work best with 1Password

    But in this particular case, I think it boils down to something even more basic, which you're probably way ahead of me on: it's best to use standard HTML web forms. As I'm sure you know, this is pretty easy. But of course people like to get "clever" and reinvent the wheel sometimes when designing their own site, and this can break things not only for 1Password but also for accessibility, or create compatibility issues between browsers/versions.

    But now I realize that I'm rambling on and haven't quite answered the question. It occurs to me that I don't want to, because that exposes the password unnecessarily. I guess you could have Javascript pipe the characters to a separate field as they're entered...but again it's not something we could recommend. There just isn't a safe way to do what you're asking -- and what this website is doing. Too many real problems.

    I know this is going to seem like I'm not only dodging the question but at the same time promoting a product...but really it seems like the only safe solution is to use a password manager like 1Password. That sidesteps the problem of having to remember and type the password correctly in the first place (hence, no need to display it in plaintext), and also stores it and other passwords securely so they can be long, strong, and unique. But I'm sure you already know that. :) I just don't see that doing an end-run around things like Secure Input fields and password masking in general has an upside that outweighs the negatives.

  • beausmith
    beausmith
    Community Member

    @brenty Thanks much. All makes sense. AgileBits is lucky to have such amazingly helpful people like you!

  • AGAlumB
    AGAlumB
    1Password Alumni

    Wow. Thank you! And hey, it's a pleasure talking to you and others who are as passionate about this stuff as we are. Cheers! :chuffed:

This discussion has been closed.