← Back to context

Comment by akersten

1 day ago

> open their password manager which also might need you to authenticate, type in their master password, search for the name of the said website, copy the password, paste it in

This is one way to guarantee you'll eventually fall for a phishing attack. Are we really running URL-unaware password managers in the year 2026?

>Are we really running URL-unaware password managers in the year 2026?

URL-aware browser plugins for autofilling passwords can also make people _more_ susceptible to phishing.

The password managers plugins sometimes not working correctly changes the Bayesian probabilities in the mind such that username/password fields that remain unfilled becomes normal and expected for legitimate websites. If that happens enough, it inadvertently trains sophisticated computer-literate users to lower their guard when encountering true phishing websites in the future. I wrote more on how this happens to really smart technical people: https://news.ycombinator.com/item?id=45179643

Password browser plugins being imperfect can simultaneously increase AND decrease security because of interactions with human psychology.

  • Even if autofill breaks, the moment it does, if you're security aware, is to actually read the URL you're at, not start copy-pasting like it's the wild west.

    > autofilling passwords can also make people _more_ susceptible to phishing

    No, it doesn't. What it does, is generally make people _less_ susceptible to phishing, but the moment you stop paying attention when autofill breaks, is the moment you can STILL get phished. But in 90% of the cases, the autofill will HELP you avoid getting phished.

    What an absolutely bananas thing to say, that autofilling passwords make people more susceptible to phishing, completely wrong and borderline harmful to spread things like this.

    • It can also not "break", autofill your credentials, and in submission the data ends up going to the attacker (see my other comment on DOM-based clickjacking)

      2 replies →

  • I don't think your other comment supports your assertion. I've experienced Bitwarden failing to auto-fill due to quirks on websites, but I've never seen it fail to identify the domain correctly.

    You link to Bitwarden's issues mentioning autofill and while it's true that autofill might break, if you click on the extension icon it's going to present you with a list of credentials for the current domain and give you options to quickly copy the username and password to your clipboard.

    If that list is empty then I'm immediately put on high alert for phishing, but so far it's always been due to the website changing its URL/domain. I retrace my steps, make sure I'm on the right domain, then I have to explicitly search for the old entry and update it with the new URL.

    That said, I've seen people do: Empty account list -> The darn password manager is misbehaving again -> Search and copy the password. I wouldn't consider those people to be sophisticated users since they're misunderstanding and defying the safety mechanisms.

  • Wrong. If my password manager doesn't auto-fill I'm am immediately far more wary. If I didn't have any URL matching in the password manager then I would very quickly stop paying close enough attention to the URL because I'd have to do it too frequently.

It’s also an issue that extensions like 1Password are _too_ URL-aware, until recently it tried to use heuristics and ignore subdomains for matching credentials. This meant that we used to get a list of almost a hundred options when logging into our AWS infrastructure. No matter which actual domain used. Someone could have used this vulnerability as part of a phishing campaign.

  • > extensions like 1Password are _too_ URL-aware, until recently it tried to use heuristics and ignore subdomains for matching credentials

    I've used 1Password for years (Linux+Firefox though, FWIW), and this never happened to me or our family. I did discover though that the autofill basically went by hierarchy in the URI to figure out what to show, so if you specify "example.com" and you're on "login.example.com", you'll see everything matching "*example.com" which actually is to be expected. If you only want to see it on one subdomain, you need to specify it in the record/item.

    That it ignored the subdomains fully sounds like it was a bug on your particular platform, because 1Password never did that for me, but I remember being slightly confused by the behavior initially, until I fixed my items.

    • It wasn't a considered a bug, it was repeatedly reported to them from us via email and from other customers on their community pages.

      Just take a look here for example: https://www.1password.community/discussions/1password/bug-su...

      1Password then wrote:

      > 1Password currently only suggests items based on the root domain. I can see the value of having 1Password suggest only exact matches based on their subdomain, especially for the use case you have described.

      Or take a look here: https://www.1password.community/discussions/1password/sugges...

      1Password then wrote:

      > As it currently stands, 1Password only matches on the second level domain (i.e. sample.com in your example). While I can't promise anything, this is something we've heard frequently, so I'll share your thoughts with the team.

      Now it is:

      > You’ll see the item as a suggestion on any page that’s part of the website, including subdomains. The item may also be suggested on related websites known to belong to the same organization.

      It's that second sentence which is the problem, they "suggested" by being "smart" items from one AWS domain which ought to have never suggested on another unrelated AWS domain.

      In version 8.10 when they added Only fill on this exact host: https://support.1password.com/autofill-behavior/

  • Haha and Bitwarden is url aware but not enough.

    I work in a company where I have two okta accounts (because hey, why not) on two .okta.com subdomains.

    Bitwarden _randomly_ messes up the two subdomains and most of the times (but not always, which seems strange actually), it fills the form with the wrong password. I don’t know why. I know that there is an option to make it stricter on domain matching but you can’t configure it on per item basis, only for the whole vault.

    • Every browser-based bitwarden client I have used have the option to choose the autofill option on single items as well as the global default. Find the login item, click edit, scroll to autofill options, where each URI is listed with a gear icon next to it. Click the gear and select the appropriate match type.

      For the absolute majority of use cases, "host" should be the default, but i have found uses for both "base domain" and "regular expression" in some special cases.

      Normal browser extension Bitwarden Ctrl-Shift-L autofill defaults to the most recently used entry when there are multiple matches, afaik.

    • You can indeed configure it on a per-item basis. The vault-wide setting you found is just the default for ones that don’t have an override set. Click on the domain/url matching setting in the individual credential and you can change it to exact host match.

