How safe are password managers like LastPass?

We should distinguish between offline password managers (like Password Safe) and online password managers (like LastPass).

Offline password managers carry relatively little risk. It is true that the saved passwords are a single point of failure. But then, your computer is a single point of failure too. The most likely cause of a breach is getting malware on your computer. Without a password manager, malware can quietly sit and capture all the passwords you use. With a password manager, it's slightly worse, because once the malware has captured the master password, it gets all your passwords. But then, who cares about the ones you never use? It is theoretically possible that the password manager could be trojaned, or have a back door - but this is true with any software. I feel comfortable trusting widely used password managers, like Password Safe.

Online password managers have the significant benefit that your passwords are available on anyone's computer, but they also carry somewhat more risk. Partly that the online database could be breached (whether by hacking, court order, malicious insider, etc.) Also because LastPass integrates with browsers, it has a larger attack surface, so there could be technical vulnerabilities (which are unlikely with a standalone app like Password Safe).

Now, for most people these risks are acceptable, and I would suggest that the approach of using a password manager like LastPass for most of your passwords is better than using the same password everywhere - which seems to be the main alternative. But I wouldn't store every password in there; make an effort to memorize your most important ones, like online banking.

I know someone who won't use Password Safe and instead has a physical notebook with his passwords in obfuscated form. This notebook is obviously much safer against malware... whether it's at greater risk of loss/theft is an interesting question.

[Disclosure: I work for AgileBits, the makers of 1Password. As it would be inappropriate for me to comment on the security architecture of competitors, I will address things in general, and talk specifically only about 1Password.]

Yes. Password managers create a single point of failure. You are keeping all of your eggs in one basket. I, obviously, think that a well-designed password manager is the right choice. But ultimately it is a choice that each individual needs to make for themselves.

It is extremely important to look at how that basket is protected. With 1Password you can read the details of how the data is stored. Although we make heavy use of PBKDF2, it is very important that people choose a good master password. The only confirmed case of a 1Password data breach that I've seen is when someone used the same master password as she used for her unencrypted POP3/HTTP Road Runner email. The same password was also used for her Dropbox account, which was also taken over and is how we presume the attacker obtained the 1Password data.

As for trusting the people behind a password manager, that is a trickier question. I do think that it is safe to say that anyone who is has been in the password management business for a while wouldn't risk trying to make an extra buck off of banking credentials or credit cards. Even if we were crooks at heart, that would just be bad business, as the mere suspicion of such a scheme would put the vendor out of business. Stolen credit card details sell for little more than one USD each when purchased in bulk on black markets. Banking credentials are about five times as much. The math just doesn't work for anyone whose livelihood comes from selling password management tools.

As as already been mentioned, in some schemes the data never goes to the vendor in any format. This is true of 1Password. We never see how anyone is using 1Password. However, to synchronize data across systems, we do rely on third party synching systems. So your encrypted data may be stolen from Dropbox as well as be stolen from your own computer if you use Dropbox to sync data. You should always assume that there is a non-negligible possibility that your encrypted data will be captured. This then goes back to how well your data is encrypted, which is something to look at carefully.

The other questions about trusting the suppliers of the password management system come down to trusting our competence and trusting that we haven't been coerced/bribed/"persuaded" to allow for a back door into the system. This is a lot more complicated. How do the vendors deal with security bugs as they are discovered? How much of the product's behavior and design is independently verifiable? Do the creators understand the crypto that they are using?

For systems, like 1Password, that don't have any data from users, there is very little reason for us to even be approached by government agencies (and we haven't been.) At the same time, you should assume that governments do have access to your data stored on sync systems. So again, this comes back to the question of how that data is encrypted.

Disclaimer: I created PfP: Pain-free Passwords as a hobby, it could be considered a LastPass competitor.

I've been looking into the security issues of several password managers on a number of occasions. In particular, I reported twelve security issues to LastPass so far and analyzed the design decisions that led to these. So while paj28 gave a very good general answer about password managers, I can provide some details.

When people talk about the security of online password managers, they usually focus on server security. The focus is on how easy is it to compromise the server and what will happen then. This is only one attack vector however, because attacking your local password manager instance might lead to the same results. In fact, attacking the browser extension might be a more promising course of action, as the data is already decrypted there and you won't leave traces in any logs.

Let me look at these two aspects separately.

Attacking the browser extension

There is a lot of historical data on vulnerabilities in the LastPass browser extension. All these vulnerabilities could be exploited by arbitrary webpages. At the very least, these are:

