Liz and Geoffrey discuss password manager extensions in depth: everything from how they keep your passwords safe from malicious websites to how they sync your passwords between your devices to how they've made mistakes in the past. If you haven't picked a password manager yet, this hard look into the security records of popular password managers sheds light on which companies have earned your trust, but even if you're a long-time password manager user, knowing about their usual pitfalls helps keep you safe from potential future issues. Also, the new iOS 13 has a variety of security implications, and Firefox and Chrome change third-party cookie settings.
Timeline
- 1:28 - Security news: 1Password adds support for U2F security keys
- 3:54 - Security news: WWDC announcements about iOS 13
- 8:21 - Security news: Firefox and Chrome changes third-party content handling
- 11:57 - This episode's scope and suggestions for other episode's to listen to first
- 12:44 - The design of password manager extensions
- 16:15 - Common issues with password manager extensions
- 22:55 - Browser password manager track records
- 26:46 - Track records of third-party password managers
Show notes & further reading
This episodes concludes a short series exploring strong authentication methods: the previous episodes were "Using a password manager effectively" (March 20, 2019) and "Two-factor tidying" (May 16, 2019). If you're new to password managers, check out our very first episode, "Securing your online account passwords" (May 29, 2018), for an overview of strong passwords and password managers.
Also check out our password manager reference page, which includes a feature comparison of the major password managers we discuss in this episode.
Password manager extensions and split architecture
In "Using a password manager effectively," we discussed how an easy way to check the basic security of your password manager extension is to make sure that the UI for the extension only suggests data for the current website, and anything else - including a prompt for your master password - shows up somehow outside the current website. (It may be a window that is drawn to cover the address bar, which it outside the area that web pages can access, or it may just be a totally separate window from your password manager's app.) The reason for this is related to the two-part architecture we discuss in detail in this episode: anything that could access all your saved passwords must be completely separate from the part of the password manager extension that embeds itself into the web page. Anything embedded in a web page could potentially be under the control of that web page, and it's important that the embedded portion of the password manager cannot be allowed to do anything beyond requesting the password for that one page. The more sensitive core of the password manager, which could be part of an extension or the regular standalone app, isn't part of the web page, which is why it has the ability to draw its UI outside of the web page.
Security white papers
Two of the password managers we discuss have good "white papers" detailing their security architecture: see 1Password's and Dashlane's. We think it's a good practice for password managers to make these available, both to show that they've thought about their security design in detail and to answer specific questions about their design. For instance, Dashlane's document mentions both the split architecture (page 18, phrased as a distinction between JavaScript and C++) and the fact that the automatic password change feature runs on servers operated by Dashlane, which see your password temporarily, instead of on your own computer (page 11).
The others we mention don't quite have one: Keeper has a white paper that's just a product feature tour, LastPass's seems to be offline as of this writing, and the popular extensions for KeePass and KeePassXC don't have one, although there is a security page for KeePass itself.
CVEs
MITRE, a US government contractor that has been working in software since the 1950s, maintains a database of Common Vulnerabilities and Exposures, or "CVEs" for short. Each CVE assigns a numerical ID to a specific security bug, e.g., CVE-2018-4430 refers to one of the three FaceTime security bugs we talked about in our October 30, 2018 episode. Security teams, including researchers, software authors, and IT departments, use the database to keep track of findings, and it's a de facto standard for all software, not just in the US. For instance, Apple will mention CVE IDs in security updates.
You can search the CVE database on MITRE's website, at the National Institute of Standards and Technology's National Vulnerability Database, or on a variety of other websites that index the database.
Searching the web for a specific CVE ID is a good way to find other discussions of the bug, such as writeups from security researchers.
Browser password managers
At this writing, while Elliot Kember's 2013 blog post about Chrome showing passwords is online in its original location, the images don't load. To see the screenshots, see the copy on the Internet Archive. In December 2013, Chrome added an option to prompt for the OS login password before showing passwords, although this was intended solely as a roadblock against casual snooping.
In the news
Apple made several announcements at WWDC earlier this month, many of which touch on privacy and security. "Sign in with Apple" lets you log into third-party sites; we discussed similar systems in our recent episode "Using a password manager effectively." Their new "Find My" system has some interesting cryptography to secure your device's data, which WIRED reports on the details of. They're now banning third-party ads and analytics from apps targeted for children, an issue we discussed in the news segment of "Digital photos and privacy" last fall.
Apple announced a few more things that we didn't mention in the podcast: the next version of iOS will support non-destructive video editing, which allows you to see the original of a video that you've cropped, trimmed, or filters. This is useful for your own videos, but as we discussed in "Digital photos and privacy," a risk of non-destructive editing is that data you might not have wanted recorded sticks around, and depending on how you export your media, might still be in the file. For most systems like this, using the built-in sharing features instead of directly sharing the file will avoid this risk. Finally, they also introduced new security features in HomeKit, including encrypting the video from security cameras so Apple can't see it and analyzing the video on your own device - most competing home security systems do the analysis on the vendor's cloud servers - as well as the ability for HomeKit routers to isolate smart home devices from the rest of your network.
Firefox is enabling its existing Enhanced Tracking Protection feature by default for new users. Existing users can enable it in privacy preferences - see their blog post for instructions on how to do so.
Chrome is making its built-in third-party cookie blocker easier to find, although not enabling it by default. Existing Chrome users can also turn it on by following the instructions in Google's support article - in the "Change your cookie settings" section of this support article, click "Allow or block cookies by default" to find the information about third-party cookies.
Transcript
Geoffrey Thomas (GT): Welcome back to Loose Leaf Security. In today's episode, we're taking a closer look at the security track records of specific password managers.
Liz Denys (LD): If you've decided to use a password manager but haven't picked one yet, this episode has you covered - we'll talk about the major password manager extensions and mobile apps and how they've handled some recent security problems.
GT: But even if you've been using the same password manager for years and love it, it's worth listening to get a better understanding on how password manager security is supposed to work and what the common weak points are. That way, when new security issues and threats come out, you'll be well-equipped to respond.
LD: We'll talk about which attacks are the most concerning, so you'll be able to evaluate the many password managers out there and figure out which makes the most sense for your own personal security needs.
GT: And hopefully get a better understanding about what you should be concerned about generally.
LD: Right, the more threat models you know well, the better prepared you'll be to figure out what your threat model should be for your other security needs.
Intro music plays.
LD: Hello and welcome to Loose Leaf Security! I'm Liz Denys,
GT: and I'm Geoffrey Thomas, and we're your hosts.
LD: Loose Leaf Security is a show about making good computer security practice for everyone. We believe you don't need to be a software engineer or security professional to understand how to keep your devices and data safe.
GT: In every episode, we tackle a typical security concern or walk you through a recent incident.
Intro music fades out.
LD: Before we get to our main segment, as always, we've got some security news to catch up on. Our first bit of news is actually about a password manager: 1Password just announced that they've added support for U2F security keys.
GT: We're both primarily 1Password users and have mentioned before that we haven't personally set up second factors for our password managers. As a reminder, requiring a second factor for your password manager isn't a replacement for having second factors on your individual accounts - if one of your accounts is ever in a breach, your password manager's second factor won't do anything to prevent someone from using that breached information to get into your account.
LD: Right, a second factor on your password manager only helps prevent someone from getting your passwords via your password manager, and that's why it's so important to pick a password manager that has a strong security record, and we'll get into that in our main segment today.
GT: Though, of course, it can't hurt to add a second factor to your password manager as long as you are confident you won't accidentally get locked out of your account and lose access to all your passwords.
LD: So, since security keys are really convenient and easy to use, 1Password adding U2F support was actually the push that I needed to get a second factor set up on my password manager.
GT: But you still need an authenticator app to use it on your iPhone, right, Liz?
LD: Yeah, because I don't have a Bluetooth security key, the only kind that would work with my iPhone, I also have an authenticator app on my phone and my backup phone. Since there's so little that I log into or out of on my phone, I've only opened up my password manager app up once on my phone since setting up my second factor, so while that was actually kind of a pain, I'm not too concerned that it'll really bother me.
GT: Oh, is this because you have the 1Password app immediately lock on exit?
LD: Sure is! Let me be more clear as to why this was such a pain - because I both have 1Password immediately lock on exit and don't let it unlock via TouchID, leaving the 1Password app to open up my authenticator app to grab my two-factor code meant 1Password locked again. So when I went back to the 1Password app again, I needed to re-enter my long master password after copying the two-factor code, which was actually kind of tough since I'm really not that great at typing on my phone's keyboard and two-factor codes only last 30 seconds.
GT: Oh, that is annoying. Fortunately, 1Password says that they only require a second factor for logging into new devices.
LD: Yeah, that is what they say, so hopefully I won't get into that loop again on my phone, but I've had to use my second factor a few times on my laptop, even though I've said it's a private device where I'm willing to let 1Password remember me. But at least having to tap my security key is convenient enough that I don't mind.
GT: Apple announced iOS 13 at their Worldwide Developer's Conference earlier this month, and there are a bunch of new privacy features. First up, Apple has entered the third party login space by adding "Sign in with Apple", which offers users the ability to sign in with a single button tap that authenticates over TouchID or FaceID instead of needing to create another account.
LD: A neat feature Apple put into "Sign in with Apple" is the ability to choose whether or not the service gets to see your actual email address or instead, a unique address that Apple forwards to your real address behind the scenes. It's a nice nod towards privacy, because it makes tracking your account across apps a little harder.
GT: However, "Sign in with Apple" still has the same provider lock in problem as other third-party logins like "Login with Google", "Login with Facebook", or so on, so losing access to your Apple account for whatever reason could cause you to lose access to a lot of other services.
LD: Though, I do think that using Apple for a third-party login is a little different than the other popular options of Login with Facebook or Twitter because Apple accounts these days are primarily about enabling you to use devices you purchase from them. It's arguably in the interests of social media companies to temporarily or permanently ban you if something you post gets reported, you know whether or not what you post actually is in violation of their terms of services, but Apple actually has a really strong incentive to make sure you can continuously access your account: the products you buy from them become a lot harder to use if you lose access to it.
GT: Right, and Apple caring about privacy is much more in line with its business interests as a device manufacturer than for companies like Google and Facebook whose business models center on gathering information about you and using that information to target ads.
LD: Regardless, if you ever do want to delete your Apple account for whatever reason, you'll have to switch any accounts that you have with "Sign in with Apple" to something else. Make sure you're aware of the downsides to using third-party logins before you "Sign in with Apple" - we talked more about this in our episode "Using a password manager effectively."
GT: Apple also added additional options to control location tracking. Previously, you could only choose to give an app access to your location all the time, when using the app, or never, but now there will be an additional option to allow location access just once. If the app wants access to your location again, it will have to prompt you again.
LD: In addition to the new "allow just once" option, iOS 13 users will get periodic pop-ups that show maps of how apps are using their location in the background. When you get one of those, you'll also be offered the option to limit that app's location access. Given how easy it is to set and forget which apps get access to your location data, I think this is a really user-friendly way to reduce unnecessary tracking.
GT: If you want to check up on what's tracking always your location before iOS 13 comes out, you can still do that: in the Settings app under Privacy, look in Location Services. You won't be able to see a map yet, but you can double check that nothing unexpected is tracking you.
LD: Speaking of tracking, Apple is also rolling out a new, more general version of Find My iPhone and Find My Mac which will just be known as Find My. The new Find My system will be based on a novel encryption system that is designed to prevent tracking, including tracking by Apple. Apple hasn't finalized this system yet, but from what we know, it sounds like it will be turn your device into a Bluetooth beacon that will broadcast encrypted location information across networks of Apple devices.
GT: The encryption is set up between your phone and another Apple device - so you do need a second device from Apple for this feature to work - but only those devices will be able to see where your phone is.
LD: I like that Apple and its employees won't be able to see your location because they won't be able to decrypt those location messages, but it is a bit frustrating that you now have to have two Apple devices to get to use the newer Find My feature.
GT: On the Safari side, you'll soon be able to enable microphone, camera, and location access on a per website basis, which is much better than granting blanket access for any site you visit.
LD: One change that wasn't announced at WWDC but came out at the same time involved new rules for apps targeting kids: Apple is no longer allowing the apps in the Kids category to have third-party ads or analytics tools.
GT: They've also banned external links and in-app purchases unless they're put in a section of the app that's only for parents.
LD: We talked briefly before about how gathering personal information and location data for children is in a grey area surrounding informed consent, and we're glad that Apple has removed some of that ambiguity in favor of increased privacy.
GT: There were a bunch of other announced features that have security and privacy implications - some positive, some negative - but they affect pretty specific groups of users. To avoid turning this into a WWDC podcast, we have a bit more discussion in our show notes.
LD: Our last news segment is about changes to how various browsers handle third-party content like tracking cookies. Chrome and Firefox have both added built-in support for disabling third-party cookies.
LD: Chrome's new built-in third-party cookie blocker, on the other hand, will not be on by default. And I have to say, the setting to block third-party cookies is currently quite buried, and typing "third-party" in the settings search bar doesn't currently give any results. We'll include where to find Chrome's settings in our show notes, too.
GT: By the way, if you use Apple's Safari as your browser, you've gotten third-party cookie blocking by default for years.
LD: I think there's a lot to be said about making privacy the default - it's unclear how many users change their settings, particularly when it's hard to find. An old study from 2009 suggested about 10% of users disabled third-party cookies. Though more recently, I hear a lot more people talking about ad blockers and third party cookies, and of course, this was also before browsers started blocking this content by default. I think people, both inside and outside of tech, are generally becoming more aware of how the web works as we all come to rely on it more and more. On the other hand, I also know that even when I'm aware of browser settings that I want to change - it still sometimes takes me a while to get to actually remember to change them while I'm at my computer instead of, say, reading about the latest updates to my web browser from my phone.
GT: It's also not clear to me that it's in Google's interests to make privacy the default for Chrome - we talked last episode about how Firefox is more or less an independent voice in the browser ecosystem and they're run by a non-profit, but Google makes a lot of their revenue by selling advertisements. Google definitely has a lot more tracking options available to them than just third-party cookies, but I'm not surprised that Google didn't choose to make privacy the default given their business interests.
LD: Google's also in the process of making another change to Chrome that could break a lot of extensions, including third-party content blockers that are commonly referred to as ad blockers. Their Manifest v3 plan will limit how extensions can examine websites, and those changes will likely break third-party content blockers.
GT: There's been a lot of pushback to these changes, and so far, Google has said that they're still going forward with them, but there might be some exceptions for enterprise users.
LD: I suppose there's a security argument that third-party content blocking should be done in your browser because you already have to trust your browser to use it, and by doing it in the browser itself instead of through an extension, you don't have to also trust another party, that extension. But I think that argument assumes that everyone's incentives are aligned towards improving consumer privacy, and that's not always been clear. While I appreciate browsers doing more of this content blocking natively, it doesn't make me feel great to no longer have the option to use an extension made by someone else. Of course, it's important to make sure that the extension is well-vetted and doing what it should be, and there have been lots of ad blockers out there that either do something malicious or don't actually block a lot of the ads they know about. But it's nice to have more than just the one option provided by your browser itself.
GT: Yeah, we talk more about third-party cookies and how to choose trustworthy unwanted content blocker extensions in our episode "Web security continued: cookies, plugins, and extensions."
LD: And as a reminder, you can check out this episode's show notes for how to turn on third-party cookie blocking in Chrome and Firefox's settings.
GT: We'll get to our main segment after a quick break.
Interlude music plays.
LD: Today we're finishing up our mini-series on improving the security of your website logins - last time we talked about "Two-factor tidying," and the episode before that, we looked at "Using a password manager effectively."
GT: In this episode, we're taking a hard look at password manager security, including going through some specific security issues that various password managers have had in the past.
LD: By the way, if password managers are new to you, you might want to check out our very first episode "Securing your online account passwords," which covers online account security more generally and the tradeoffs of password managers versus other ways of handling all the passwords you need for various websites.
GT: Spoiler - we mostly ended up on the side of password managers. Although, to be fair, I only really started using one a couple of years ago. I had a password scheme before that, and I'm sure there are a few websites I rarely log into that are still on that scheme.
LD: One of the big reasons we like password managers, as we discussed two episodes ago, is how they have browser extensions which automatically fill in the right password for the right site, and they don't offer to fill in a password on the wrong site. This is one of the two strongest defenses you can have against phishing attacks - where someone sends you a link to a page that looks like a login page you use frequently, but is actually run by an attacker who's trying to harvest your passwords.
GT: The other strong defense against phishing attacks is security keys as a second factor, which we've mentioned a few times when we've talked about two-factor authentication.
LD: Security keys are excellent second factors and we both use them where we can, but they only provide phishing protection for accounts that let you use them for two-factor. By using a password manager, you can get that phishing protection for all your online accounts.
GT: Right. Both password manager browser extensions and security keys will check which website you're on before filling in any information. If you're copying a password from a separate password manager app or entering an authentication code from a text message or something like that, there's always the risk that you get tricked by a phishing page and enter the secret into the wrong place.
LD: The tradeoff here is that the password manager extensions are a whole bunch of complicated code that's running inside your browser, so it's a bigger attack surface. By using an extension instead of a separate, isolated app, you're intentionally telling your password manager to integrate deeply into your browser, and so it's a lot easier for something to go wrong.
GT: Usually that's one of the concerns people have - certainly it feels safer not to have something automatically fill in passwords, and to check yourself whether the password should get copied in. And to be honest, that isn't a bad instinct!
LD: Yeah, there have been some serious issues with password manager extensions, and in particular, their autofill functions, before. The good news is, you can look at the track records of various password managers, see which ones have been affected, and then evaluate how they've responded.
GT: The basic problem is, if a browser extension is going to add features to a website like a password fill button, it simultaneously needs to add some code that runs as that website - basically, it temporarily pretends to be that website - and also it has to have a bunch of special access that the website doesn't actually have, like accessing your saved passwords, and it needs to be very careful about balancing those two requirements.
LD: In our episode last year "The history of the Web and an introduction to browser security," we talked about how browsers separate websites into their own isolated areas - we called them snow boots. If snow somehow manages to get into your left shoe, at least it won't leak somehow into your right shoe. In the same way, if something goes wrong with one website, it's contained to that website. But a browser extension has access to all websites - all the snow boots - at once. If something goes wrong with the extension, it's like spraying snow into all of your shoes!
GT: So usually the way that password manager extensions work is they have two parts. One is the tiny bit of code that runs inside a web page and sends a message saying, "I'd like to request passwords for this web page only." The other part, which has the actual passwords and sees your master password, stays away from web pages and only responds to messages sent by that first component.
LD: In many cases, that second component is your password manager's desktop app. That's because historically it's been very hard to do cryptography and keep files safe from inside a browser, and password managers usually had an app already. So the extension can communicate with that app.
GT: And you can think of a few things that can go wrong with this setup. What if any website can send a message saying, I want passwords for some other websites? What if those two components aren't actually separate? And that's roughly what's gone wrong with password manager extensions in the past. It's definitely possible to get things right, and the major password managers do, but it's a little tricky.
LD: Back in our episode "Malware, antivirus, and safe downloads," we started off by talking about the history of desktop security, and if you remember from that episode, there isn't really the same sort of isolation with desktop applications as there is with websites. Websites in your browser are isolated, and apps from an app store are usually kept separate, too, but traditional desktop apps all have access to each other's data.
GT: This is the episode where everything is all coming together! I guess that's usually how things work with computer security - a lot of the day-to-day stuff is just thinking about how the pieces fit together for whatever specific situation you're trying to keep yourself safe in.
LD: Right. That's part of why we don't like endorsing specific products - everyone's specific situations are different - so instead, we focus on how to evaluate various products. For password managers, the upshot is that there is very little you can do to protect yourself from malicious programs running on your computer. You can lock your password manager, but all that means is that malware needs to wait around until you unlock it.
GT: We talked a little bit about this last time around, when there was a story in the news about an attack on all password managers. It turns out that attack is just this regular risk - that it's possible for one program running on a traditional desktop computer to mess with another program running in the same user account on that computer.
LD: There was a little bit of subtlety to it: they found that many password manager had passwords still in memory even after they were locked, which is a valid issue, but it's not one I'd be particularly concerned about. In most cases, if malware can get onto your computer, it can get into your password manager simply by being patient - at some point, you're going to unlock your password manager. Since it's easy for malware to just wait for that unlock, you're not actually at significantly more at risk from this issue.
GT: One of the members of 1Password's security team actually wrote an interesting, lengthy response - his argument is basically that occasionally leaving copies of the password in memory is a tradeoff, because if they tried to manually specify every single thing the password manager does with memory, they'd run a huge risk of getting it wrong somewhere, and that could cause bigger problems - for instance, they might mis-handle some input from the browser extension and corrupt the trusted portion of 1Password. His argument a bit technical, but it's a good example of carefully weighing the downsides of two options. The most robust ways of writing secure code in general require them to give up the ability to scrub the password reliably.
LD: Of course, just because the risk is well-known doesn't mean it's any less of a risk. If you use a traditional computer regularly - which you probably do - it's absolutely worth being cautious about what programs you download and who has access to your computer, even temporarily.
GT: Mobile platforms tend to be a lot better about this, because they don't have to be compatible with the desktop model where every app has access to everything. A random app you download can't trivially get into your password manager.
LD: Even so, you shouldn't really go downloading random apps from your phone or tablet's app store - they might try to exploit vulnerabilities on those devices, or they might do other things you don't like, like using all your data and tracking you.
GT: Right. I don't download weird apps, especially from places other than the app store, but I do feel much more comfortable installing a random mobile game on my phone than downloading a game from a developer's website on my laptop. The unfortunate reality is that, by design, every traditional desktop or laptop application has access to all of your files, and you should be careful about what you download from the web.
LD: To some extent, this means that how well a password manager encrypts your data, or like we were saying earlier, whether there's two-factor authentication on your account, isn't that important for the day-to-day security of your passwords. It's much more important to keep your device secure and free of malware.
GT: However, all of this is very important for how you synchronize your passwords between devices - you want to make sure they're encrypted in a way that only your own devices can get access to your passwords. They shouldn't be accessible to whatever service is helping you sync the passwords, whether that's a password manager's own cloud service or some other file transfer tool. And they definitely shouldn't be accessible to a new device unless you prove your identity beyond a doubt. So you should absolutely set a strong master password.
LD: And it's also a good idea to keep your passwords encrypted even on your device, so that you have multiple layers of security or what's called defense in depth. Even though it's not difficult for malware to extract passwords from a running password manager, there are so many other risks, like old backup drives or lost laptops, and it would be a lot easier to just get your decrypted passwords there if you're storing them in plaintext. You can argue that you should be using encrypted disks - and, again, we'd agree - but the major password managers tend to do their own encryption, too.
GT: That said, browsers' built-in password managers are often the exception here. One of the more interesting examples was several years ago, when people discovered that Chrome would reveal your saved passwords in the settings window without prompting for anything, and that this was on purpose. Chrome's argument was they didn't want their users to have a false sense of security - they wanted people to know that if you give someone access to your browser, they also have access to your passwords.
LD: And that's true, of course, but they were quite brusque about dismissing complaints because many people expected, and still expect, to let someone else use their browser briefly and not expose all of their passwords. Chrome's engineering team is technically correct when they say you shouldn't be doing that, but let's be realistic - we've all let our friend borrow our laptop to check something before.
GT: Safari saves its passwords in the macOS Keychain, which is encrypted with your login password or some other password you choose. And it tells you when your keychain is locked or unlocked and it plays a little sound, so you know if your keychain is accessible at the moment or not. It's sort of like locking the door to your bathroom - those locks aren't meant to be secure against someone trying to pick it, but you expect your friends aren't actually going to do that.
LD: Firefox actually encourages you to set a master password for the password manager. But the encryption is pretty weak. Specifically, the way they convert your password to an encryption key was considered out-of-date a decade ago, and they still haven't changed it. If you aren't using a long phrase as your master password, it's likely that it can be brute-forced.
GT: As far as I can tell, none of the encryption mechanisms for browser password managers are very strong. On Windows, Chrome and Edge use a built-in encryption function that's based on your Windows login password and makes decryption available to any program running in your account. So it's maybe a little helpful for lost disks, but it won't save you from malware or someone snooping around inside your unlocked computer. And even for the macOS Keychain, it's not clear how it's encrypted - the current macOS Security Overview document just refers to protecting Keychain with "Access Control Lists," not encryption. That will work for sandboxed apps from the App Store, but not for traditional desktop apps.
LD: Even so, Chrome ended up adding a little prompt for you to type your login password before showing your saved passwords. It definitely helps against casual snooping, but you should still remember that an attacker who really wants your passwords can get them if they can get malware onto your computer.
GT: Apart from encryption on disk, browsers tend to be pretty good about the security of their password managers. This isn't too surprising - browsers already need to make sure they're only making cookies and other saved data available to the right site, so adding passwords isn't too complicated.
LD: You're already relying on your browser to be secure, to make snow boots that don't have big holes in them. So relying on them for saved passwords is pretty sensible. The big drawback, the reason Geoffrey and I both use third-party password managers, is that syncing passwords between devices is weaker, and especially syncing between devices that use different browsers - that's really difficult.
GT: We took a look for security issues about browser password managers getting isolation wrong, and there really haven't been many. If you're interested, you can take a look for yourself - there's a standard catalog of software security issues run by a US government contractor: it's called Common Vulnerabilities and Exposures, or CVE for short.
LD: The CVE database is handy for security teams at big companies, because it provides a label for a specific issue. You can say, "Oh, has Apple fixed CVE-2019-8550 yet?" instead of saying, "The iPhone FaceTime bug" and then someone else being like, "Which FaceTime bug?" But the fact that things are nicely cataloged is helpful for us as individuals, too, so we can see the track record of a piece of software - both how often things go wrong and what kind of security issues there are with it.
GT: There are a number of sites that let you search through CVEs, and we'll link to some of them in our show notes. Looking at password manager bugs in the major browsers, the most recent ones about filling a password into the wrong site were all years ago. Like in 2014, Safari on iOS would autofill passwords against HTTPS sites with bad certificates, potentially leaking passwords to malicious pages trying to impersonate a real page.
LD: That's pretty bad, but it kind of makes sense how you'd forget to put in this check. Browsers tend to be pretty good at filling in the right password for the right site, right?
GT: Yeah, in the last few years, it seems like there haven't been bugs where they fill against a totally unrelated site, which makes sense because they're already doing origin checking just to get the basic parts of the browser right. Back in 2010 there was an issue in Chrome where if you put a password-protected image on another site, it would fill in that other site's password to the original site. So you could imagine someone, like, putting an image in a forum post but having that image be hosted by a malicious website, and it would autofill with the forum credentials.
LD: Wow, 2010 doesn't feel that long ago, but it's amazing how much basic things in digital security have matured in the last few years.
GT: Yeah, if you go to the previous decades, you can see some really interesting views. One is that on MySpace -
LD: That's a name I haven't heard in a while! Wow, everything was full of animations and popups and marquees and everything.
GT: So MySpace, basically, let you upload your own custom HTML and JavaScript.
LD: The world really was a different place then. That led to some huge security vulnerabilities, because all of that ran inside MySpace's snow boot, right?
GT: Precisely, but we didn't have a great model of how web security was supposed to work back then. If someone put a username and password field on their MySpace profile and set the form to send the password to their own page, browsers would still fill in the MySpace password, and people thought this was a problem.
LD: But you could just grab the cookies from the page. Or use JavaScript to click on anything on MySpace.
GT: Right, even then, there was pushback about whether this was really a bug, but they decided to fix it - they only fill in the MySpace password if it's going to MySpace. Still, yes, malicious JavaScript could just read that password before it gets sent. Fortunately, in the years since then, websites that let anyone upload custom HTML and JavaScript have faded away.
LD: Or if custom styling is still a feature - they'll generally move your HTML and JavaScript to its own origin, so it's isolated from every other page on that site. Or, even better, they'll just let you upload a few custom images to decorate the page. They'll host those images themselves, and that doesn't run the same security risks as being allowed to put in arbitrary code.
GT: So let's take a look at password manager extensions. They're more difficult to get right in general, because they don't have access to the web browser's internals, and so they need to do things like have the two-part architecture we talked about earlier. And there's more room for things to go wrong.
LD: There's a team at Google called Project Zero, which does security research generally on non-Google products. The motivation for Google, I think, is generally to improve the web and more specifically to improve commonly-used products that they're using internally and that their customers tend to use. We took a look at their research on password manager extensions: it's one way to get a sense of how secure various password managers are.
GT: It's not foolproof - password manager extensions aren't their main mission, and in any case, there's no guarantee that Project Zero will find every problem. But it's a good way to get a rough idea of whether things look generally solid or not. And the Project Zero team is pretty familiar with all the complicated corners of browser security.
LD: Out of the top five most popular password managers we listed on our resources page, the only one they didn't report anything from was KeePass - but that's not too surprising. KeePass is the open-source, do-it-yourself option, so there isn't a single obvious extension to use with it. There are a few popular ones, but even for the app itself, there's both KeePass and KeePassXC.
GT: As for the others, we're going to run through them in alphabetical order, to be impartial. 1Password had one issue in 2016 - someone who can run code on your computer can send a message to the app pretending to be the extension. This only happened on Windows, and the root of the problem was a sort of footnote to a way that Windows lets you identify who's sending an app a message, that lets you pretend to be another app.
LD: Hold up, what's the vulnerability there? Didn't we just say that you can't protect against other apps, only against other websites?
GT: Yeah, this one is subtle: it's saying that another user on your computer can send those messages. If you share your computer with multiple people and you all have separate logins, one person's apps and files shouldn't be able to interact with another person's. It's basically another layer of snow boots.
LD: Hm, okay. That does seem like a problem, but it's probably a problem for very few people. We've recommended against sharing computers before, because someone needs to have an admin account, and if you have an admin account you generally can get into other users' accounts. And also, there's a lot of ways that someone else having physical access to your computer can let them get to your files.
GT: And it only applies if you lock the screen and switch users - if you're logged out, your copy of 1Password isn't running any more. Still, it's better not to rely on that on a multi-user machine, so it's good to know that they fixed this. Somewhat disappointingly, it took about two months after the report to publish the fix, even though they responded confirming the issue on the same day.
LD: Next up is Dashlane, which also had an interesting issue in 2016. Project Zero didn't find any attacks on the password manager itself, but they did find the presence of the Dashlane extension introduced a pathway for a cross-site scripting attack between two websites.
GT: Oh, interesting. So it's like... they left a paper towel on top of the snow boots, and water soaked up from one and dripped into the other.
LD: I think you're stretching this analogy a bit too far to make sense, but you're not wrong. If a malicious website expected its victims to have the Dashlane extension installed, it could trick that extension into sending JavaScript to another open tab, and mess with the website that way, possibly monitoring your login process or stealing your cookies.
GT: That one was also patched pretty quickly - they got back to Google with a proposed fix the same day. I think it's not super surprising that they had a bug since their extension is a bit younger, and it's also a good sign that they fixed it quickly.
LD: Keeper did a little less well. There were two recent issues, one in 2016 and another in 2017, and they were basically the same problem: the in-page half of their extension had the ability to search through all saved passwords and make any request of what should have been the out-of-page half of the extension. So any website you were on could see if you had Keeper installed, and fetch passwords for any other website.
GT: In general, I don't think counting the number of bugs in a piece of software is a really fair way to measure how secure it is, but in this case it doesn't sit well with me that it was basically the same bug both times, and also that the bug was about the basic design of the extension and how to properly keep your information secure.
LD: Right. You're really looking less at whether they messed up, or got tripped up by something buried in, say, some Windows documentation, than at how it happened and whether they had a good process for writing secure software and updating those bugs. Everyone makes typos, but if you're publishing an encyclopedia and have released multiple editions with the same incorrect information worded differently, even after those mistakes were brought to your attention, that's more of a sign of a problem.
GT: They did fix each of the issues within under two days, and while it's a great thing that they can respond, fix, and publish updates quickly, I wish they also had some signs of a process to audit for these sorts of problems proactively.
LD: That brings us to LastPass, which Project Zero found five issues in, in the last few years. The first one was in their Firefox extension: when you clicked the LastPass button in a password field, they set up an open channel from the website to the LastPass app. A malicious web page could send all sorts of messages through that channel, including searching for any password and even logging you into a new LastPass account so all your new saved passwords go to the attacker's account instead of just into yours. And you didn't even have to click it: because it's a button present in the web page, malicious code in the web page is able to trigger an artificial click of that button and do all of this behind the scenes.
GT: So, basically the same as Keeper's issues above - not being paranoid about messages that are sent where websites can control them.
LD: The next one was actually sort of a repeat of an issue from 2015, where a researcher at the security firm Detectify found that the LastPass extension would be very easily tricked by bad URLs. It turns out you could make a website on any domain name and put some special characters and "twitter.com," and the LastPass extension would gladly fill in the twitter.com password.
GT: That's... quite bad. To be fair to them, this was before browsers had built-in functionality that websites could use to make sense of a URL. It turns out URLs can b pretty complicated, and it is actually kind of hard to make sure you're not getting fooled by them.
LD: Yeah, we mentioned this briefly in our show notes in the previous password episode. By now, password manager extensions ought to be able to use this built-in function and work reliably. But even without the help of browsers, the process of making sense of a URL is well-defined. It might be complicated, but password manager extensions need to be particularly careful about not being tricked up about this.
GT: Right, the whole reason I'm using a password manager extension is I don't trust myself to read the URL right, so it's pretty bad if the extension isn't doing that either. So they fixed the 2015 issue that Detectify reported, but it came back?
LD: Right. Project Zero found a particularly strange format of URL that would still trip up LastPass's improved code. So basically, LastPass hadn't completely fixed the problem, it was just much harder to figure out how to break their code.
GT: It is a little frustrating that they responded to this issue and published a fix, only to find out two years later that the fix wasn't complete. And while I want to cut them some slack for this being hard, it kind of also is the most important hard problem a password manager extension needs to solve, and none of the others had this sort of issue.
LD: Also in 2017, they had an issue where they apparently wanted to let some page on lastpass.com send messages to the extension. But they didn't do any filtering of the messages, and worse, they also didn't do any filtering of whether they were actually coming from that one page. And some of the messages would let you run code or access passwords.
GT: That's also pretty bad news. I feel like it's a design issue in general for the password manager company's website to have special access to the extension - in a sense, yes, it's the same people who are giving you the code for the password manager itself and automatic software updates to it, but it shouldn't be too easy for their servers to send orders to your local password manager.
LD: They fixed it by taking down that one web page, but as it happens, that only blocked the issue in Chrome, not Firefox, because Chrome doesn't run extensions on error pages and Firefox does. Finally, there was one very subtle issue about the difficulty of writing secure browser extensions in general. LastPass was badly hit by this one, and to their credit, they set to cleaning things up quickly.
GT: Even so, it sounds like, of the major password manager extensions, LastPass fared the worst. Which is not to say it's bad as a password manager, but if the value of a password manager to you is the browser extension, it has a weaker track record than the other major ones do.
LD: It's certainly not the worst of the ones Project Zero looked at, though. This was only among the really popular ones that it fared so badly.
GT: Oh? Did they look at some other small ones?
LD: Yeah. Trend Micro, the antivirus maker, has a password manager and their own browser - what they call a "Secure Browser."
GT: Let me guess, it wasn't.
LD: So the "Secure Browser," it turns out, is based on Chrome - although it was a version of Chrome that was close to a year out of date. And it even runs with an option to disable sandboxing, or that snow boot-ing that we've talked about before.
GT: Like literally running around in the snow in socks!
LD: Yup, and Project Zero found this because the password manager starts up a little web server on your computer, and one of the things the web server could do is open up the secure browser. It turns out that another thing the web server could do is run any program on your computer, or return any saved password and decrypt it.
GT: This seems like one of the worst possible ways to implement the split of the untrusted and trusted halves of a password manager. While it's very easy to access a web server from a browser extension - after all, it's what browsers are good at doing - by the same token, it's also very easy for any random website to access that same web server. So if you visited a malicious website - which could just be clicking a weird link because you're curious or even loading a malicious ad on an otherwise trustworthy web page - it could impersonate the password manager extension.
LD: They got the update for this out in a week, after Project Zero pushed them on it. It fixed the most serious of their problems, but it looks like there are a lot of other functions in this web server that Project Zero didn't investigate in detail, and it's definitely not clear that Trend Micro did, either.
GT: I guess, points to them for responding quickly, but I think the design issue is the bigger concern here. What they should have done is said, hold up, there are way better ways of communicating between the password manager extension and its core without letting everyone communicate with that core. I mean, what they should have done is implemented a secure communication channel from day one, and not have needed an outside researcher to tell them about it. So I'm really concerned about the underlying quality of this software - and not just the password manager component, but the "Secure Browser," the antivirus, and everything else, too.
LD: Well, you should be. Two months later they found another embedded web server in Trend Micro's password manager and their antivirus products, which also let you run any code on the computer.
GT: Oh my. Just two months? And it took Google to find it again?
LD: Yeah, and they couldn't fix it promptly because it wasn't even their own code running that server. Trend Micro said it was a "3rd party binary" and their engineers needed, quote, "extra time to crack open the source code to disable the debug port." And what they ended up shipping was a workaround - basically jamming something else in front of that server to prevent it from opening the port - instead of actually implementing a proper fix.
GT: I... you know, this is basically a textbook example of a security track record that's not trustworthy. It seems like there are some underlying issues with how they've designed this software, and even if they're very responsive to researchers who find problems - which is great, by the way - that can only get so far.
LD: Also these issues weren't just in the password manager, it was also in their antivirus products. It goes back to what we were saying in our episode "Malware, antivirus, and safe downloads" - the tradeoff is that antivirus software generally has significant access to your system to get its job done, and if something goes wrong with how the antivirus software is written, it can introduce security problems that wouldn't have been there in the first place.
GT: We should also note that this is a pretty limited cross-section of security vulnerabilities. It's just what Project Zero could find in a specific block of time when they happened to be interested in password manager extensions.
LD: And as we mentioned, they didn't look at KeePass, so you shouldn't take this as advice that a specific password manager is going to be great forever.
GT: Though I am feeling a lot more confident about my choice of password manager from these results.
LD: A better takeaway is to pay attention to security updates and blog posts from the team that makes your password manager, and see what sort of things they're fixing and how they're doing it.
GT: And dig a little bit behind the blog post - that's generally going to have some edits from their marketing team, but if the researcher has their own post on the situation, even if you don't follow exactly what the attack is, you can get a sense of how well-designed the underlying product is.
LD: Yeah, Project Zero discloses the emails they sent and received when reporting an issue, and if you look at their notes on the Trend Micro issue, you can see them being clearly shocked at the design of the system and how it's not like the rest of the password managers they looked at.
GT: And you can also take a look at news reports and see how password managers have responded to those - like the news from earlier this year about leaking passwords in memory. If the company making your password manager can give a quick, straightforward response, that is a sign of confidence. If they're not saying anything, or they spend a lot of time saying how there's no evidence any customer data was stolen -
LD: Well, a properly-designed password manager shouldn't leak any information back to the company, so they shouldn't have that data in the first place!
GT: Yeah, they're just trying to sound reassuring. Which is very different from actually being reassuring. If they say, "This issue isn't important because it's not how our threat model works," that's one thing. If they say, "This issue isn't important because we haven't heard anyone lose their passwords because of it," that's quite another.
LD: So we've generally been talking about the threat models and security design of desktop password managers and their browser extensions. One last thing that's worth going into is how mobile password managers make sure the password is going to the right place.
GT: Mobile platforms like Android and iOS have browser-style isolation between apps, but apps don't have URLs - so how does your saved password for facebook.com get to the Facebook app but not anyone else? Or worse, how is your phone supposed to know that your saved accounts.google.com password is allowed to go to the Google Maps or the YouTube apps?
LD: It turns out that on both Android and iOS, there's a way that apps and websites can attest that they're related. That attestation has to happen in both directions, which is good for security - you can't just have an app claiming it wants facebook.com passwords. The Facebook website also has to say, yes, this app should in fact get my password.
GT: Apple's feature is called "associated domains," and Android uses Google's "Digital Asset Links." They're not just used for passwords, they're used for things like opening links inside an app. And they're both very similar in design: when the app developer uploads their app, there's something inside that package that says, "I'd like to be associated with this website." There's also a file in a well-known location on the website saying, "I'd like to be associated with this app."
LD: Both Apple's and Google's systems access this URL on the website from the phone that the app is being installed on, so the phone is not just trusting the app store. It's verifying for itself that the website wants to share login credentials with the app.
GT: Once the device knows about this relationship, if you tell your password manager app to fill in a password in an app, it will be able to find saved passwords for the corresponding website - and not show you saved passwords for other websites.
LD: Both of these mechanisms are relatively recent, especially for third-party password managers as opposed to the one that came with your phone's OS. The Password Manager API that lets you use third-party password managers is new in iOS 12, released last year. And Android password managers only started using Digital Asset Links last fall.
GT: Before that, password managers would generally check the Android app's package name, which is a codename that's usually somehow based on the name of the app maker's website. Facebook's app, for instance, is called "com.facebook.katana." But the trouble is that these names aren't necessarily trustworthy.
LD: Last year, a group of Italian researchers discovered that it's really easy to make an app with a package name that includes the word "Facebook" and get it into the Play Store - and that would be enough for password managers to prompt to autofill Facebook credentials.
GT: At the time of this research, only Google's own Smart Lock actually checked Digital Asset Links. All the other major password managers were vulnerable to an attack of some form, although some of the problems were more serious than others.
LD: Dashlane had the biggest problem, but also the best response. They were just searching for any text in common, so an app with "Face" in its package name, anywhere, would get the Facebook password suggested. Their immediate response was to add a warning when filling a password on a new app, asking you to make sure it sounds like it's the right app. But they've now implemented Digital Asset Link checking, and won't show a warning if it's verified. Not all websites and apps have set up Digital Asset Links, so it's still good to be paranoid if you do see that warning from the Dashlane mobile app.
GT: 1Password took a different approach: they never tried to guess about which password to fill, and they still don't. They let you search for all passwords that you've saved, and they try to make it clear that you're on your own. 1Password has said that they avoided Digital Asset Links in the past because it wasn't mature, but the researchers inspired them to take a second look at it. However, it seems they still haven't implemented it.
LD: One thing I'm wondering about this is whether you could have noticed something was up and kept yourself safe, even before the researchers dug into all the details.
GT: Right, like we've said before for password manager extensions - if you see a prompt for your master password be inside the web page as opposed to obviously outside it, or if you see all your password suggestions available within a single website, that's a sign something is going wrong.
LD: For 1Password, since they listed all the passwords, it should have been pretty obvious that they weren't actually trying to filter to the right site, and you needed to verify this for yourself. That is, unless you weren't just starting to set up your password manager and only had a few websites in it.
GT: For the other ones, maybe, maybe not. If you didn't have tons of apps prompting for your password, it probably would have looked like it's doing the right thing, since even though the password managers were guessing, they probably would have guessed right most of the time. Now that they have warnings, you should definitely pay attention to those and make sure you're filling in the password on the right app.
LD: The other high-level takeaway here is that you were safer on Apple, at the expense of having the feature much later. Apple insists that third-party password managers use their API, and their API always goes through the associated domains feature.
GT: Which feels very typical of Apple versus Android's differing stances to security, as we've discussed before in our episode "Comparing Android and iOS security." For example, Android discourages using sideloaded apps, that is, apps from outside the Play Store, but you can turn it on. Apple prohibits it - you have to jailbreak the phone. Android let third-party password managers build autofill well before Apple did, but it didn't give them a good way to verify sites. So you got more features on Android sooner, but the tradeoff is the burden of keeping yourself secure falls more on you.
LD: Whatever platform you choose, though, your security is ultimately in your own hands. Hopefully, you've now got a better idea of how to evaluate password managers - and can apply that to other security software, too.
GT: Um, Liz, we're at the end of the episode, and did we have any super witty signoff? I don't think we did anything at the beginning either.
LD: You know, for once, I think we made it through an episode without any terrible jokes.
GT: Well, other than the terrible joke of a security record of -
LD: Now now, Geoffrey, be nice.
GT: Okay, fine.
Outro music plays.
LD: Loose Leaf Security is produced by me, Liz Denys.
GT: Our theme music, arranged by Liz, is based on excerpts of "Venus: The Bringer of Peace" from Gustav Holst's original two piano arrangement of The Planets.
LD: For a transcript of this show and links for further reading about topics covered in this episode, head on over to looseleafsecurity.com. You can also follow us on Twitter, Instagram, and Facebook at @LooseLeafSecure.
GT: If you want to support the show, we'd really appreciate it if you could head to iTunes and leave us a nice review or just tell your friends about the podcast. Those simple actions can really help us.
Outro music fades out.