LastPass and the Heartbleed Bug | Hacker News Reader

LastPass and the Heartbleed Bug

blog.lastpass.com

104 pointsmjhoy76 comments

I don't understand how anyone can throw last pass under the bus here.

0day where an unbelievable amount of sites are affected. last pass comes out and says we were vulnerable and we fixed it and provides information as to what it means for your data... I wish everyone did that...

edit: A lot of people recommend keepass. keepass is vulnerable to the same thing everyone else is worried last pass was vulnerable to. kee pass' download site is HTTP. You could be getting trojaned binaries and incorrect shasums if you download it from ANYWHERE.

I installed keepassx through my distro's package manager.

Where do you think they got the package from?

Compiled from source.

To be fair, not where you think he got it from (it seems). For example, in Ubuntu you download all packages over plain HTTP. Worried yet? Don't be. Let me tell you why:

A Debian repository (a repository of .deb packages) is a directory containing *.deb files, a list of packages in a file called Packages and a description of the repository in a file called Release. Every package listed in Packages includes the filename, the name and version of the package, and several checksums of the file (typically MD5sum, SHA1, SHA256, and SHA512). Thus if you trust Packages you can verify the integrity of the .deb file.

Why should you trust the Packages file? Well, it's checksums are listed in the Release file.

Why should you trust the Release file? Because there is a signature of it available in Release.gpg file. The signature is created by the distribution maintainers.

How can you trust this signature? Because your initial installation ISO, etc. came with the public key of the distribution maintainers which APT uses to verify all the packages. How can you trust the ISO you used to install it? Because presumably you verified the checksums of it when you downloaded it, and you obtained those checksums over a secure channel at the time of the installation.

I'm aware how you download packages but I don't know how Ubuntu actually gets the packages it will be distributing.

How do we know Ubuntu isn't distributing a trojan'ed version of keepass?, is what I'm saying. If keepass doesn't have a secure mechanism for distribution then how can you be sure Ubuntu got the correct copy?

If I was an attacker able to get packages in Ubuntu compromised I wouldn't be going after KeePass. I would go after a browser, a random utility normally run by root, or the kernel itself. If Ubuntu is giving you poisoned packages, you are hosed. Game over, no security.

You "know" that Ubuntu is not distributing rogue packages because the author of the package and the Debian package maintainer are different people. Presumably the Debian package maintainer peer-reviews the code they are including in the distro for security issues, and puts their name and reputation on the line (hence the Debian maintainers' signatures on the distro itself).

What you are really asking is "how can I trust code written by other people". You cannot. If you are taking the paranoia to this level, then don't use computers at all. We do not have a system in place for not trusting the OS, or the hardware. You must put a line in the sand somewhere and say "I trust these people". Otherwise, you cannot even trust your `cat` command to review the source code of the software you want to trust, and you'd have to spend more than your lifetime reviewing every bit of code you are currently using to read HN in order to know for sure that it's secure (assuming you are able to spot all malicious, or just insecure code).

> What you are really asking is "how can I trust code written by other people". You cannot.

That's not his point. The concern is that without a secure channel of distribution from the author, Ubuntu can be MITM'ed into packaging a tampered binary.

Ubuntu absolutely can be MITM'ed. So can you when downloading the source code. Moreover, you don't have to MITM attack Ubuntu (or rather Debian) into downloading a compromised version of the KeePass source. You could MITM attack anything the Ubuntu/Debian developers download, whether it be the source code to stuff that's going into Debian/Ubuntu as a package or something they are installing on their machines. I repeat, at some point you have to trust someone, otherwise all software and hardware is suspect.

Now, the really big question to ask here is what processes do we have in place for this not to happen. Downloading stuff over HTTPS is clearly not good enough: there are many ways someone willing to compromise a distro can circumvent it (including forcing a CA to give out a rouge certificate, or simply threatening the individual software developer into accepting a malicious patch). The best I can think of is using the PGP/GPG web of trust. When Debian Maintainer Dave gets an updated version of the source for package foo from Programmer Pete, Dave can verify that Pete actually authored the code by making sure the source is properly signed with Pete's GPG key. Dave knows Pete's public key having properly exchanged keys with him in person. I think that's the best we can do.

Mind you in the above we cannot guarantee that Pete does not turn to the dark side, either willingly or forced into it by a powerful adversary (NSA, drug cartels, etc.) The best we can do is that Dave is not also turned to the dark side and that Dave carefully reads and catches any security issues with the code Pete delivers to him. This is what keeps your distro safe, nothing else, so buy a maintainer a beer next time you meet one.

Distributions like Ubuntu are not picking up and distributing random packages from the Internet. Usually it's either the software author that does the packaging by himself, or a package maintainer that has a direct relationship with the software author.

Encryption/signing is only for proving that the source is who it claims it is. It doesn't mean that you can trust the software itself. Towards that end you've got source-code. Ubuntu's software packages are built from source and you can inspect it - yes it may not be feasible, leaks may escape even trained eyes and so on and so forth, but the source-code is there available for inspection and nothing short of a source-code review can prove that the software does what it claims.

That is assuming you can trust your tools, OS, and hardware to show you the real source code :). How do you know that your editor or your compiler are not messing with you? But yes, you are correct.

