Designing pages for password managers

izevaka

Hi,

We recently had an issue on our website where 1Password changed multiple users' passwords after prefilling. The question is really for the prefilling team to give us some tips on how to design pages to work password managers so that we don't have to rely on patched prefill plugins.

Here is what happened.

We have an account admin page that has the following features:

1. Change your own password (old password, new password, confirm new password boxes).
2. Change any user's password by clicking on a button to reveal password box (one password box per user).
3. Enter your password on any action (ie change users' details, passwords etc).

The extension (1Password for Mac 4.4.1) and latest Chrome with (1Password 4.2.3.90) works well for filling in your own password when prompted (fills in only one box). However prefill feature indiscriminately fills in every password on the page, even if they are hidden or disabled.

We are constrained by the fact that the fields have to be generated on the server (ASP.NET server controls). Ideally we would mark the fields that we don't want filled in (which we know based on user interaction). So far we haven't found a way to do that other than changing individual users' password boxes to hidden fields and copy values with JavaScript.

PS Can't really provide access to the web page as it's fairly locked down.

khad

Sincere apologies for the trouble, @izevaka. Can you help me understand what you mean when you use the term "prefill"?

One thing I would suggest is testing with the latest beta version of the 1Password extension. You can download it via Preferences > Browser. Click the "Install Browser Extensions" button. Then make sure to click "Enable Betas" on the extension installation page before clicking the big green "Install" button.

Do you still have the issue using version 4.2.4.3 of the 1Password Beta Chrome extension?

izevaka

Hi @khad,

When I say "prefill" I mean pressing "Fill" in the Password Generator menu. Attached is a screenshot of the UI. Pressing "Change" reveals a password box - If I now generate a password, all of those password boxes will change to the newly generated password. (In our old version, all password boxes get filled, even before pressing Change).

I guess what I am looking for is a set of general guidelines from password manager developers that will let us, web page developers, design pages that behave nicely. Ideally those changes will also improve experience for other password managers like LastPass, oneSafe, etc.

RichardPayne

@izevaka‌ From my limited, and obviously non-official, experience the best thing you can do is only have one password field on a page. Although I realise that this doesn't bode well for your current design.

@khad‌ That leads me to an idea. If there are multiple forms with password fields can 1P display a sub-menu to allow you to choose which one to fill. Display the form ID property and when the user hovers over the menu item, highlight form using a temporary CSS change, sort of like the various browser developer tools do.

khad

@izevaka‌ From my limited, and obviously non-official, experience the best thing you can do is only have one password field on a page. Although I realise that this doesn't bode well for your current design.

Indeed. @RichardPayne, you are correct that only having one password change per page is the best way to go at this time. I suspect this is the case not just for 1Password.

@izevaka‌, my suggestion above was a bit off base because I didn't understand what "prefill" meant. We made a fix in the extension to prevent filling Login items into all the fields on a page — a shotgun approach. When filling using the Password Generator it still does the shotgun approach. There are some sites where this makes sense, but there is room for improvement here.

Short of implementing a whole new UI for selecting which field(s) to fill as @RichardPayne suggested, we could:

• only fill the field which has the cursor focus, however this won't work well on pages which have a "confirm password" field as well.
• stop filling after two fields, which would help in this case but not completely resolve the issue.

We have some other ideas too and hope to go over the Fill Generated Password code in the future.

I hope that helps for now. Please let me know.

EDIT: Updated to clarify that shotgun approach is not used in the stable extension for Login filling.

izevaka

Thanks for suggestions guys. Thinking about this some more, I realised that the problem we experienced is most likely fixed by not filling all password boxes when using extension to enter your password. I can't reproduce this behaviour now, however we did verify that our customer could log in with his password as any of the affected users. Now, it's possible that their password got changed as well and they didn't know as they used 1Password to extract the password in the first place (meaning the person didn't even know they changed their own password).

One suggestion I can make is not filling password boxes that are clearly disabled for user input (ie disabled, detecting 'visibility:none' would be nice).

My gut feel is that doing that follows of a principle of least surprise more so than filling even disabled fields, and it's very semantic :)

RichardPayne

I agree @izevaka‌, although you have to know there'll be an edge case where someone is using a hidden password field to store a value derived from the entered password and that needs to be submitted. ;)

khad

One suggestion I can make is not filling password boxes that are clearly disabled for user input (ie disabled, detecting 'visibility:none' would be nice).

We ignore type="hidden" for both Password Generator and Login filling. Neither one ignores the attributes readonly or disabled. However, the browser will not submit a disabled field, even if it has a value.

For fields with styles visibility: hidden or display: none, we try to ignore them at first, but if we don't fill what we were trying to fill we stop ignoring those fields and try again.

As @RichardPayne alludes to, all of this is really hard to get right in all cases perfectly. But we keep trying. :)

Also, I edited my post above to clarify that the "shotgun" approach for Login filling was actually fixed in the stable extension a while ago. I lost track of my timeline.

izevaka

Awesome, will give type="hidden a go. I understand what's going on with disabled fields now - TBH I didn't know browser didn't submit them. I think I got the info I need for the time being, thanks guys.

izevaka

Correction - will give readonly a go.

khad

Please keep me posted. Cheers!