Sure, we'll hold on to your passwords for ya

April 6, 2010 9:19 AM

LastPass, the password storage service, says that all encryption occurs on my computer, so that the only way to see the passwords is with my encryption key. Is there a way for someone to prove this, or do we have to take them at their word? If it's the latter, does the incentive for LastPass to tell the truth outweigh the incentive for the alternative?

Not that I find the service particularly suspect, I was just wondering if it were easy or at least possible for someone to just claim host-proof hosting.

And if the answer is no, then a secondary question would be, why don't google and banks do this?

posted by Busoni to technology (12 answers total)

Computing pioneer Ken Thompson, in his Turing Award lecture Reflections on Trusting Trust, said that there's no way to truly verify that a program doesn't do something evil, unless you're written the code yourself, and compiled that code on a compiler you've also written yourself.

In the end, you're almost always taking someone at their word, although I would also believe that the incentive for Last Pass to tell the truth is outweighed by the commercial value to the underground of the information they're protecting.
posted by deadmessenger at 9:32 AM on April 6, 2010 [1 favorite]

On your first question, you can monitor outgoing traffic and verify that what passes down the wire looks like an encrypted password, and try to decrypt it to verify they have done a good job on the encryption.

Of course, they still be doing sneaky stuff, like adding a backdoor to the encryption algorithm: If you don't have the source for the program running on your computer, you have to take their word for this. If you can look at the source, you could theoretically verify it does what it says on the tin, but this is not as easy as it sounds.

On your second question, this is how most non-bozo cryptography works these days: read up on private key encryption to get an idea of how this kind of stuff works.
posted by Dr Dracator at 9:33 AM on April 6, 2010

If they encrypt your passwords in your browser using java or javascript (likely) then a man-in-the-middle attack could break their system. Yes, banks are similarly vulnerable but a common point of failure would make you much more vulnerable. Just never give your bank passwords away period.

Afaik, all modern browsers like firefox, chrome, safari, etc. all have password storage systems that avoid storing critical passwords like banks. I'd say lastpass would be useful only if you login from numerous terminals, but surely then you'll use only very few sites, maybe just gmail and facebook or twittr.

You should use shard password tools like bugmenot for sites that have no business asking for passwords, ala newspapers.
posted by jeffburdges at 9:34 AM on April 6, 2010

From the LastPass FAQ:

Whenever you setup/edit/add sites/notes your sensitive data is encrypted locally on your computer then the data is sent to LastPass. When you go to a cyber-cafe or a new computer and login, first a hash is made locally to check if your account exists and your password is correct. If it is, then your data is downloaded and decrypted on the local computer you're using; this includes LastPass.com where it's done using JavaScript (that's why there is a delay when you first login).

And they suggest links to network monitoring tools so you can verify the security yourself:

The vast majority of the data is encrypted, then sent over SSL, but if you want to satisfy your curiosity about what goes over https you might want to try Fiddler2 for IE, and Tamper Data for Firefox.

More details are available on that page, including info on your private key, which is actually a hash generated in realtime (on the client side) from your password when you enter it. Your password itself is never sent to LastPass and they have a policy to never ask for it. That seems pretty legit to me. It's actually a smart idea and I'm not sure why banks aren't doing it. Maybe they just haven't thought of it yet.
posted by The Winsome Parker Lewis at 9:40 AM on April 6, 2010

And if the answer is no, then a secondary question would be, why don't google and banks do this?

I don't have much insight into whether Last Pass is really secure or not, but the reason why their scheme works for them and not banks or Google is that for Last Pass your data is a black box. Although Last Pass will apparently store your encrypted passwords (so that you can access them from anywhere, presumably), they claim that there is no way for them to decrypt those passwords without your master password. So they are storing your information, but they don't have any reason to look at your passwords, so all of the decryption can be done on your side. For banks, they already have all of the information they are showing you, so there's not really anything you can be keeping secret from them. For Google, they want to be able to scan your email for AdWords and whatnot, and most people don't care if Google stores their data in plaintext. For online stores, they need to be able to read your credit card information so that they can charge your account.
posted by burnmp3s at 9:42 AM on April 6, 2010

I have never used LastPass. From skimming their Web page, it looks like they encrypt your passwords using a client side script before sending them to their servers. I've ssen this kind of scheme before and there are some inherent problems with it:

• LastPass has access to the encrypted passwords, and can attempt to brute-force the key. You can check every 8-character string in a couple of days on a modern computer, so this is a major concern.
• LastPass sends a new copy of the client-side script every time you visit their site. They could alter the script one day to, say, send an unencrypted copy of your password to themselves.
• If they're doing things right, the LastPass app itself should have two passwords: one that tells their server to give your computer the encrypted data, and one that is the key for the encryption algorithm. But that wouldn't be a "single password," would it? It's conceivable that their server will give out any user's encrypted data to anyone who asks. Which would mean anyone could be giving passwords to anyone who asks. Oops.

The software doesn't appear to be open source, so while we could check that the client side code does what it's supposed to, there's no way to know if the server does what it's supposed to too.

As for why other people don't do this: 1) it's inconvenient (Gmail couldn't search your messages if they were encrypted) and 2) it brings up a lot of legal problems. A startup callend Hushmail tried offering encrypted e-mail back around 2000, but at one point they were ordered to hack into a customer's account to comply with a subpoena. News got out and the company more or less died.

I'm all for outsourcing when it makes sense, but it seems extremely risky to outsource. password storage if you care about secuirty at all.
posted by miyabo at 9:52 AM on April 6, 2010 [2 favorites]

point 3 above: if the server gives out your encrypted data to anyone who asks, then anyone could brute force passwords. Hopefully they're not that dumb.
posted by miyabo at 9:55 AM on April 6, 2010

miyabo: The FAQ I linked to earlier does mention that multiple failed login attempts from one IP will trigger five-minute lockouts. So they are authenticating on their end. But yeah, if that's the case, I'm not sure how they could be truly secure unless you had a second password for decryption. I didn't get the impression from the FAQ that was the case, either. I don't use the service personally, so anything beyond what I can see on that page is pure speculation.
posted by The Winsome Parker Lewis at 10:09 AM on April 6, 2010

"Prove" is a strong word. Formal verification methods could prove that their software does what it says (with some practical caveats, like a finite limit on password length and bounded runtime), but this is really only theoretical; in practice, it is not currently possible to verify a program of this size and complexity. And even if the program is correct, the encryption algorithm is going to be based on cryptographic assumptions that are generally believed but nobody has yet been able to prove.

Security researchers could poke at their software and say on good authority if anything looks fishy, but this does not constitute a proof; it just means that any malfeasance is cleverly concealed.

But it's far more likely that any security holes are the result of bugs rather than deceit. For instance, maybe they're using an inadequate random number generator, making the encryption weaker than it should be.
posted by qxntpqbbbqxl at 10:14 AM on April 6, 2010

You can check every 8-character string in a couple of days on a modern computer, so this is a major concern.

I dispute this claim. Assuming you choose characters from the ASCII subset [upper+lower+digit+punct] that's a keyspace of 94^8 or about 6.1e15. This page lists the key and IV setup time for AES/CBC-256 as 0.619us. That's for a rather old Core2 1.83 GHz chip so let's be generous and say that modern machines are about four times faster or 0.150us. Lets also assume the setup time dominates the actual decryption time. The average time to brute force then becomes 0.5 * 6.1e15 * 0.150e-6 = 4.6e8 seconds = 5295 days = 14.5 years.
posted by Rhomboid at 11:16 AM on April 6, 2010 [1 favorite]

Rhomboid,
I did this math recently for a friend recently, I guess with some different assumptions. I assumed a keyspace of 62^8=10^14, I assumed we were just doing MD5 sums, and I assumed better hardware like an nVidia Tesla running Elcomsoft Password Cracker. You're right that AES setup takes far longer than doing a checksum -- from the linked page, around 10^5 times longer.
posted by miyabo at 2:03 PM on April 6, 2010

While hashing is indeed faster (not to mention the possibility of employing rainbow tables) in that case you also have to compensate for the fact that any competent hashed password storage system is going to incorporate salting which greatly magnifies the amount of necessary work, so I still dispute the couple of days claim even for password hashes. (From some googling it appears that NTLM does no salting so I guess that would not qualify as competent.)
posted by Rhomboid at 2:55 PM on April 6, 2010