BTW, in the case of Debian, software authors are discouraged to package the software themselves and instead are encouraged to work with maintainers instead. I see this as a net win as there is at lest one more pair of eyes on the software before it ends up on my machines.

The only point I'm making, and I hope the other guy reads this as well, is that keepass isn't as bullet proof as people act it is when criticizing last pass. It has its problems, just like last pass. I was simply playing devil's advocate.

It's very much the "Oh I don't get viruses I have a Mac" argument that I've heard a lot of non-computer people say. This is undeniable because I'm sure many windows keepass users go to the site every download.

OK. I guess for me it sounded like you were saying the big problem is with the actual download of the software, not with the software itself. That's two different beasts that need to be attacked very differently.

Distributions are signing distributed packages with trusted keys by PGP. PGP signing is a fairly standard mechanism by which somebody can prove that he packaged that software.

The interesting bit is ... if a web of trust can be established, this is far, far more secure than distributing binaries by HTTPS. That's because the private keys with which those packages get signed DO NOT have to be distributed or installed on any public servers on this internet and thus this mechanism is invulnerable to exploits such as Heartbleed. And in the case of Linux distributions, this web of trust can easily be established, because the package maintainers and software authors know each other.

In the right context, the web of trust model can be much more secure than SSL/TLS, because SSL/TLS requires X.509 certificates that have to be issued by a central authority - and we'll always have problems with central authorities that go rogue or have their root keys stolen. And you can't rely on the central authority model if you want protection against the NSA. Too bad that PGP signing/encryption isn't too popular, since the web of trust model only works if there are enough people vetting for each other. But for Linux distributions it works just fine ;-)

Here, read more about it: https://en.wikipedia.org/wiki/Pretty_Good_Privacy

Moreover, unlike HTTPS/X.509 you don't have a problem where another CA can just issue a certificate in your name. That is, if you hold a private key for a cert for .example.com from VeriSign, Comodo can issue someone else a valid certificate for .example.com and your users would not know the difference.

With PGP/GPG there is no CA: you create a private/public key pair and initially nobody trusts it. But by exchanging and signing keys through the extremely laborious process of verifying identities you actually establish trust for your specific key, thus making this system much more robust.

Well, that's rather unfair to keepass. Presumably you can install keepass the same way you install your browser. If the browser is backdoored you're hosed anyway. In fact, if any process is backdoored you likely hosed.

Not understanding some of the responses, I think they did a pretty nice job trying to address the issues in their posts. Of course you could have been MITM but the vast majority of that danger comes from using public wifi and if you're smart you should be using a VPN provider anyway.

Realistically speaking here they found out about this at the same time as everyone else did and addressed it pretty quickly and professionally. Is there really anything else they or anyone else could have done, other then just use KeePass? Which has it's own major inconveniences that can only be addressed by some sort of cloud based solution (whether controlled by you or someone else), which probably would very likely have been using OpenSSL as well ...

