Preventing Amazon from "stealing" password

Autofill Vulnerabilities and the Case of the Lost Pepper

TL;DR: This is a PSA to illustrate some of the dangers inherent in the autofill feature (even when manually autofilling using Ctrl-Shift-L or clicking a vault item, but especially when enabling autofill on page load). I present an example in which even a benign exploitation of the autofill vulnerability can lead to some annoyances, and conclude with a call to action: block autofill of hidden form fields!

Background: Autofill on page load and manual autofill are both risky actions

Automatic autofill of login credentials on page load is risky, because of a well-documented vulnerability [Acar et al., 2017][Toth, 2021] that allows your username, password, and other autofilled data to be stolen from hidden form fields (see demo). This is a significant security concern, because such hidden login fields can sometimes be accessed by third parties (unrelated to the website you are logging in to).

Manual autofill on demand is considered less risky, because you would only use it if you can actually see non-hidden login fields. However, the original reports acknowledge that approximately 75% of login pages do contain third-party scripts (which theoretically could inject hidden login fields on the same page as the real, visible login fields).

Amazon’s sign-in page exploits the autofill vulnerability

So what does the above have to do with Amazon, and my allegation that they “steal” passwords? In this case, because Amazon is not a malicious third party, but a second party to whom you intend to provide your password anyway, there is nothing too nefarious going on (but nonetheless, it is a sobering demonstration of the possibility of getting your password stolen by a manual autofill action).

Try it yourself: Go to amazon.com and click the Sign-In button. Notice that you are prompted for your email (or phone number), but not your account password. Now use manual (or automatic) autofill to complete the sign-in form, and click Continue. Magically, you are now signed in to your account without being asked to provide your password! This was possible because the sign-in form also contains a password field that is hidden from view (but which is nevertheless dutifully autofilled by Bitwarden). Some of you may consider this to be convenient (“great, I can skip the second page of the login form!”), but if you’re anything like me, you’ll be a bit unnerved.

Unintended effects: You cannot pepper a “stolen” password

Other than providing a demonstration of the risks inherent in both manual and automatic autofill functionality, does Amazon’s practice of using a hidden password field matter in practice? Yes, because it robs you of the opportunity to add a password pepper (a technique also recommended in a recent Bitwarden blog). After you submit your login email, your stored password is automatically submitted; if your actual password includes a pepper, you will get a login error (“There was a problem: Your password is incorrect”). Not insurmountable, but not something you want to deal with every time you log in.

Two work-arounds

Maybe the simplest workaround would be to just ignore the error message about the incorrect password, since you are provided with a second chance to submit the correct password (this time, using a visible password field, which you can autofill and pepper).

Another option is to create two separate vault items, one item to autofill the username (in which you omit the password), and one item to autofill the password (in which you omit the username). To make this work, you can set the URL for the username-filling item to https://www.amazon.com/ap/signin?openid.pape.max_auth_age= (matching to Starts with), and set the URL for the password-filling item to https://www.amazon.com/ap/signin (matching to Exact). In addition, I found it necessary for the username-filling item to include a custom field named ap_email, which I linked to the username value. This configuration prevents the hidden password field from being autofilled on the first page of the sign-in screen, which prompts Amazon to display the second page (where you can autofill and pepper your password).

A call to action

I shall refrain from co-opting the slogan “Stop the Steal”. Nonetheless, it would be great if Bitwarden could refrain from autofilling fields that are not visible, which would plug this security hole once and for all. However, I have no idea if this would be technically feasible to implement (i.e., is Bitwarden able to determine whether a form field is visible to the user or hidden?). Please comment if you think it can be done, in which case it would make a great feature request!

1 Like

Why not just turn off autofill by default and then enable it individually for logins you trust? Bitwarden won’t autofill anything this way unless you provide a matching URI and explicitly grant permission to autofill.

I do have autofill on page load disabled. The point (well, one point) of my post is that you are still vulnerable to this attack vector if you exclusively use manual autofill (e.g., using Ctrl-Shift-L). The only alternative is to copy-paste via the clipboard, but this exposes a whole other attack surface…

1 Like

I have now updated my top post to make it more clear, and to add the promised information about work-arounds. I hope some discussion will ensue.

Another good and relevant XSS, and clickjacking testing site
https://websecurity.dev/password-managers/autofill/

I like your first workaround. Works for me. i imagine it should work for any site, although some sites justifiably ratchet up the login verification requirements as you accumulate unsuccessful login attempts.

I wouldn’t go as far as your title but i was amused by it (which i guess was the intended outcome).

Yes, I fully admit to making a click-bait title for this post. It is part of my ongoing campaign to convince Bitwarden to prevent auto-filling of non-visible form fields, which is a real security issue. Thanks for reading!

1 Like