New bug in how IAM user name field is filled on AWS "Sign in as IAM user" login page

mjcsb

It seems there's a bug introduced in the latest update to 1Password. on MacOS, Version 7.7 (70700015), related to how the "IAM user name" field is populated by 1Password when selecting a login entry.

When attempting to login to an AWS Account as an IAM user, you first go to an account-specific login URL (for me, via a bookmark) such as https://.signin.aws.amazon.com/console, which then redirects to the same domain with additional query string variables to indicate the account. This confuses most password-saving mechanisms as a result as it can't differentiate between what account and user might be wanted when multiple accounts and users per account are in use, so I save all my user logins as separate 1Password entries. Because I have many of them, I usually have to type the in the search bar after I open the client to whittle down all entries to the relevant account, then I double-click to select the specific IAM user I want.

Saved within each 1Password login, I have fields for (partial list, relevant to this login screen):

• account: This is the account alias OR account ID (if no alias is defined), used in the "Account ID" field
• username: This is the IAM username, used in the "IAM user name" field
• name: This is the account name, which is not meant to be used in any sign-in fleld, but is data showing the account name
• password: This is the IAM user password, used in the "Password" field

When I first double-click on the login entry, this used to work until this last version update correctly. Now, what happens, is the "name" field in the 1Password entry is used to populate the "IAM user name" field on the signin page. This is a change to prior behavior, and is broken. If I then go back to the 1Password browser client and re-click the Autofill button, on the second fill attempt, the "IAM user name" field is correctly filled from the "username" field.

Summary: Autofill incorrectly fills the "IAM user name" form field using the "name" 1Password login entry field on first attempt, then correctly fills in the form field using the "username" 1Password login entry field on the second attempt. It should consistently use the "username" field on all attempts.

---

1Password Version: 7.7 (70700015)
Extension Version: Not Provided
OS Version: OS X 10.15.7
Sync Type: 1Password
Referrer: forum-search:aws IAM user

ag_michaelc

Hey @mjcsb! You mentioned,

Saved within each 1Password login, I have fields for (partial list, relevant to this login screen):

How exactly are these fields set up? Are these all custom fields, or are some fields in the main details of the item (i.e., username, password)?

mjcsb

Default fields at the top:

