Hacker News Reader

His conclusion seems off to me too. I got "Password managers that use content scripts are bad" not "password managers are bad".

Edit: I just cracked open the 1password extension, and it does indeed use a content script. Glancing over the code I only see stuff related to locating which fields are the username and password field - but I was mistaken in thinking that they didn't use a content script.

Yeah, the analysis here lends itself to a pretty simple heuristic: if the input for the password manager ends up on the page itself, the password manager is poorly designed. If the input ends up in a popup from the icon in your tool bar (which you can tell because it will draw a little arrow thingy that crosses past the edge of the web page), it is likely to be well-designed (in this respect).

All the icon on the webpage ought to do is indicate to the password manager that you'd like to use it, nothing else. You shouldn't be typing your master password there, you shouldn't see a list of sites there (perhaps you just see an option for the current web page, that's fine), etc.

1Password follows this rule and has a pretty good track record overall and I too use it. There are certainly password managers that don't follow this rule; don't use them.

What if browsers exposed the capabilities to locate the inputs, act upon user input, supply generated passwords, etc. in a sandboxed manner?

That’s how iOS Safari’s Password AutoFill works for both iCloud Keychain and third party password managers. Password managers can also supply a prebuilt list so that Safari handles everything, although custom widget handling user input is also allowed.

https://developer.apple.com/documentation/security/password_...

Edit: Of course it’s not limited to Safari, it works for in-app authentication flows too provided apps integrate it.

Or, even better, no passwords and just sensible pki

A browser-integrated password management API could make for a smoother transition to a future automated auth technology based on public keys, like WebAuthn

It's not just content scripts, I've seen vulnerabilities from information leaking(not necessarily creds) to authentication bugs.

Connecting the application that manages your secrets to the most exposed application on your PC is a bad idea.

You're wrong. you can exploit browser extensions without escaping sandbox.

In fact, LastPass and others had some pretty embarrassing vulnerabilities that can be exploited due to being an extension.

There's no question that a local PM has a significantly lower attack surface.

Here are some stories:

https://blog.lastpass.com/2019/09/lastpass-bug-reported-reso...

https://www.csis.dk/newsroom-blog-overview/2021/moserpass-su...

There were several classic web vulnerabilities for 1password and bitwarden when it comes to extensions.

> https://blog.lastpass.com/2019/09/lastpass-bug-reported-reso...

That’s a clickjacking vulnerability. Gp post discussed why UI should be out-of-DOM.

> https://www.csis.dk/newsroom-blog-overview/2021/moserpass-su...

I’m not familiar with the password manager here, but that's a CDN compromise causing auto-update to download a malicious dll. Of course voluntarily installing malicious code is a game-over scenario unrelated to the discussion, and I’m not even sure there’s a browser extension involved here. What’s the point you’re trying to make?