Any VPN provider that you can recommend?

I use privateinternetaccess, good reference comparisons:

http://lifehacker.com/5935863/five-best-vpn-service-provider...

https://torrentfreak.com/which-vpn-services-take-your-anonym...

Great, thanks a lot for the links.

Most VPN providers offer openvpn which uses openssl and thus is vulnerable as well.

yup, good point. A good provider should have multiple protocol options but most people would use the default, something definitely to look into changing from the norm. i.e. if a lot of sites use OpenSSL for https then for your VPN you should probably use a different protocol, so no single vulnerability in either would screw you over.

Agreed that cloud services may be using OpenSSL to transfer the KeePass database to/from the client. Presume an attacker obtains the KeePass database via a MITM attack on communications to/from this cloud service. Then what?

The attacker needs to penetrate the defenses of the KeePass database itself, so I'm unsure of the point you're trying to make with KeePass and cloud services.

I don't get it. If someone capture the SSL cert, they could be MITMing the server. Which means they could be serving poisoned JavaScript code to everyone who was using the website or the bookmarklets, code that could send the master password to the attacker's servers.

How is this not vulnerable?

EDIT: and more, what guarantees can they offer that the plugins downloaded from their site ever since their were vulnerable are not themselves trojanized? OpenSSL has been vulnerable since March 2012, how many downloads did they have since then?

I'm unclear on what you mean by "MITM... serving Javascript to EVERYONE". In a typical MITM scenario, you've logged into your coffee shop with an insecure network, or you are in some Middle Eastern country where all traffic is under control of the government.

Unless you are somehow able to route all traffic through your network, you cannot MITM "everyone", no matter even you have the private certificate for lastpass.com.

Of course you can -- for example, if you are NSA and in position to apply pressure to whoever hosts lastpass SSL frontends.

If you're the NSA, you can probably get a CA to sign a cert for you, no need to steal theirs.

But MITM can still affect a lot of people if the attacker can get into a big gateway (e.g. large company, ISP, university, etc).

> If you're the NSA, you can probably get a CA to sign a cert for you, no need to steal theirs.

That would leave a trace (at least the person issuing the cert would know) while heartbleed doesn't.

Yes, I'd say most MITM scenarios are at the client end.

But you could, for example, be an evil network admin near the LastPass servers. That would let you MITM almost everyone who connects.

You don't get very much by MITM of LastPass compared to other targets -- the extensions aren't going to pull down Javascript, the update process only uses signed binaries... You might be able to put people utilizing LastPass.com to login which we don't recommend and isn't done by the vast majority of people.

The vast majority of people haven't logged in to LastPass.com in the last two years, since OpenSSL has been vulnerable?

(Frequency of LastPass.com login via web page on insecure network) * ( odds of MITM attack on that network) = scary low odds

Everyone who they were MITMing. I thought that was implied in the context.

Extensions/Downloads are all cryptographically signed -- I'd hope if you're installing password management software like this that you see that it's unsigned or signed by someone other than LastPass.

Using the extensions to login -- it doesn't matter nearly as much if you're MITM as it would if the website was MITM and you login from the website -- what's in the middle is mostly useful only to do things like mess with you -- delete your sites / DOS your account, but in no way exposes your encrypted data.

The combination of extension use instead of going to the website, perfect forward security, data that's encrypted with a key that doesn't leave your devices, the fact that what you'd most likely leak is a session ID which will be replaced on your next login and that we haven't actually seen anyone utilize heartbleed to get a SSL key yet combine to make LastPass a tough target.

Given everything it'd be far easier to target all the banks and email clients that simply send your credentials right over the wire.

This is definitely a big problem and we're currently working on tools to try to help people recognize what's at risk and help them update it.

Also, LastPass has employed a feature called “perfect forward secrecy”. This ensures that when security keys are changed, past and future traffic also can’t be decrypted even when a particular security key is compromised.