• Flaw in AutoFill functionality (Mathias Karlsson)
• Exposed internal API (Tavis Ormandy)
• Three LastPass extension vulnerabilities (yours truly)
  • Another flaw in AutoFill (deemed non-exploitable by LastPass, only to be proven wrong by Tavis Ormandy later)
  • Another exposed internal API
  • Remote code execution, full extension compromise
• Yet again a flaw in AutoFill (Tavis Ormandy)
• Yet again exposed internal API (Tavis Ormandy)
• And once more exposed internal API, resulting in remote code execution (Tavis Ormandy)

Did you notice a pattern here? LastPass has been struggling for years to secure their AutoFill functionality and to restrict access to their internal API. Each time a new report proved that their previous fix was incomplete.

Now it isn't unusual that password managers fail to implement AutoFill securely, most of them had issues in this area when I checked. While totally avoidable, these issues are common enough that I even compiled a list with recommendations to avoid the traps.

But the internal API issues are quite remarkable. LastPass exposes this API to websites in a number of different ways. It's meant to be restricted to lastpass.com but the logic is so complex that the restrictions have been circumvented several times in the past. And while LastPass did their best to downplay the severity in their official announcements, each of these issues allowed websites to read out all passwords at once. Worse yet, the last report by Tavis Ormandy proved that the internal API could be used to make the binary LastPass component execute arbitrary code on user's machine. Same could probably be done with all the previous flaws which exposed internal API.

One could of course ask why LastPass failed to restrict access to the internal API properly. But the better question is why this API is exposed to websites at all. That's because a significant part of the LastPass functionality isn't contained in the extension but rather relies on the LastPass website to work. That's a very problematic design decision but so far LastPass didn't seem interested in fixing it.

Attacking server-side data

Let's state this very clearly: we don't trust the server. It's not that we particularly distrust LogMeIn, Inc. - at least not more than any other company. But our passwords are very sensitive data, and even the most ethical company might have a rogue employee. Add to this the possibility that US authorities demand them to produce your data, something that isn't even necessarily associated with a criminal investigation. Never mind the possibility that their servers get hacked, like it already happened once.

So it is very important that your data on the server is encrypted and useless to anybody who can get hold of it. But what can possibly stop the attackers from decrypting it? Exactly one thing: they don't know your master password which is used to derive the encryption key. So the essential question is: does LastPass sufficiently protect your master password and encryption key?

In this area, I am not aware of any publicized research but my own, most of it written down in this blog post. My conclusion here: LastPass suffers from a number of design flaws here, some being resolved by now while others are still active.

Bruteforcing the master password

If the attackers got their hands on a bunch of encrypted data, the most straightforward decryption approach is: guess the master password used to derive the encryption key. You can try an unlimited number of guesses locally, on whatever hardware you can afford, so this process will be comparably quick.

LastPass uses PBKDF2 algorithm to derive the encryption key from the master password. While being inferior to newer algorithms like bcrypt, scrypt or Argon2, this algorithm has the important property of making key derivation slow, so attackers doing guessing locally will be slowed down. The time required is proportional to the number of iterations, meaning: the higher the number of iterations, the harder it will be to guess a master password.

For a long time, the LastPass default was 5,000 iterations. This is an extremely low value that provides very little protection. I calculated that a single GeForce GTX 1080 Ti graphics card could be used to test 346,000 guesses per second. That’s enough to go through the database with over a billion passwords known from various website leaks in barely more than one hour.

Following my reports, LastPass increased the default to 100,000 iterations mid-2018 which is far more adequate. Of course, if you are an important target who could expect state-level resources being thrown at guessing your master password, you should still choose an extremely strong master password.

Getting hold of data to bruteforce

One of my findings in early 2018 was that the script https://lastpass.com/newvault/websiteBackgroundScript.php could be loaded by any website. That script contained both your LastPass username and a piece of encrypted data (private RSA key). With your LastPass username being also the password derivation salt, that's all someone needs to bruteforce your master password locally.

This issue was resolved quickly of course. However, the flaw was obvious enough that I'm left wondering whether I was the first to discover it. While I urged LastPass to check their logs for signs of this vulnerability being exploited in the wild, to my knowledge this investigation never happened.

"Server-side rounds" as useless protection

Following a security incident in 2011, LastPass implemented an additional security mechanism: in addition to your PBKDF2 iterations on the client side they would add another 100,000 iterations on the server. So in theory, if somebody could get data off the server, this would increase the effort required to guess your master password.