The point is(just gave a couple of examples for issues in the past related to web based PM's) that extensions have tremendous attack surface and lots of complicated little things you have get perfectly right.

kbuck made it seem like there's just a single issue here that can be avoided. that's not true.

Program binary delivery CDN compromise is completely orthogonal to whether the password manager is "web based". Upon some cursory research, the compromised Passwordstate thing is an on-prem enterprise solution, the upgrade package compromised looks like an asp.net application meant to be placed on a server. I guess you can call it compromise of a web-based password manager... But you can compromise native programs the exact same way if you get ahold of the update CDN. Using it as an example is weird.

I see, definitely valid criticism. Cannot edit my comment now.

My point wasn't the specific incident that was linked but more about the fact that updates are a threat for extensions as they update automatically without user input

Just to prove my point that extensions have a wide attack surface.

authentication bugs:

https://blog.lastpass.com/2017/04/lastpass-2fa-bug-reported- resolved/

Information leaking bugs:

https://hackerone.com/reports/337189

server side bugs, rogue updates(all extension are auto-update by default), breaking security boundaries and more.

Good point. This is also the same for KeePassXC where the browser extension works by communicating with the main app process. The extension itself doesn't store the passwords.

And KeePassXC is open source and does not require cloud storage. So you can build from source and do not need to rely on any claims from the vendor on how the data is securely stored.

It is my hope that this article keeps the 1Password team steered away from in-browser solutions. I’ve seen a couple of experiments of them trying it, and I’d much rather keep the awesome and extremely trustable methods that they have used up til now.

Anyone else remember when they essentially pushed OSX to get better at security by having a tunnel of protected memory? (It’s been a minute and I know I won’t be able to find the article, so please excuse me if the details are wrong)

> I’ve seen a couple of experiments of them trying it,

? Browser-addon 1password has been the only way to use (modern?) 1password on Linux for a long time.

This is a recent development, but 1Password is now available on Linux as a native program, and it’s probably my favorite implementation!

https://1password.com/downloads/linux/

I have this installed but I have no idea how to make it put passwords into a given password field, or save the password as I'm setting one somewhere, so I went back to the browser addon. I think I'm getting too old to copy+paste passwords by hand. :/

> exploiting a browser-based password manager likely means escaping the sandbox that contains web pages and accessing the shadow DOM

Any PM that injects a script into the DOM is vulnerable, as the article explains, because the script runs with the exact same privilleges as everything else in the DOM (so the existing DOM can mess with your script or with the changes your script tries to make).

Also, the shadow DOM has nothing to do with security in any way. It's trivial to work around it whether it's closed or not. See https://blog.revillweb.com/open-vs-closed-shadow-dom-9f3d742... for example on how to do that.

The page's scripts can indeed see and alter the changes you make to the DOM, but cannot access the extension's script or data, so there isn't much risk actually.

Extensions are protected by a mechanism called Xray vision, not the shadow dom.

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Xray_v...

Why does that matter if the content script doesn’t have privileged access to anything itself?

Because one can monkey-patch any JS function used by the injected script, as the OP showed, to make the injected script do whatever it wants it to.

By one, you mean the website that the script is running on right? What's a possible attack vector there? I didn't understand how an attack might work from the example in the article.

If the domain of the site is checked by the browser extension outside the content process, injection of the password is initiated by the extension button not a button on the page itself so there is no API the content process has access to, and only the correct password for that domain is provided to the content script, what could the page do exactly that would be a security issue? The content process would just be responsible for receiving any password injected into the page and putting it in the righ place.

I'm also a 1password customer and curious how the attack vector of spoofing the 1password input icon can harm the user. They might be able to get your master password, but that doesn't mean they gain access to anything.

Also, I never use that icon and exclusively use the shortcut. I'm curious if that can be spoofed somehow. But again, they can only get your master password. In the case of 1password, I'm pretty sure they would need direct access to the computer to gain access to your vault.

"they might be able to get your master password, but that doesn't mean they gain access to anything"

I can't be the only one who finds that to be small comfort; isn't it sensible to respond, "if my 1Pwd master pwd is stolen, I must treat the vault as if it had been exposed"?

Not really. At least not in the 1Password case.

Having access to the 1Passswrd Master Password and your entire encrypted vault still doesn't get the attacker what they need. To decrypt your vault, you also need to know the 128 bit secret key which is also used in the encryption strategy that is stored offline (e.g. on a piece of paper in your safe or via another already authenticated device)

https://support.1password.com/secret-key-security/

This is not true for the standalone version of 1Password.

It’s 100% true of the standalone version of 1Password because there is only one version of 1Password - the standalone version.

Everything else interacts with it.

Your secret key is still required to decrypt passwords via the desktop application (which is the only version - everything else interacts with this.)

I believe he was referring to the old 1Password that let you handle the storage of your encrypted vault (which doesn't incorporate the secret key encryption approach)

Yes, I was - and it still exists and gets updates. 1Password goes out of their way to not promote it though.

And rightly so.

It has nothing to do with security - they want to move everyone to a subscription model for reoccurring revenue. I can't blame them for that, but it isn't necessarily the best for customers.

But that’s why you have choices - you’re not going to agree with or want what everyone is offering you. And like wise, that’s why businesses decide what choices to offer you - they’re not going to be able to serve every need.

In this case it is about security, I believe. Primarily because of the additional secret material needed to encrypt the vault, but also because I trust them to store that vault securely for me versus my self. I’m lazy. I’m forgetful. They’re not. It’s literally they’re business and they’re getting better at it daily (one would hope at least.)

That would be news to me. I have never used a secret key with 1Password and a local vault.

Then sounds like you're working with a diminished product that's less secure.

I am curious how managing secrets locally is less secure than a cloud based solution?

I was referring to additional piece of secret material required to decrypt the vault. It increases the key length by 128 bits. This is important in the general, overall scheme of things based on how your mother will use the product.

You’re not as good as they are at storing the vault, monitoring it, backing it up, and observing any and all access to that vault and reacting to access that’s not authorised. That’s literally their job and you have to trust someone to do that job well at some point (trust is the backbone of a healthy society)

Of course you can get as good, and better, but the time and energy required would burn hundreds of hours you might consider spending doing something that generates more money, therefore negating any (reasonable) price they put on their product.

In principle there’s no difference, but 1Password did happen to improve the security in parallel with their transition to a cloud-centric product.

That being said it’s worth noting that behaviour can be as important as technology. For example if a cloud-centric solution is more convenient, its users are less likely to engage in security compromising behaviours such as copying and pasting passwords, or declining to use a password manager at all outside of their local device context.

The article is about Cloud-based Password Managers.

With the current well designed systems, it isn’t the case however. That password is important (one of several factors), but you can’t get access with only that information. It is also something that is easy to change with no retroactive access abilities.

I 2 use 1password. I think it’s reliable enough

» Good examples of simple and safe password managers are keepass and keepassx, or even pass if you’re a nerd.

» I’m generally skeptical of these online subscription password managers, and that’s going to be the focus of the rest of this article.

I may be wrong but he talks about online password managers only, that's why his conclusion is «if you want a password manager in your browser, sue the one that's built-in». Otherwise, separate password managers are good, but author isn't talking about them.