I thought perfect forward secrecy simply gives you plausible deniability, or is that in the particular case of Off The Record messaging? How is it that a key I could have used yesterday to decrypt all the traffic I was capturing until yesterday suddely cannot be used to decrypt the same data, if none of it has changed in my vault?

No, they're using the term correctly. The plausible deniability in OTR comes as a result of forward security. Since past and future traffic can't be decrypted with a certain captured key, the entity that captures that key can't cryptographically tie an identity to the previous messages.

It goes futher than that in OTR. After the ephemeral keys are out of use, the public keys (used for encryption, not decryption) are broadcasted so if later someone gets an old encrypted message, it could "effectively" have be written by anyone.

Plausible deniability is when you have a hidden datastream inside another encrypted one, as there's no way to prove it is or isn't there without the key. See: TrueCrypt.

PFS means "If the server's private key is later compromised, it can't be used to decrypt past captured traffic".

LastPass puts vulnerable in scare quotes.

But to my understanding, with this bug session information to the website could have leaked, and they don't seem to address this. Could an attacker have hijacked logins?

No. Here is the explanation:

"However, LastPass is unique in that your data is also encrypted with a key that LastPass servers don’t have access to. Your sensitive data is never transmitted over SSL unencrypted - it’s already encrypted when it is transmitted, with a key LastPass never receives. While this bug is still very serious, it could not expose LastPass customers’ encrypted data due to our extra layers of protection. On the majority of the web, user data is not encrypted before being transmitted over SSL, hence the widespread concern."

This means "your passwords are safe, because they're encrypted with a key that only you have".

It still means people could have hijacked your session, which is what GP was referring to.

I don't use LastPass, but I speculate even if your data isn't vulnerable, people could use your ID/password to do malicious things (denial of service to your passwords being the first thought).

I thought that too, until they mentioned logins at the end. Perhaps you are right.

It would appear the session info would be compromised, but the login credentials would be protected.

hijacking your session with lastpass wouldn't do someone any good, as they still wouldn't have access to anything. All they could attempt to get back is encrypted data. Your encryption key is never available.

It seems some servers had some combination of nginx+openssl that caused the memory location being dumped to always be a recent HTTP request/response. Keep hitting that enough times and you'll get all sorts of goodies (session cookies, cleartext passwords).

This tweet shows someone getting credentials from Yahoo Mail: https://twitter.com/markloman/status/453502888447586304

I think any service who suspects they've been vulnerable should issue a forced password reset email to their users. Even if there's only an infinitesimal chance of credential disclosure, how can you be sure, and why not take precautions?

The issue I have with LastPass is that they claim to never see your master password. This is not true in any sense. Open their website, log in using your master pass. You just submitted it to them. As a secondary thing, pick a random password from the list and say "Show me the password"; it will ask you for your master password. The extension you install has nothing to do with this: you are entering the password directly into their web page and interacting with their JavaScript and their server-side code. At this point they have your master password.

I understand why they do this: it's convenient and lets you share/give passwords to others. But this feature is 100% incompatible with the claim that they never see your master password.

My understanding is that even with their web login process your password isn't sent to their servers in plaintext. From the comments on their heartbleed blog post: "We only use one-way salted hashes (after going through PBKDF2 rounds) to send to the server for authentication."

So their servers get a hashed version of your password, but not the password itself. Their servers likely also store a hashed version of your password so that they can authenticate you. This style of auth is also used when you use the "show me the password" feature.

This cannot be. Your passwords (the ones you are trying to protect) must be encrypted using your master password. LastPass needs to decrypt them somewhere using your master password. What you are describing is how their browser extension seems to work. However, their website does not require the extension to work. So either they implement security in JavaScript that's running within the page (cannot by definition be done securely), or they store all your passwords in a way that they can decrypt them (invalidates the use case for LastPass).

The passwords are decrypted locally on your machine using javascript not on the lastpass servers.

We implement everything in JavaScript on that page if you're trying to login from the website -- which is as secure as that page load -- LastPass recommends people utilize the extensions to mitigate this risk.

Our choice could be to not allow people to utilize the website but it seems like educating people of the risks and letting them decide is the best policy.

