Critical Vulnerabilities In Web-Based Password Managers Found

An anonymous reader writes A group of researchers from University of California, Berkeley, have analyzed five popular web-based password managers and have discovered vulnerabilities that could allow attackers to learn a user's credentials for arbitrary websites. The five password managers they analyzed are LastPass, RoboForm, My1Login, PasswordBox and NeedMyPassword. "Of the five vendors whose products were tested, only the last one (NeedMyPassword) didn't respond when they contacted them and responsibly shared their findings. The other four have fixed the vulnerabilities within days after disclosure. 'Since our analysis was manual, it is possible that other vulnerabilities lie undiscovered,' they pointed out. They also announced that they will be working on a tool that automatizes the process of identifying vulnerabilities, as well as on developing a 'principled, secure-by-construction password manager.'"

Comments

KeePass?

[Electricity Likes Me]

I'd be really curious to here there opinions on KeePass, which isn't web-based but certainly in the same category.

Re:KeePass?

[mlts]

I'd probably say KeePass is as secure as things get, since it doesn't use the Web in any way, shape, or form.

What I'd like to see with password apps that use a cloud provider for backend storage, (be it 1Password, mSecure, or so on), would be a keyfile that is manually transferred between devices, and never is put on the cloud backend. This way, if/when the cloud provider is hacked, the password file is not just protected by the passphrase, but by a keyfile that an attacker would have to compromise a physical device to get.

Re:KeePass?

[mlts]

Hate responding to my own posts, but adding another idea... Each endpoint device has its own private key... so the data that is stored on the backend cloud provider would be conventionally encrypted, but would be unlockable by any key in the access list, similar to a PGP attachment that lists multiple public keys. That way, one can add and remove devices by using their key, and no common file needs to be shared.

Re:KeePass?

[Anonymous Coward]

I e-mail myself my passwords with the site name in the subject line and the password in the body of the e-mail. It works really well for sites I forgot the password for, and it's 100% safe as Google uses HTTPS by default now.

Re:KeePass?

[allquixotic]

I have a YubiKey NEO that works perfectly with LastPass, both on desktop systems via USB, and on my mobile device via NFC. The key has internal non-volatile storage but no battery; when it's plugged in and used, it atomically reads from storage; uses the input from storage as a salt to generate a unique one-time password (a long ASCII string); transmits the password to the host device; then updates the non-volatile storage with some magic to ensure that the next one-time password is unique, unguessable and cryptographically secure.

An attacker would need my LastPass password (which is not, itself, stored in my LastPass vault); my physical YubiKey; and the knowledge to use both in tandem, in order to gain access to my LastPass account.

Re:KeePass?

[itsownreward]

I have KeePass installed on my computers and KeyPassDroid on my phone and tablet. The file is shared between them all using Dropbox. This way, if I change it one place it's available at all the others automagically, and in case it gets corrupted I have a 30-day history of changes at Dropbox's site. I've had no problems, I like its built-in and configurable password generator, and it works a treat with the KeeFox plugin for Firefox.

(YMMV in that you may have issues with Dropbox, but for me, it works.)

Re:KeePass?

[Anonymous Coward]

The "magic to ensure that the next one-time password is unique" is a counter, an integer one higher than the previous time.

The checksum of (counter + internal private key) is what results in the final 32 chars of the sequence (the first 12 being your userid).

Re:KeePass?

[Mister Liberty]

Which in Dutch --translated for the occasion to English-- would mean 'Ouch! Tom Ate Ice".

Re:KeePass?

[Jesus_666]

You can always try KeePassX (for Linux and OS X; use the latest 2.0 Alpha release) and MacPass (for OS X), both of which are compatible with the KeePass 2.x database format. They might not have all the features but they work rather well and you don't have to deal with the monstrosity that is KeePass on a non-Windows system.

Re:KeePass?

[znrt]

I'd be really curious to here there opinions on KeePass, which isn't web-based but certainly in the same category.

i've always had trouble with putting all my apples in the same basket, so i never touched things like keepass, kisskiss nor any other keyring. that there's folks doing that *OVER THE WEB* is staggering. if i weren't speechles right now i'd say they deserve being raped in their most intimate identity.

Re:KeePass?

[Dutch Gun]

You're telling us not to trust a web based service, but then tell us you keep your data shared like google drive or dropbox? I see no appreciable difference in practice there. Lastpass is essentially Keepass + a specialized dropbox-type service. Your advice is especially ironic given the spotty security dropbox is known for.

At some point, you have to make informed decisions about the tradeoffs between security and convenience. For me, using Lastpass is a convenient way to synchronize the strongest possible unique passwords - essentially gibberish - across my multiple computers. I feel that having strong, unique passwords across the web is critical to keeping my numerous accounts secure.

This is exactly how security is supposed to work - a researcher discovers a potential flaw, discloses it to the vulnerable companies, who then promptly fix it and discloses this fact in detail to it's customers. The system is arguably more secure than before, not less.

