1. 68
  1.  

  2. 34

    For those who don’t know, Tavis Ormandy is one of Google’s infosec research people, and has been involved in discovering many high-profile vulnerabilities. People should be taking his observations here seriously.

    1. 6

      On the other hand, they work for Google. Google makes a web browser, and their most profitable business is leveraging user data to sell advertisements and ???

      So this person saying “trust me, use your browser’s password manager” kinda seems like a conflict of interests…

      1. 7

        As someone who works on security for the competition, I can say this is far-fetched.

        The (current) security model of web extensions is really bad and Tavis is giving really good security advise by sugesting the browser built-in password manager mainly and firmly for the reason that it doesn’t have to subject itself to the a huge class of attacks. It’s somewhat hidden behind Tavis’ main evidence link.

        There are easily dozens of password managers implemented as extensions which have fallen into the very same trap. Really, the web extensions API are an unfortunately brittle foundation to build upon. The original author of AdBlock Plus, Wladimir Palant, has written countless articles of password managers being broken due to this poor design (and poor implementations), take a look at the password-manager category on his blog.

      2. 8

        If this had been written anonymously, should I take it less seriously??

        1. 27

          Attribution is one among many factors in considering what is worthy of your attention. Since the Internet is infinitely large in comparison to our available attention, most people only look at what they have somehow been guided to look at.

          In this case, you are looking at a website which is dedicated to pointing out other interesting websites, for some very weird values of “interesting”. So your first factor is “did it appear here?”. Another factor, probably weaker, is “how many votes did it get?”. A stronger factor would be “Does the subject line interest me?”.

          All that gets you to look at it, but the actual quality is still debatable. Since the subject is security, it is relevant that the author has some significant accomplishments in that area. If the subject was solo trekking the length of the Erie Canal, information security expertise might be much less useful in evaluating whether the author knows whereof they write.

          This whole process includes discovery and distribution in many different and repeated ways.

          So, yes, if this had been written anonymously, it is less likely that you would be seeing it and you might consider it less thoroughly. There are a lot of wackos out on the Internet.

          1. 2

            I think you’re raising a serious epistemological question, and I’m happy to chat about that over on IRC (regulars to the site should feel free to direct-message me), but I don’t think it makes sense to have the conversation here. It would be a lot of controversy and not really topical for the site.

            1. 2

              I agree that this is ad hominem but then again, ad hominem is only dangerous because it’s a good heuristic.

              Still, I agree that putting this here as an argument seems silly.

          2. 19

            The biggest problem with the ‘use your browser’s password store’ argument is that not every password is for a website. If I want to log in to an application and I use a third-party password storage thing, I can easily just copy-paste it out of my password manager. If I’m on my phone, I can even use the OS’s built-in autofill framework to do it for me!

            I don’t think there’s any good mechanism for doing this in Firefox or Chrome, since they assume that each password corresponds to a website, and they don’t have a good UI for just browsing passwords (since that’s not their use case).

            Of course, you could use the built-in password mechanism for your website passwords, and your third-party password mechanism of choice for your app passwords, but that’s clunky, and also runs into synchronization issues for things that have both a website and an app.

            1. 3

              I don’t think there’s any good mechanism for doing this in Firefox or Chrome, since they assume that each password corresponds to a website, and they don’t have a good UI for just browsing passwords (since that’s not their use case).

              What would you consider to be a good UI for browsing passwords?

              1. 4

                Something like bitwarden’s. That text field near the top lets you filter by the name you gave the psasword entry or by username (I keymashed into it so that I wouldn’t have any entries in it). When I want to log into FFXIV, I can just switch over to Bitwarden, type in “FFXIV”, and the entry pops up immediately. Firefox’s ‘browse passwords’ menu works roughly similar, but it requires each password to have an associated URL and it’s hidden behind a couple dialog clicks. It also doesn’t let me store things like recovery codes, my insurance information, or other things I want to have backed up in a secure way and easily accessible.

              2. 1

                Yeah, I love my password manager, but the idea of integrating it with a browser extension is super sketchy to me; I agree it massively increases the attack surface. I use a script that basically boils down to this:

                password=$(printf '%s\n' "${password_files[@]}" | rofi -dmenu "$@")
                pass show "$password" | { read -r pass; printf %s "$pass"; } |
                        xdotool type --clearmodifiers --file -
                

                Keeps a very strong separation between the sensitive bits and the unsafe nasty web, plus it works equally well inside and outside the browser.

              3. 14

                I would be very interested in a discussion around this. The author explicitly didn’t make any statements about differences in password managers. The claim is, they all have equally big attack surfaces if they use web extensions.

                Counter example: bitwarden does not inject any elements (it adds properties to input fields though). The extensions drop down interface has to be used. Does that make it safer? Or am I missing something?

                1. 10

                  Isn’t there a standardised API for password manager inputs in browsers? If not, why not?
                  Seems like it would stop all these password managers from reinventing the wheel every time; reduce some attack surface by having it built into the browser itself rather than injected elements.

                  1. 15

                    Both iOS[1] and Android[2] have standardised APIs. There is none for desktop browsers.

                    [1] Password AutoFill [2] Autofill framework

                    1. 1

                      yeah it feels like having OS’s or browsers offer a standard hook for credential storage and having the tools use it would resolve a lot of this stuff. I think the iOS stuff works very well, though there’s a lot of uncertainty about what domain you’re on inside app stuff sometimes, but it usually “fails” in the right direction (not filling in credentials vs filling in incorrect credentials)

                      1. 1

                        It also does not work smoothly on Android inside browsers other than Chrome.

                        1. 1

                          Really? I use KeePassDX on Android, with Firefox, and it seems to work fairly smoothly through the autofill framework. It also provides a fake/specialized keyboard implementation for places where autofill doesn’t work.

                          1. 1

                            Fascinating. I should try that.

                      2. 5

                        Chromium is backed by your OS password manager. If your password manager syncs with your native password store then it should interop smoothly. https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/docs/linux/password_storage.md

                      3. 5

                        As another example, keepassxc

                        • requires to pair the extension to the program first
                        • checks that the web page you’re logging in to matches the one saved in the password entry
                        • for good measure, asks for confirmation in a native popup before sending the password to the browser

                        As long as those checks are performed by the program or by the extension and not by the injected script, I don’t see the problem.

                        1. 1

                          Well, that is really hard to tell, though. So I agree that people should recommend specific products.

                        2. 4

                          There’s just a fundamental risk when mixing things inside an untrusted sandbox (the web page) and out where your secrets are. It’s much easier to do that well if you’re building a browser than if you’re building an extension - and even then there’s a long history of bugs with how browsers have done it.

                          I don’t know much about bitwarden, but a bit of poking around showed it injecting a few content scripts including one taken from 1password: https://github.com/bitwarden/browser/blob/master/src/content/autofill.js

                          1. 4

                            I haven’t looked too closely at the script, but it looks like it does two things: pull out the structure of the page, and then fill it. I have no clue whether either of these are exploitable, but it’s definitely not vulnerable to this sort of redress attack. In particular, the only way to trigger password fill is to click the extension icon or use the right-click menu, both of which are not vulnerable to the same sort of redress/IPC attacks that Tavis mentions. (Well, I guess you could write some JS to fake the right-click menu. But I’m not sure what the way around this is.)

                            It does inject elements (I think) if you fill in a page to show a ‘would you like to remember this password’-type dialog box, but that’s not really much of an attack surface.

                            Bitwarden can also be self-hosted, though this doesn’t protect you from the browser extension being malicious.

                        3. 11

                          The recommendation in the article’s conclusion’s depends on a certain assumption, but I’d like to note that this assumption may not be necessary. The conclusion:

                          If you want to use an online password manager, I would recommend using the one already built into your browser.

                          Why would you want to use an online password manager – that is, one built into your browser? By using a non-browser-based password manager, you could gain password management features such as storage of non-website passwords and storage of free-form notes with each entry while sacrificing very little convenience.

                          The article’s introduction mentions some offline password managers such as KeePass, KeePassX, and pass. On macOS, I personally prefer KeePassXC, a successor to KeePassX.

                          With KeePassXC, my password is not auto-filled when I visit a login page. (Perhaps KeePassXC’s browser extension has this feature, but I avoided installing it due to the principle of least privilege.) However, I can still use KeePassXC’s “auto-type” feature to simulate keyboard entry of my username and password in one go. I can also copy the username and password to the clipboard individually for pasting. The one downside to these methods is that the password manager will not warn me if I am trying to type the password into a phishing site – I have to be sure to first visit the site through a trusted bookmark or the link in the password entry.

                          Note that that “non-browser-based” doesn’t mean you will be forced to rely on one device to look up your passwords. You can use an online file sync service – a proprietary one like Dropbox or Google Drive or an open-source one like Syncthing or ownCloud – to make your password database available on multiple devices. I use this strategy to access my KeePassXC password database on both my laptop and my phone.

                          As your password database is encrypted at rest, online syncing requires only trusting your file sync service to not leak your files to anyone who would spend time brute-forcing your password. I find that trust easier to give than trusting a browser-based password management company to both not leak my encrypted password to their many attackers and to not serve me a version of the software with encryption disabled.

                          If you use password manager to share credentials among multiple users, you could still use a non-browser-based password manager plus a file sync service, but it’s less suited for that use-case. If multiple users add a password to the database at the same time, one of the users will have to manually resolve the conflict.

                          1. 2

                            This sounds like a decent middle ground between comfort and security. You might also consider hosting your password manager yourself. Bitwarden, which I use, is open source and has multiple server implementations. And because of the way bitwardens client - server communication protocol works, I don’t have to trust my hosting provider to not read my data.

                          2. 6

                            But what if you want to use the passwords outside fo the browser?

                            1. 2

                              Fully agreed. It came up a couple of times in the thread that people use their password manager for more than simply websites. Nowadays people probably also want to use their password manager on their phone and everything should stay in sync without too much additional effort.

                            2. 4

                              If you want to use an online password manager, I would recommend using the one already built into your browser. They provide the same functionality, and can sidestep these fundamental problems with extensions.

                              Except that they don’t support sharing passwords, let alone role-based access controls.

                              1. 3

                                You’re doing role based access control using passwords and a password manager?

                                So when e.g. somebody loses a role you change the pw and update it in everybody’s manager?

                                And when something gets screwed up you only know that it was somebody who had the password because everybody uses the same account?

                                Imho password sharing is an anti-feature.

                                1. 5

                                  B2B vendors have a nasty habit of mandating one account per customer company instead of one account per human. Password sharing solves this problem.

                                  1. 1

                                    And it gets even more fun when the vendor has “you must change your password every 30 days” rules, which was a constant headache with dozens of one-login-per-company vendors at my last job.

                                  2. 2

                                    Many people have multiple computing devices, sharing allows you to use the same password store on all of them instead of having to laboriously setup and manage multiple password stores.

                                    1. 1

                                      Oh, yeah, that’s fine and can be handled using a shared db. This was about sharing with other people. :)

                                    2. 1

                                      My girlfriend and I share passwords for a couple sites (streaming ones, mostly). It’s not role-based because there’s just two of us, and we could just let each other know if the password has to be changed, but it’s not an anti-feature.

                                      1. 1

                                        I think it is an anti-feature because it prevents the proper security requirements unless you also have some kind of shared master password.

                                        The password manager company should simply not be able to share your password with someone because they should not be able to access it.

                                      2. 1

                                        So when e.g. somebody loses a role you change the pw and update it in everybody’s manager?

                                        And when something gets screwed up you only know that it was somebody who had the password because everybody uses the same account?

                                        It’s mostly me, but I have multiple environments that require varying levels of access. It’s mainly to try and contain the damage from a breach on any one device. It sucks, but very few sites/services allow you to enable access to different users.

                                    3. 1

                                      I wonder why no password manager has support for hashicorp’s vault. I guess I also wonder why vault has so few 3rd party tools. It’s like almost nobody uses it.

                                      1. 3

                                        Adobe has a GUI one: https://github.com/adobe/cryptr I wrote a POSIX shell one: https://hg.sr.ht/~zie/vpw