7 ms·

I'm a little disappointed in the conclusion because there are more secure password managers out there that still offer the same level of convenience as the brow

by kbuck 5y ago

I'm a little disappointed in the conclusion because there are more secure password managers out there that still offer the same level of convenience as the browser built-in password manager. Yes, if you use a password manager that's implemented entirely as a browser extension, you may as well use the browser's built-in password management features. However, if you're an advanced user and are comfortable using a separate password management application, there are options out there that don't force you to choose between a difficult-to-use app and the convenience of something in-browser. For example, exploiting a browser-based password manager likely means escaping the sandbox that contains web pages and accessing the shadow DOM. But this is still a larger surface area than 1Password, where the password selection menu (on Windows at least...) is actually rendered by an entirely separate process on the system. (I.e., clicking the icons that the extension displays triggers the 1Password desktop application to display UI at the cursor's current position. Picking a password from this UI will transmit it to the browser extension for filling. The password is only present in the browser's memory once you've interacted with the desktop application's UI.) As always, do your research. Don't get suckered into paying a subscription fee for a browser extension that offers the same functionality your browser has built-in. But realize that there are other options out there that may actually be worth investing in. Disclaimer: I've been a happy 1Password customer for a few years now.

kennywinker 5y ago
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.
- cordite 5y ago
  What if browsers exposed the capabilities to locate the inputs, act upon user input, supply generated passwords, etc. in a sandboxed manner?
  - oefrha 5y ago
    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_autofill 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.
  - peteretep 5y ago
    Or, even better, no passwords and just sensible pki
    - shawnz 5y ago
      A browser-integrated password management API could make for a smoother transition to a future automated auth technology based on public keys, like WebAuthn
- geofft 5y ago
  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.
- CyberRage 5y ago
  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.
bstar77 5y ago
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.
- chrisweekly 5y ago
  "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"?
  - lazide 5y ago
    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.
  - a10c 5y ago
    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/ https://support.1password.com/secret-key-security/
    - miked85 5y ago
      This is not true for the standalone version of 1Password.
joshspankit 5y ago
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)
- ben0x539 5y ago
  > 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.
  - noahtallen 5y ago
    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/ https://1password.com/downloads/linux/
    - ben0x539 5y ago
      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. :/
      - deleted 5y ago
        [deleted]
xerxesaa 5y ago
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.
CyberRage 5y ago
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-resolved/ https://blog.lastpass.com/2019/09/lastpass-bug-reported-reso... https://www.csis.dk/newsroom-blog-overview/2021/moserpass-supply-chain/ 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.
- oefrha 5y ago
  > https://blog.lastpass.com/2019/09/lastpass-bug-reported-resolved/ 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-supply-chain/ 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?
  - CyberRage 5y ago
    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.
    - oefrha 5y ago
      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.
brabel 5y ago
> 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-9f3d7427d1af https://blog.revillweb.com/open-vs-closed-shadow-dom-9f3d742... for example on how to do that.
- ubercow13 5y ago
  Why does that matter if the content script doesn’t have privileged access to anything itself?
  - brabel 5y ago
    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.
    - ubercow13 5y ago
      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.
- Seb-C 5y ago
  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_vision https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Xray_v...
vort3 5y ago
» 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.

by kbuck 5y ago

kennywinker 5y ago

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.

cordite 5y ago
What if browsers exposed the capabilities to locate the inputs, act upon user input, supply generated passwords, etc. in a sandboxed manner?
- oefrha 5y ago
  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_autofill 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.
- peteretep 5y ago
  Or, even better, no passwords and just sensible pki
  - shawnz 5y ago
    A browser-integrated password management API could make for a smoother transition to a future automated auth technology based on public keys, like WebAuthn
geofft 5y ago
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.
CyberRage 5y ago
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.

bstar77 5y ago

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.

chrisweekly 5y ago
"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"?
- lazide 5y ago
  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.
- a10c 5y ago
  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/ https://support.1password.com/secret-key-security/
  - miked85 5y ago
    This is not true for the standalone version of 1Password.

joshspankit 5y ago

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)

ben0x539 5y ago
> 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.
- noahtallen 5y ago
  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/ https://1password.com/downloads/linux/
  - ben0x539 5y ago
    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. :/
    - deleted 5y ago
      [deleted]

xerxesaa 5y ago

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.

CyberRage 5y ago

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-resolved/ https://blog.lastpass.com/2019/09/lastpass-bug-reported-reso... https://www.csis.dk/newsroom-blog-overview/2021/moserpass-supply-chain/ 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.

oefrha 5y ago
> https://blog.lastpass.com/2019/09/lastpass-bug-reported-resolved/ 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-supply-chain/ 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?
- CyberRage 5y ago
  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.
  - oefrha 5y ago
    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.

brabel 5y ago

> 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-9f3d7427d1af https://blog.revillweb.com/open-vs-closed-shadow-dom-9f3d742... for example on how to do that.

ubercow13 5y ago
Why does that matter if the content script doesn’t have privileged access to anything itself?
- brabel 5y ago
  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.
  - ubercow13 5y ago
    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.
Seb-C 5y ago
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_vision https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Xray_v...

vort3 5y ago

» 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.