Very happy to get a reply from someone from LastPass!

So then what would prevent someone from using the Heartbleed attack to obtain your private key that use used to secure the HTTPS connection from me to your servers, then inject malicious JavaScript into the page where I enter my password? This is the attack I am worried about outside of Heartbleed as well, since any CA can issue a valid certificate for lastpass.com and I would not know that I am being MITM'ed.

From a strict security point of view, disabling website access seems like the best policy. From a usability standpoint, I understand the tradeoff you made. Perhaps an option at the account level that disabled website access might be a good idea.

Also, how are the share/give functions handled? I know what "share" is not really keeping my password from being seen by the other person (there are a variety of techniques they can use to get at it), but how is the encryption handled on your end?

Lastly, how do I know that the browser extension I download from you is secure? Is there a way for me to verify it somehow?

Having said all that, I absolutely love your product and recommend it to everyone I know. It's a huge net win in terms of security.

You are not submitting your master password to them. It's been a while since I completely understood the login process, but this should be mostly right:

1. The encryption key is a local hash of your email address and master password. This never leaves your computer.

2. Ignoring PBKDF2, Your encryption key and your master password are again hashed locally. That is sent with your login email to LastPass.

3. LastPass hashes Step 2 with a salt and that result is then used to authenticate you. After any additional two factor auth verification, LastPass will send your password file, which is decrypted using the result in Step 1, that has never left your computer.

You're more than welcome to inspect the JavaScript code yourself. They have a simple encryption, decryption page so you can see exactly what LastPass does.

https://lastpass.com/js/enc.php

Password managers can protect you from being "Hacked" in the manner of destroying all your Gmail, and can help prevent your computer from being enslaved by a botnet. And probably help protect your bank account and any online medical records.

But if the NSA or any competent government targets you as an individual, no password manager can help you. TrueCrypt might help, but even that has vulnerabilities.

This reminds me of the time when i downloaded the Lastpass iPhone app, synced it with my Macbook's Lastpass, opened the Lastpass iPhone app _for the first time_ and it uploaded all my data to icloud without asking for permission... #fail

It was about a year ago, and at the time the iphone app apparently defaulted to 'sync -> iCloud -> on'.

Don't worry, you're still storing secret information with a proprietary web service that you can't audit. You're safe!

The website and extensions are mostly JavaScript, so you can audit the code yourself if you wish. LastPass does use a proprietary plugin for some features, but they have a binary free version for most, if not all browsers.

Thank god I'm using Keepass I can put my head on the pillow comfortably.

Should have used KeePass. Even HTTPS isn't perfect, so uploading your data to a third party is a bad idea.

I've heard people say this before, but I'm a little confused by it. Do you only use one device? If not, how do you keep the PWs for your devices in sync without uploading your data somewhere?

I suppose you could carry it on a usb drive.

Don't know about the OP, but I use a combination of sneakernet and scp to keep keepassx up to date across machines.

I've been using Dropbox. Is that a bad idea?

I wouldn't necessarily say it's a bad idea, I'm just saying it's equivalent to using lastpass since it's a third party hosting your data. I think the usability of a third party syncing service is worth the potential risks.

The potential risks depend on the data, don't they?

Using my local network or USB. Aren't most if not all your devices using your network too? There is no need for your private data to leave your network when you want to sync!

How do you easily connect to your network from your phone?

I enable Wifi and let it login. Takes 3-5 seconds.

...just answered it for me. I scp it across intermittently, as I rarely actually use it on my phone.

KeePass by itself is not a replacement for Lastpass since it lacks (among other things) the ability to sync across devices or support mobile platforms.

i thought there's built in sync to ftp,webdav.. http://keepass.info/help/v2/sync.html , http://keepass.info/plugins.html#ioprotocolext adds sftp/ftps..

and an android app https://play.google.com/store/apps/details?id=com.android.ke...

...then be a hacker and implement it right, rather than wanting an all in one 'solution' that compromises security for the sake of not requiring thought.

Reply on news.ycombinator.com