In practice, I could conclusively prove that these additional 100,000 iterations are only applied to the password hash. All the other pieces of user data (passwords, RSA keys, OTPs and more) are only encrypted using the encryption key derived locally from your master password, no additional protection here. Conclusion: this additional "protection" is a complete waste of server resources and doesn't provide any value whatsoever.

Getting in through the back door

No matter how weak the protection, brute force attacks will always be ineffective against the strongest master passwords. However, the design of LastPass contains plenty of backdoors that would allow decrypting the data without expending any effort.

The web interface

LastPass conveniently provides you with a web interface to access your passwords without the help of a browser extension. This feature is a trap however: whenever you enter your master password into a login form on the web, there is no way of knowing whether it will hash your master password with PBKDF2 before sending it to the server or whether it will transmit it as clear text.

Remember that we don't trust the server? Yet a trivial modification of the JavaScript code served up by the server is enough to compromise all your passwords. Even if you inspect that JavaScript code, there is too much of it for you to notice anything. And it would be possible to serve up the modified code only to specific users.

Account settings

Even if you use the browser extension consistently, whenever you go to the account settings it will load up the lastpass.com website. Here again, there is no way for you to know that this website isn't compromise and won't steal your data in the background.

Several other pieces of the extension functionality are also implemented by falling back to the lastpass.com website, and LastPass doesn't see the issue here.

Recovery OTP

LastPass has the concept of One-Time Passwords (OTPs) that you can use to recover data from your account if you ever forget the master password. These OTPs allow decrypting your data but aren't normally known to the server.

To make recovery even more reliable, LastPass will create a recovery OTP automatically by default and store it in the extension data. The issue here: the recovery process has been designed in such a way that the extension would immediately give lastpass.com that recovery OTP on demand, without even notifying you. So a compromised LastPass server could ask the extension for your recovery OTP and use it to decrypt your data.

According to LastPass, this issue has been resolved in August 2018. I don't know how they resolved it however, at least I couldn't see any of the obvious solutions in their code.

Exposure of the encryption key

There is also a number of occasions where the extension will directly expose your local encryption key to LastPass servers. This is meant to help web-based LastPass functionality integrate better with the browser extension, but it nullifies the effects of encrypting data locally. The following actions are all problematic:

• Opening Account Settings, Security Challenge, History, Bookmarklets, Credit Monitoring
• Linking to a personal account
• Adding an identity
• Importing data if the binary component isn’t installed
• Printing all sites
• Clicking on a breach notification

The last one is particularly serious because the LastPass server can send you breach notifications at will. So this allows LastPass to gain access to your data whenever they like, rather than waiting for you to use problematic functionality on your own.

More design flaws

• As you can see by yourself by opening up https://lastpass.com/getaccts.php while logged in, the LastPass vault is by no means an encrypted blob of data. It rather has encrypted data here and there, while other fields like the URL corresponding to the account merely use hex encoding. This issue was pointed out in this 2015 presentation and more fields became encrypted since then - still by far not all of them however. In particular, a report I filed pointed out that Equivalent Domains not being encrypted allowed LastPass server to modify that list and extract your passwords in that way. This particular issue has been resolved in August 2018 according to LastPass.
• Same presentation scolds LastPass for their use of AES-ECB for encryption. Among other things, it gives away which of your passwords are identical. LastPass has been transitioning to AES-CBC ever since, yet when I looked at my "vault" I saw a bunch of AES-ECB-encrypted credentials there (you can tell because AES-ECB is merely a base64-encoded blob whereas the LastPass variant of AES-CBC starts with an exclamation mark).
• Recovery OTP being created automatically and stored in the extension data means that anybody with access to your device and email address can access your LastPass account. This is actually documented and considered a low risk. Maybe one of your co-workers played a prank on you by sending an email in your name because you forgot to lock your computer - next time they might take over your LastPass account even if you are logged out of LastPass.
• Speaking of being logged out, the default session expiration time is two weeks. While certainly being convenient, there is a reason why most products handling sensitive data have much shorter session expiration intervals, typically well below one day.
• For combining a value with a secret (e.g. as a signature) one would usually use SHA256-HMAC. LastPass uses a custom approach instead, applying SHA256 hashing twice. While the attacks that HMAC is meant to address don't seem to play a role here, I wouldn't bet on somebody with better crypto knowledge than me not finding a vulnerability here after all. Also, the server side will occasionally produce some SHA256 tokens as well - I wonder what kind of humbug is going on where I cannot see it and whether it's really secure.