• username (this value should be used for the "IAM user name" form field, but it not on the first fill attempt, only the second
• password

ACCOUNT section, containing:

• name (this value should NOT be used for the "IAM user name" form field, but is on the first fill attempt, but not the second)
• account (this value is used for the "Account ID", it used to work, and continues to work
• number (this used to be used by the "Account ID" field, but AWS changed it a year or so ago, so now this is just for reference)

There are more sections, but these are the relevant fields, and where they are located.

PLEASE fix this soon - it is incredibly annoying that every time I login, I have to paste credentials twice. I switch accounts a lot...

kaitlyn

Thanks for sharing, @mjcsb! I'm curious, did you manually add "name" as a custom field? I'm not seeing anything that would indicate saving a name field. In my tests, I was able to fill my username and password as I'd expect in the IAM form on the Amazon console, granted I don't have that additional "name" field you mentioned.

mjcsb

I've attached a picture of the typical entry I create for AWS IAM users. I've been using 1Password for this purpose since 2010!

As mentioned before, I have a set of bookmarks which I use to pick the IAM signin URL for the relevant account and user, then when I open the 1Password browser helper, I often have to type the account number (in the number field, when no alias is defined) or the account alias (in the account field) into the search box, to narrow down the logins to only that account, then I can double-click to fill in the Account ID form field from the account 1Password login field, the IAM user name form field from the 1Password username field (this is what the latest update broke - it's been working for years before this), and the password form field from the 1Password password field. I then hit enter, and am taken to the next page for the MFA code. 1Password automatically copies the 1Password mfa field into the paste buffer, so I just have to his command-V to paste, then enter, and I login. It's fast and easy - until this update broke that process.

Now, as stated before, when I first double-click on the 1Password entry after reducing via the search field, the name field is initially and INCORRECTLY used to populate the IAM user name field, and only after I hit fill on the 1Password client a second time, does it do what it should have done on the first click (and used to do before the update), fill the IAM user name field from the 1Password username field.

Please fix this - it's very annoying.

ag_yaron

Hey @mjcsb ,
It is rather hard to keep up with your text description since all the names and descriptions of fields are repetitive and similar, but I think I got the gist of it.

We constantly work to improve and enhance 1Password's autofilling logic and abilities, and with every update we release these changes can be felt (for the better in most cases), but existing (and old) login items might experience some side effects.

When we create a new login on AWS's console page, it does not contain all the extra details that are in your login item(s), and it seems like some of your custom fields are colliding with the main fields of the login items you have. Can you please, for testing purposes, try this:
1. Get to the AWS console's login page.
2. Manually fill in your credentials and save it as a new login: https://support.1password.com/save-login-manually/
3. Refresh the page and try to autofill using the new login you just saved.

If the new login autofills all three fields correctly, take note of which fields are present in that login item and which aren't, and compare it to one of your existing login items. Remove any excess custom fields from your existing login item and see if it works better then.

Let us know what you find.

mjcsb

Just discovered that the bug is in the Safari Browser plugin, but not in the Chrome Browser plugin. The behavior is correct in Chrome, where the initial selection of the correct 1Password login uses the 1Password "username" field to fill in the "IAM user name" field on the AWS sign-in page. On Safari, it incorrectly uses the 1Password "name" field on the first fill attempt, and only uses the correct "username" field on the second fill attempt.

I don't have time to debug your software this week, @ag_yaron - I've been quite exact in describing the broken behavior I'm seeing, now I've added another clue that this bug only exists on the Safari plugin. It was introduced in the latest release - I've had many of these login records going back 4 to 6 years, and they have always worked perfectly for all that time now - so this is a new bug, seems like you guys need to find it. I don't see how creating a new login would help, given the behavior I'm seeing - it's a bug which only affects one browser client, which means it can't be the data, IMHO. It's the new code.

It's annoying enough - I'm wondering can I revert to the prior version of the Safari plugin somehow? Since this behavior seems to be only there, not in the underlying data, or it seems like it would affect the Chrome Browser plugin as well, as both plugins must be using the same encrypted vault cached on my computer or accessed from my computer on demand, it doesn't seem like reverting the 1Plugin application would fix this - That's working fine, it's the browser plugin on safari only - can I request a specific prior version of that while you guys try to find and fix this?

ag_yaron

Hey @mjcsb ,
Thanks for the additional details and for discovering it is in Safari only.

The problem is that in order to debug it, we need to be able to reproduce it, which we can't, as we tried numerous times according to your description and instructions, but things just work correctly. So our current conclusion is that the old login items you have for AWS contain something that might trigger it, which is why creating a new login item will resolve the issue.

We definitely do not recommend using older/outdated versions of our apps and extensions. Keeping software up to date is how you keep your data safe. If you're adamant about it, I won't stop you from rolling back to 1Password 7.6, which contains the previous version of the Safari extension (they cannot be installed separately), but like I said - we strongly advise against it.

Thanks again for providing the additional details. We'll keep an eye on it and see if any other similar reports come in.

mjcsb

I will try to create a new entry. Because I have a structured format for how I save my AWS Accounts (root) and AWS IAM Users, I have been creating a copy, then modifying the copy, whenever I need a new one for many years now. I'll report back on what I find, but may not get to that until later this week.

But, it's not clear how you can't find this bug - it's in the Safari browser plugin, it's code which was changed in the last release, it's related to the initial double click on the entry in the sidebar list, it works when I later re-double-click the sidebar entry or the AutoFill button. See the subset of the relevant page attached, where the field which is broken as of this release does use "username" as both the id and name.

Found one more new clue while confirming the behavior above. The behavior alternates! The first time I go to a bookmark, and wind up on the signin page, if I double-click the entry in the left sidebar multiple times, odd iterations put the 1Password "name" field into the form "username" field, even iterations correctly put the 1Password "username" field into the form "username" field. It switches back and forth on each iteration. The alternating behavior is the same with the AutoFill button.

One more thing. I've found the auto-fill behavior slightly flaky for a while now. At least once per day, I get a different value than expected in the MFA form, like the prior paste buffer value, instead of the current OTP in 1Password. I've seen multiple times where when I try to open the browser client, instead I see the top-toolbar client open instead, stuff like that.

ag_yaron

Hey @mjcsb ,
Thanks for the additional information here.

I dived a little deeper into this and I think I was able to replicate the issue. I created a login item similar to yours, and tested things with "open and fill" so that 1Password will open the webpage for me, and other tests with normal autofilling while already on the page.

The custom "name" field in your login item definitely throws off our latest version of 1Password's autofilling brain, as it comes out equally scored as the username field, therefor when you autofill multiple times without refreshing, it will autofill the "name" field and the main "username" field simultaneously. Sometimes the former will hold, and sometimes the latter.

Custom fields now have a much stronger weight in the latest version of our autofilling brain because a lot of websites have fields that are not username/password in their forms, and we need to do a better job at autofilling all fields on a form, which is why this change was implemented. What you are experiencing is a side effect, as you have been using (a lot of) custom fields in your login items, and now one of them is going rouge. This is not a bug, but rather a side effect of an enhancement of a feature.

If you create a new login item for AWS, there will be no "name" field or any other custom field for that matter, aside for the Account ID field. Such a login item will work flawlessly. Alternatively, you can try and change the "name" field to something else that doesn't contain the word "name" in it (e.g. rename it to "title" or "nick") and things should also work fine with your current login item.

Please try that and let me know if that was it.

mjcsb

Dude, I can't believe what you're describing to me. The "field" in the form has both an id and a name value of "username". How should this use ANY OTHER FIELD in a 1Password login entry other than "username"?

The fact that I have a field in the 1Password login entry named "name" should not matter AT ALL. How should this matter? How is that not a bug? Incredible you are suggesting this hidden side-effect buried somewhere in the code which can now cause this type of inexplicable behavior is normal or I should have to work around this, instead of you FIXING THE BUG.

Also, in case you didn't notice, this works fine in Chrome, only has this weird flaky behavior in Safari - a "designed feature" works the same way in all use-cases and browsers, and it's clearly documented, and it makes sense. This behavior is none of those things, meaning, it's a bug by any sane definition I have ever heard, and I'm a 30 year advanced software developer.

Please fix this. I should not have to change what I call my fields in a 1Password login form. If the web form has a field with an id/name = username, it should use the 1Password username field. if it has a field with the id/name = name, it should use the 1Password name field, and so on. That's how EVERY SINGLE password manager or form-filling program I've ever used works. Please don't try and justify fancy logic that breaks the normal expectation of most people.

ag_yaron

Thanks for the feedback and additional info here. I agree with some of the points you’ve raised.

I asked some other team members to take a look and see of there’s something I missed.

Can you please let us know with which extension you tested in Chrome or any other browser? What was its version?

ag_jarek

@mjcsb,

Hello! My name is Jarek, and I'm a part of the Extensions team here at 1Password. Yaron brought this thread to my attention and asked me to take a look into the filling issue you're experiencing here. Sorry you've bumped into this!

After some investigation, I've discovered that this is being caused by a hidden field on the AWS login page:

The username field on your item is properly matching and filling into the IAM user name field, as expected. However, the "name" field on your item is matching the username2 field in one of the other modals that is able to appear on the page (it's not visible when the page first loads). The site uses JavaScript to sync the values of the two username fields; so, the "name" item field matches and fills into the hidden username2 field, and then the site copies that value back to the username field, overwriting the correct username value that was previously filled.

Thank you for helping us figure out what's going on here (with AWS being such an important site). I've opened an issue to help improve the way in which our filling takes this and other pages into account. In the meantime I'd recommend changing the title of your item field from "name" to "account name". This means it will no longer match and fill into the username2 field, and the IAM user name field will remain filled with the correct value.

Give that a try and let me know how it goes!

mjcsb

You're the second person there that suggests I change what has worked for something like 6 years, across 3 different employers at this point, without a problem, and which continues to work in Chrome now, without a problem, instead of FIXING THE BUG your latest code release introduced.

As a senior developer, who I assume is interested in supporting the enterprise market, I'm a bit surprised an experienced person does not see a problem with this.

I no longer work at 2 of those employers. I recommended the use of 1Password to store AWS credentials, and worked to setup dozens of credentials for shared accounts, and these conventions have now likely been used to setup what may be a hundred or more such saved credentials across teams of people. You have no idea of the problem you've caused by whatever it is you're doing, which breaks Safari but not Chrome. I have no way to contact these people, and tell them how to fix the problem you created.

The fact this breaks in Safari, but not in Chrome - please explain to me how this is a problem with the AWS website, and not your code? Do you think AWS is serving different page HTML/JavaScrpt to Chrome that prevents this problem? I really doubt it, man.

You introduced a bug. This worked for years without trouble before your latest code update. It continues to work in Chrome. I don't think AWS changed their page source at the exact same time as your update, making it their problem. This is your problem. I really think you need to own this and fix it. I can't go back and change some unknown but large number of saved AWS user entries for some unknown number of employees at companies I no longer work for, because you introduced a bug.

Please think about what you're asking - I have a "name" field. It's not "username" or "username2" - which is the visible field I found and the other field I'm not aware of you claim to have found. So, how does my "name" field get into either of them? Why does it alternate, between working properly and using the wrong field substitution? Why does Chrome consistently work properly, same as before?

I now work for EPAM in the AWS practice - we grew from 30,000 to 40,000 employees last year. if you want me to recommend we use 1Password to store AWS credentials, I better not hear more excuses for not fixing this bug, and instead hear that you understand you can't break long-standing behavior in a non-deterministic way, that affects one browser but not another, and then find excuses not to fix this bug, or even - incredibly to my ears - not even seem to recognize that this is a bug.

nickmcguire

Heya @mjcsb 👋🏼

As a senior developer yourself, and likely one that has some web experience I'm certain that you know how turbulent the web can be at times, especially when you work across multiple environments such as Firefox, Safari, Chrome, and Edge.

Firstly I'd like to thank you for the bug report of 1Password for Mac 7.7. In regards to filling it contained many many fixes and with your report clearly a regression. One of your questions is why this works in Chrome but not Safari, and this is a fantastic question. With the latest updates for 1Password for Mac (7.7 and above) we've started to use our new filling engine and with that a way to ingest page details. One that differs from the current ones used by the 1Password extension (desktop app required) and is more like the 1Password X extension. With this report we've been able to narrow in on the differences being ingested and have opened some issues to look into them.

With that said, I don't believe any of my teammates were attempting to make excuses for why this has occurred, rather just determine what could have been the cause. Jarek specifically was the one who started investigating to identity where the differences occurred between our ingestion scripts and was trying to give a way for you to continue filling in Safari in the meantime while we investigate this issue.

mjcsb

Forgive my annoyance when I've had two people who work for you suggest I go back and change long-lived working configurations because you introduced a bug - like that's easy, or even possible. It's not.

When something has worked for easily 6 years and has been replicated by many other people under the - I think reasonable assumption - that it would continue to work, it's not something which could be changed, even if you think it's easy, and even if I wanted to, as those configuration files extend way beyond my own personal control at this point.

What I find quite astonishing, is that you're using a field saved in 1Password - "name" - to fill in webforms that do not use that identifier as either the "id" or the "name" in html. Again - ONLY IN SAFARI, not in Chrome - you're IGNORING the very specific "username" field saved in 1Password, which I think it's reasonable to assume, would be used to fill in a website form field which has both "id" and "name" set to "username", and instead, using a 1Password form field called "name" instead. But even then, not in Chrome, only Safari, and not consistently in Safari, as it alternates back and forth, using "name" to fill "username" every other time, and currently using "username" to fill in "username" on alternate attempts. This is just insane, man. This is a logic error or a design flaw, it is astonishing that there are people there who are even attempting to defend this logic! It is a bug. It is clearly a bug. It doesn't make ANY sense at all for something to work this way.

If I have a form, with an id/name of "thingamajig", and I have a helper app meant to fill in form data, which itself has a field called "thingamajig" - how in the world could anyone conceive of a design, where these two fields which match explicitly by name are not meant to be connected? It's not like 1Password is MISSING a field called "username" which the AWS webpage form expects!!! It has a field with exactly that name, it's an EXACT match, and Chrome correctly uses the right field, and the Safari plugin prior to this new release, for at least 6 years I'm personally aware of using this convention, correctly used the right field... and now, as of this update, it does not. How is this not broken? How is this not a bug?

Jesus. Why are we having this conversation? Are you going to fix this or not?

nickmcguire

Heya @mjcsb 👋🏼

Another really good question about why we changed to using the fields of your item as a part of the fill process. An item actually contains two sections of fields, the ones that are always visible Section Fields, and another section called Web Form Fields. These Web Form fields do allow for more customization of HTML Name when filling but are completely invisible to the user when viewing/modifying the item. With this in mind, we have tried to improve the ergonomics of filling section fields from your item into the page which has some really nice benefits.

With all that said, yes, totally agree with you on this being a bug and something we'll look into how to resolve it. But in the meantime, following the advice of my teammate Jarek should allow you to continue filling.

mjcsb

I do remember someone mentioning a (IMHO, misguided and broken) design change to try and guess how a form needs to be filled out when the specific field requested may not be there or obvious. I can sympathize with trying to make the experience for users better, by auto-correcting mistakes or trying to guess the best action - when the best action is not already specifically defined.

But, whatever logic has been designed, I think it's faulty, and needs to be re-considered in the light of the problems I'm finding in it's real-world impact.

• The fact behavior varies between Chrome (which works correctly same as before) and Safari (which only breaks on alternate fill attempts, so while that is, in a way, deterministic behavior ("See, it consistently breaks only on the odd fill attempts!"), it is certainly in no way intuitive behavior or expected behavior.
• If there is a field in a web form, which has an id and a name set to "fieldA", and there is a matching "fieldA" in any form-fill helper app, be it from you, or anyone else out there making one, including Safari's own form-fill logic, or Chrome, or Firefox, or LastPass, etc - the expectation of any user is that this exact match would override any "helpful logic" (especially opaque logic which is not described in a published manner as is the case with what you're doing, it seems) and the exact match field will be used to fill in the form field of the same name. And, any "helpful logic" would only come into play, if there was not such an exact match. AT A MINIMUM, a user should be able to turn off this logic if it turns out to break expected behavior. On a per-login basis would be best, but at least on a per-installation client basis.

I know I have ZERO interest in this, ANYWHERE, for ANY SITE. I know how to save form fields and use them to fill forms. I have now lost quite a few hours to this problem. I have now had to explain, in multiple screen-share issues with other employees of my company, where I'm switching AWS Accounts, why I have to fill the login screen twice, that's it's a bug you introduced on the last release and still haven't fixed. If it's important, I use Chrome so they don't see this.

So, my work around is to avoid your buggy Safari helper and use Chrome, which isn't buggy, until you fix this. it's not a satisfactory workaround for me, as I normally prefer to use Safari.

ag_yaron

Thanks for the additional info and feedback @mjcsb .

Hopefully we'll be able to change that behavior with an elegant solution soon. :+1: