How safe are password managers like LastPass?

Question

I use LastPass to store and use my passwords, so I do not have duplicate passwords even if I have to register four to five different accounts a day, and the passwords are long.

How safe are password manager services like LastPass? Don't they create a single point of failure? They are very attractive services for hackers. How can I trust the people behind these services and their security mechanisms? I imagine that a third party (government, company, etc.) would be very easy to 'bribe' and get all of my passwords.

Are there any other solutions that offer similar services with similar ease of use?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

Are your passwords really safe?

I have used Lastpass, and I always wonder how we can be sure that they don't send our master password along with the database to their servers. They could even set the client to poll the server and do this for specific users only, to prevent discovery. This concerns the NSA and Patriot Act of course, or other agencies that can force companies to do something like this and keep it a secret.

Forget about the NSA

For me, keeping everything secure from the agencies is something different than keeping my logins secret. I would like to keep everything secret from them, but they simply have so much and different resources and manpower that I can only make an effort. If they target me specifically, I'm probably lost. They can hack my home router, my phone, my laptop, install key loggers etc and I wouldn't have a clue. Agencies that have legal power (even if we don't agree with them or if they are from other countries) will be difficult to stop.

So simply forget about the NSA and GCHQ etc - because it won't get us normal people anywhere. Well... forget about it in this context.

Lastpass or Keepass or ...?

If Lastpass would upload our passwords by default, and if this was to be discovered, they would be in big trouble. I've used Lastpass for about a year, but stopped because of the way it interacts with the browser. I don't like the intrusive methods to insert dropdown menus into web forms, and it slowed down my browser. When I used Lastpass I used it for all those trivial forums where it didn't matter much if I lost the password or the login. For the more serious passwords I use Keepass.

I use Keepass and have done so for years. Is Keepass safe? It's offline! But do you know for sure that it never sends out data? I use it for logins to websites like Amazon, Apple, ISP, Paypal, big shops - in short: those websites that have my credit card number.

Some passwords I memorize and don't keep anywhere except in my mind.

Answer 5

Jeffery's answer is particularly insightful - the main risk is all around the economics. One of the biggest threats may be for failing password managers (those not making enough money for their author). A malicious actor can 'rescue' the developer by buying the product, and changing the program to send data to themselves (perhaps in a hard-to-detect fashion). So it's probably important to ensure the password manager you use appears to be financially successful for it's author.

I recently became uneasy about the password manager app which I had been using for a long time (and previously paid for). Development seemed to have largely stopped, the app became free (a big red flag in my opinion) and ownership may have changed hands. I've switched to another app, but it's hard to know if my data was compromised.

Answer 6

Some services like this offer cloud "convenience" and others do not. If you're allowing your passwords to be stored to the cloud then you are putting more trust in the application, as there is a single source of attack to retrieving data representing all users' stored passwords. Assuming these passwords are encrypted uniquely for each user then the risk might be mitigated, but regardless of how much mitigation there, is, this remains a single attack point.

Contrast with applications that only store passwords locally (or enable you to migrate your database manually). Here, your effort level might be greater, but the attack point is on a machine you presumably have more control over and it's a much less interesting attack point since it only has your passwords. That doesn't immunize you completely of course; a trojan horse could certainly be written to seek these out and send them elsewhere.

The bottom line is you have to decide where you want to trade off security for convenience, but it's certainly a trade off in most (if not all) cases. My own take on the situation is that if I didn't write the application, I don't know what it's doing and I'm that much less likely to trust it.

Answer 7

Here are some papers that you might be interested in:

• "Password Managers: Risks, Pitfalls, and Improvements" (2014)

Abstract:

We study the security of popular password managers and their policies on automatically filling in passwords in web pages. We examine browser built-in password managers, mobile password managers, and 3rd party managers. We show that there are significant differences in autofill policies among password managers. Many autofill policies can lead to disastrous consequences where a remote network attacker can extract multiple passwords from the user's password manager without any interaction with the user. We experiment with these attacks and with techniques to enhance the security of password managers. We show that our enhancements can be adopted by existing managers.

• "Vulnerability and Risk Analysis of Two Commercial Browser and Cloud Based Password Managers" (2013)

Abstract:

Web users are confronted with the daunting challenges of managing more and more passwords to protect their valuable assets on different online services. Password manager is one of the most popular solutions designed to address such challenges by saving users' passwords and later auto-filling the login forms on behalf of users. All the major browser vendors have provided password manager as a built-in feature; third-party vendors have also provided many password managers. In this paper, we analyze the security of two very popular commercial password managers: LastPass and RoboForm. Both of them are Browser and Cloud based Password Managers (BCPMs), and both of them have millions of active users worldwide. We investigate the security design and implementation of these two BCPMs with the focus on their underlying cryptographic mechanisms. We identify several critical, high, and medium risk level vulnerabilities that could be exploited by different types of attackers to break the security of these two BCPMs. Moreover, we provide some general suggestions to help improve the security design of these and similar BCPMs. We hope our analysis and suggestions could also be valuable to other cloud-based data security products and research.

Paper download locations and some other related papers are detailed at https://www.wilderssecurity.com/threads/password-manager-security-papers.365724/, a forum thread that I created.

Answer 8

The requirement is for an offline access of credentials. For example a small notebook on which you write all your security details for all banks, stores, websites, even combination locks, addresses and all other details you may wish to be able to access from any location in the world.

Online access of credentials is OK but not perfect, since you will need to be near a PC connected to the internet before you can access any of your details.

Online systems also pose the risk for hackers, governments, and individual employees of the gatekeeper companies stealing the data or making it unavailable when you need it. Read on "silk road" for examples of repeated and persistent loss of personal information.

A better solution would be a hardware device that you carry with you, like a tiny USB stick, which has some simple software to store and encrypt your information as well as retrieve it when you plug it in a PC or Mac. Ideally it would have bluetooth to be able to be accessed on your mobile phone. It might need some tiny battery for that. And if you are not near any computer / mobile phone and you still need access to the stored data, then maybe it would come with a small LCD screen, like those RSA security key fobs - a small display that could use to access information. The whole thing need not be larger than a credit card, or a Zippo lighter. And it could also have a removable micro SD card that could contain a backup of all your info (encrypted of course) so that you would not suffer a complete data loss if you lost the physical device.

That is in my opinion the best solution. (1) accessible anywhere with or without PC and Internet access (2) data stored completely locally with no third parties anywhere to pose a security risk and dependence.

Another approach is email. Most of us have yahoo or google emails or some other online email. And we have thousands of emails stored on the yahoo servers which contain tons of personal information, including addresses, phone numbers, account details and even passwords. This right there is a huge repository of personal information, it is online, it is available on anyone's PC through a simple browser, even on your smartphone. And for the most sensitive data you could devise a personal method of encryption so although the email is clear text, the data is encrypted somehow, only known to you.

Answer 9

I've found the OSX Keychain an ideal place to keep passwords and related info. Even more so with the new IOS & iCloud integration. For me it is an acceptable balance of convenience, availability and safety.

I do wish Apple was more transparent on the inner workings so I wouldn't have to base my evaluations completely on third-party reverse engineering; but then again, I'd feel the same way if the only info available was from Apple as well.

Answer 10

I think there are easier methods of hacking your passwords than to try to breach LastPass's encryption. For example keyboard logging. If you really think that your credentials are in danger or being hacked, you should use a clean linux computer. Choose a really hard password (24 characters?).