Yes we should run URL-unaware manager, but nearly no one understand security, especially in browser. Let's see the permission asked for the #1 manager in firefox (Authenticator):

  Input data to the clipboard
  Access your data for sites in the dropboxapi.com domain
  Access your data for www.google.com
  Access your data for www.googleapis.com
  Access your data for accounts.google.com
  Access your data for graph.microsoft.com
  Access your data for login.microsoftonline.com

Yep! And #2 (2FAS Auth):

  Display notifications to you
  Access browser tabs
  Access browser activity during navigation
  Access your data for all websites

Even better, maybe at one point web browser can get their sh* together and build better permission system (and not just disable functions like manifest v3). For now the majority of people trust opaque organization shoving them unknown code their run with way too many permissions on their computers.

Talking about unknown code there is a lot of work to be done on reproducible build as anything touching web has nearly nothing about it.

That's a very smug take, especially when you encounter websites every day that don't autofill for whatever reason (As another poster already showed with some examples) or in my case the 1Password extension in Safari failing to connect to the main 1Password deamon or a number of other issues that make this still common place in 2026.

And that's for me, a technical user using a password manager.

  • I also find the 1Password browser (Safari) extension to pitifully poor. But there's a neat workaround: set up a hotkey for 'Show Quick Access'. I use Ctrl+Opt+\.

    This pops up 1Password's overlay but it is still URL-aware. I find it works almost universally. It'll show you what it's going to fill: just hit Return and it'll be done.

    It doesn't even care what browser you're in. Works across the lot. Of course it isn't fully integrated so Passkeys won't work.

I'm using Apple's Password Manager (native app on iOS & macOS), but didn't install its browser extension that can do autofill because for me it wasn't as convenient (it has a bad UX, unreliable autofill, etc.)

So, when I'm prompted to log in somewhere, I open the password manager and repeat the steps you just mentioned. It does add extra steps to the process, but I don't think it makes it less safe than having an autofill extension, which requires a ton of permissions and is more prone to compromises. And yes, my manual method also means I have to rely on me being aware of the URLs I'm on, but I usually bookmark my main services, so it's working fine for me this way. I also treat all emails as spam and/or an attack unless I verify them by the domain, and whether I had just recently requested to log in or requested a password change, etc.

At the end of the day, it boils down to us paying attention to every action we take, regardless of the measures we take, as new and different methods are being deployed to own us every day.

Lots of people are afraid of attacks on the browser extension.

There have been exploits for them in the past, it's a legitimate concern.

Deciding between the two setups is a tradeoff between one security issue and another.

  • I am now wondering if Safari's integration with the system-wide password manager is similar to having a 1Password browser extension installed in a chromium browser

    • It's probably slightly more secure than the extension.

      Legitimately the only reason to us the built in password managers is this tradeoff.

  • >afraid of attacks on the browser extension

    Which is a legitimate concern since they are a gaping hole in security and isolation. Visiting website should be treated like phone calls from the bank. If you get called/mailed you don't follow the information there but call back / visit the site yourself e.g. from bookmarks or copy url from pw manager.

Autofill can be an attack vector.

Lookup Dom-based clickjacking. It will "autofill" the field but on submission it sends the data to an attacker.

"The new technique detailed by Tóth essentially involves using a malicious script to manipulate UI elements in a web page that browser extensions inject into the DOM -- for example, auto-fill prompts, by making them invisible by setting their opacity to zero.

The research specifically focused on 11 popular password manager browser add-ons, ranging from 1Password to iCloud Passwords, all of which have been found to be susceptible to DOM-based extension clickjacking. Collectively, these extensions have millions of users."

""All password managers filled credentials not only to the 'main' domain, but also to all subdomains," Tóth explained. "An attacker could easily find XSS or other vulnerabilities and steal the user's stored credentials with a single click (10 out of 11), including TOTP (9 out of 11). In some scenarios, passkey authentication could also be exploited (8 out of 11).""

More info: https://marektoth.com/blog/dom-based-extension-clickjacking/

Originally discussed at DEFCON 33