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

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

  • brentybrenty

    Team Member

    @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. :)

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file