Incidentally, as it turns out, this attack is apparently only applicable to those not using a browser plugin. That's not to discount the seriousness, but I was never actually vulnerable to this attack, since I only use Lastpass from my PC using Firefox + Lastpass plugin.

Re: KeePass?

[lhunath]

That is very dangerous: when the master password is trivial to reverse from the site password, an attacker could easily set up a hoax site, get your site password and reverse your master key. Master Password above uses a hmac-sha-256 of a 64 byte master key which is something you can't just reverse. It also uses an expensive scrypt based salted key derivation to get that key from your master password, which is also something you can't reverse.

Surprise

[pmontra]

The web in insecure, don't store passwords in the web. Use keepassx instead. You get it for Windows and OS X on the site, for Linux using package managers, for Android on the Play Store and maybe also for iOS (look for MiniKeePass).

Re:Surprise

[jsherma2]

I think there's a difference between "being willing to accept the risk of my credit card(s) being compromised on the internet" and "being willing to accept the risk of every account password I have being compromised on the internet". I essentially have insurance to help me recover losses from my credit cards. Having every bank account and retirement account drained by an enterprising criminal with access to all of my account and personal details is on a completely different risk level.

Re:Surprise

[mlts]

Done right, storing passwords on the web can be decently secure, especially if there is some part of the decryption key (be it a public key, a secondary authenticator, or a keyfile) that is not available to the attacker, in combination with the master passphrase.

I'd say the best implementation of this would be a utility that piggybacked on the cloud provider of choice, so one isn't limited to GDrive, Dropbox, Box, Skydrive, iCloud, or others. The utility would ask for permission just for its own directory (if possible), and would store its main DB file, as well as some backups in that directory. That way, the password program author or company doesn't have to maintain a cloud infrastructure.

Re:Surprise

[allquixotic]

I think there's a difference between "being willing to accept the risk of my credit card(s) being compromised on the internet" and "being willing to accept the risk of every account password I have being compromised on the internet". I essentially have insurance to help me recover losses from my credit cards. Having every bank account and retirement account drained by an enterprising criminal with access to all of my account and personal details is on a completely different risk level.

Let's assume for the moment that you're correct and that there is a difference in risk level between submitting your name, address, email, credit card number, CVV2 (these are the fields required for a standard online order form), and storing all your passwords on the Internet.

Let's assume someone actually does intercept your order form, and gets all the above-mentioned personal data on you (perhaps because the company processing your order stored all your order info in an unprotected SQL database). Many people acknowledge that, with this amount of personal information, a lot of damage can be done, starting with identity theft. Yes, there are many protections on credit cards, but other personal details can be used as leverage to get access to even more details. This is starting to look like more than simple credit card theft.

Also, if you're not storing your passwords on some website, where ARE you storing them? If you don't store any passwords anywhere, chances are you don't have a perfect, long-term eidetic memory, so you probably use the same password everywhere. That's just as risky, if not riskier, than using LastPass -- if an attacker compromises just one of the sites you use, they can try that password on random sites across the web and gain access to a slew of your accounts.

Let's be a bit more charitable and assume you use completely different passwords on different sites. OK, now we're getting serious. You are going to need somewhere to store all these passwords -- that's the simple reality of it. Only the extremely rare individual can remember them all in their head. So what do you use? A paper card file? That's great, unless you invite a guest in your house who may not prove 100% trustworthy, like an A/C repairman... Or if you happen to live in a dangerous part of the world where house robberies are common, a password card file would definitely be something a thief would want to steal. Or you could just get really unlucky, even in a low-crime area, and get robbed anyway. The same logic as the card file effectively applies to such things as KeePassX, since an unhindered thief can take your laptop, phone, or whatever you use to store your KeePass database on. Once they have your device, you're basically owned. Remember, we have to be fair here; you're assuming the thief is smart enough to break the security model of a business that builds its entire reputation around security, like LastPass, so we have to also assume the thief is smart enough to break the security model on your physical box, whatever it may be. Most people are not going to employ physical or digital countermeasures that are sufficient to keep very sophisticated thieves from breaking into your box once they have physical access. Full disk encryption is still quite the rare thing, and brute forcing a typical-length KeePass password isn't all that hard anymore with GPGPU or an EC2 compute cluster once you've obtained the database file.

Now, since LastPass supports two-factor authentication via various physical methods, such as the YubiKey, simply obtaining your LastPass password will not be sufficient for them to gain access. They'll also have to be a sophisticated thief, which brings us back to square one, where LastPass and KeePass are about equal on security: you'd have to get robbed, and the thief would have to steal the correct things, then break into them in order to gain access. I concede that users of LastPass or similar services who opt out of two-factor authentication are taking a greater risk,

Re:Surprise

[Anonymous Coward]

The web in insecure, don't store passwords in the web. Use keepassx instead. You get it for Windows and OS X on the site, for Linux using package managers, for Android on the Play Store and maybe also for iOS (look for MiniKeePass).

