Account-specific one-time pw issue with AWS

tholahan

Hi. I have several AWS accounts with MFA (aka 2FA) enabled.

Virtual MFA works exactly as expected for all of them but one (the one I use most, naturally).

For that account, I have to do the following to successfully authenticate:

1. Attempt to authenticate with the MFA code. It fails.
2. Attempt again after the code has changed. It succeeds.

If I don't perform step 1 (i.e. try and fail to log in at first), but simply wait until the code has changed and enter the new one, that fails. I can only authenticate by failing and then succeeding.

I've tried many times to re-synchronize the "virtual MFA device" (their term) with AWS, and I've tried deleting and recreating the virtual MFA device, all to no effect. The behavior remains remarkably consistent.

I created a case with AWS support. No surprise, they blamed it on the virtual MFA device (ie 1Password).

Any suggestions?

---

1Password Version: 6.8.4 (684001)
Extension Version: 4.6.12.90
OS Version: 10.13.2
Sync Type: 1Password.com for Teams?

rudy

@tholahan,

That's certainly a weird result. The can you try doing a manual sign-in and fill in the code that's being displayed in 1Password to see if it takes that? In practice MFA servers typically take the previous and next codes as well as the currently displayed one.

If it doesn't take it, that makes me wonder if your computer/device's clock is out of sync by just enough to be outside of that window of accepted generated codes.

Rudy

tholahan

Thanks, Rudy.

Authenticating manually worked 4 out of 4 times tried just now.

Not sure what to make of that.

tholahan

It seems to me that, if the system clock were the root cause, I'd have this problem across all of the accounts, or less consistently on the one account.

It's never happened for three other MFA accounts with AWS, and it always happens for the problem account (except when entering credentials manually).

rudy

@tholahan,

In the failed attempts you're doing a fill and the TOTP code is being placed on the clipboard (evidence of that is that we posted a notification via Notification Center)?

Rudy

tholahan

Yes, that's how it's been. However, in doing more testing, I have seen it fail with manual entry of the code as well (after using 1PW to automate the u/n and p/w entry on the first page of the AWS login UI).

tholahan

It's starting to look pretty consistent that auto-entry of the u/n & p/w on the first page is the cause of the problem. If I use 1PW for that, the login fails. If I don't, it succeeds.

The reason the second attempt (described in my original post) has been succeeding is that I've been doing the p/w entry manually. When AWS bounces me back to the first page, the u/n is still populated. If I try to use 1PW to auto-fill again, it blanks out the u/n field, though it does fill the p/w.

That's made me fill the p/w field manually (by copying it out of 1PW). That's why the second attempt has succeeded. The first attempt succeeds if I do that.

It seems like 1PW may not be accurately submitting the u/n.

AGAlumB

@tholahan: 1Password will just submit the credentials you have saved in it. Are you certain it's correct? What happens if you copy and paste instead of having 1Password fill? Maybe theres a script on the page that is preventing 1Password from doing so reliably. Another thing I see from time to time is that a site will accept credentials initially on account creation but not allow them when logging in (e.g. special characters, length, etc.) Just keep in mind it's impossible for us to troubleshoot this properly without any details to test it ourselves, but happy to offer some suggestions that might help you narrow down the cause. :)

tholahan

The credentials as saved in 1PW are correct and work when either manually typed or cut and pasted.

It seems likely that the issue is with the first sign-in page (which doesn't include the MFA code), or the hand-off of the u/n and p/w from that page to the next (where the MFA code is entered). It may well be JavaScript/DOM-related.

I understand that it's tough to debug based on second-hand information. I'd be happy to do a screenshare with someone there. I'm familiar with debugging browser issues (the problem happens on Firefox and Safari as well as Chrome).

jxpx777

@tholahan Since you're familiar with the browser debugging tools, could you see if there is a difference between the POST payloads when using 1Password to fill vs filling manually via copy and paste. It could be that there is some subtle website behavior that we aren't tickling properly. Obviously don't post unaltered screenshots or other info that might be sensitive, but I'm sure you can describe the behavior well enough to let us know what might be different.

--
Jamie Phelps
Code Wrangler @ AgileBits
Fort Worth, Texas

tholahan

I did that, Jamie. 1PW is submitting the wrong password. This 1PW login has had three passwords (two show up in the history), and the form submitted contains the oldest (i.e. the original one that was created with the login).

tholahan

The old pw (and the blank username) were in the "Web form details" when I looked at them.

Clearing them out resolved the issue. Sorry I didn't think of that earlier.

tholahan

Seems like the app could show a warning flag on logins with two usernames and/or two passwords embedded in the web form details, since those can override what appears to be authoritative.

Something like "This login has duplicate/conflicting data in its web form details."

jxpx777

I'm glad you figured out what was causing the issue. It's tricky to do proactive things like you suggest because there are legitimate use cases where you would have multiple password and non-password fields for a page. We see this all the time. I agree that the web form details is a bit hidden and we could do a better job of surfacing it. Hopefully we'll be able to take a look at that for the future.

--
Jamie Phelps
Code Wrangler @ AgileBits
Fort Worth, Texas