I don't subscribe to this absolutist position. Web based password managers like Lastpass certainly have their uses and are extremely convenient when tons of forums and websites require you to have accounts. They make it easy to login effortlessly and across multiple computers. They are also safer in that they let you have unique passwords for every account.

That being said, the smart thing to do is to:

1) Not save any bank account / Money related passwords on a web based password manager. Heck, I wouldn't even trust my own computer. I store these strictly in my head

2) Enable 2-factor authentication on any website that if compromised, could allow the attacker to steal your identity and cause more mischief. Gmail would be a prime example of such a website.

This strikes a good balance of letting me have the convenience of online password managers for non-critical sites, and even some critical ones that support 2-factor authentication.

Re:Surprise

[Anonymous Coward]

Your entire argument is based on a false premise.

Food For Thought - It is easy to develop a simple algorithm to remember passwords and thus remember different passwords to any website. Essentially, unless you are being tortured, no one will be able to know your algorithm for setting passwords (you store the algorithm in your head). Your algorithm may appear "weak" if someone knew it but no one has to know it (i.e. you could use the first 5 letters in the web address to seed your algorithm).

Re:Surprise

[DMUTPeregrine]

The problem is that you can't hide things from the service provider with nothing but a browser. You need an addon or such to do secure crypto. You need to decrypt the password database locally, in-browser, and without an addon that means using JS crypto, which isn't ideal. Your mailing example is very different, since it doesn't matter if the service provider knows the address and financials, they're the intended recipient of the info! With a password manager, you don't want the service to be able to learn the contents of the encrypted database. That means the encryption/decryption must be done client-side.

That said, it's perfectly possible to store the encrypted database on the internet. A local encryption/decryption program (like Keepass) works just fine, and if combined with a cloud storage client that also does local encryption/decryption (Wuala, Spideroak, etc) it should be quite secure.

For that reason...

[Parker Lewis]

To avoid remember all the password managers, we need a password manager manager.

Re:For that reason...

[PPalmgren]

Passwords all the way down

Storing cloud passwords in the cloud?

[QuietLagoon]

Even if the cloud-based password repositories are secure (and apparently, they are not), why not just target the cloud services themselves for security exploits?

.
Eliminate the middle-man, go wholesale.

Re:Storing cloud passwords in the cloud?

[Enry]

In the case of LastPass at least, the passwords are encrypted locally and then sent to the server for storing. Your only possibility there would be searching through and finding stores with weak passwords, or finding a crack in the encryption. Otherwise, the attacks have to take place on the end user side.

Re:Storing cloud passwords in the cloud?

[mlts]

The problem is that there is an conflict between a password suitable enough for protection (i.e. 20+ characters), and something quick enough to access in a short time.

mSecure addresses this in an interesting way -- they cache the extra long sync password used for the cloud. The password that is used to encrypt the synchronized database that sits in iCloud or DropBox is different from the app's passphrase. Since most phones have decent innate protection, it is not impossible, but very difficult to dump the data on a locked device [1], so one can have a fairly easy to type in PIN on the device, but the synchronized backend file is protected with a much longer (and more secure) passphrase.

[1]: iOS on the iPhone 4 and up always encrypts. Android since 3.x has the option of using md-crypt and encrypting the /data partition, then using another tool to separate the password asked on boot to decrypt that partition from the screen locker password.

TL;DR - (from a security guy)

[xxxJonBoyxxx]

From page 7 of the paper (http://devd.me/papers/pwdmgr-usenix14.pdf):
- LastPass, RoboForm and My1login all had "bookmarklet" vulnerabilities (used if you share passwords across the web - shudder)
- LastPass, Roboform and NeedMyPassword all had "web" vulnerabilities
- My1login and PasswordBox both had "authorization" vulnerabilities
- LastPass and RoboForm both had "UI" vulnerabilities

The other thing I wondered at was why the special mention of "creating tools to automatically identify such vulnerabilities" when there's a bunch of packages that already do that...until I looked on page 14 and saw the list of US government grants that sponsored this paper, plus mention of some Intel funding. (If you want the money to flow, first identify the problem...)

Slightly misleading, fearmongery headline

[myvirtualid]

This was on HN a few days ago; my comment there was the same: In the case of LastPass, the headline is misleading and a little fearmongery.

There were two issues with LastPass and NEITHER affected its storage of persistent passwords, that is, neither affected the feature the vast majority of us use passwords managers for!

One concerned a targeted attack against one-time passwords (OTP), the other concerned bookmarklets, which are used by less than 1% of the user base, according to LastPass. Personally I didn't know either feature existed until I read the LastPass blog entry about these two vulnerabilities.

A truer headline would have been Vulnerabilities found in less-frequently used features of LastPass; persistent site password storage unaffected".

They had one job

[Animats]

A "web based password manager" has one job - keeping the passwords secure. That's all it does. If anyone easily finds a vulnerability in that, the service is a failure.

brainpower

[clam666]

I just remember my passwords. As if someone else storing them is possibly safe.

Re:brainpower

[steelfood]

I use bash.org to store my passwords.