Apr 8, 2014

LastPass and the Heartbleed Bug

With news breaking on Monday, April 7th that the Heartbleed bug causes a vulnerability in the OpenSSL cryptographic library, which is used by roughly two-thirds of all websites on the Internet, we want to update our community on how this bug may have impacted LastPass and clarify the actions we’re taking to protect our customers.

In summary, LastPass customers do not need to be concerned about their LastPass accounts. Though LastPass employs OpenSSL, we have multiple layers of encryption to protect our users and never have access to those encryption keys.

What is the Heartbleed Bug?

The Heartbleed bug is a vulnerability in the OpenSSL cryptographic library that allows stealing of information normally protected by the SSL/TLS encryption used to secure the Internet. OpenSSL is open-source software that is widely used to encrypt web communications. SSL/TLS is what normally provides secure and private communication over the Internet via websites, email, IM, and VPNs. According to CNET, an attacker can exploit Heartbleed to essentially “get copies of a server's digital keys then use that to impersonate servers or to decrypt communications from the past or potentially the future, too.”

Heartbleed is being taken so seriously because OpenSSL is widely used, essentially no servers locally encrypt their data the way LastPass does, and it’s been exploitable for some time.

How does it affect LastPass?

LastPass utilizes OpenSSL for HTTPS/TLS/SSL encryption and we were therefore “vulnerable” to this bug. For anyone who was using this tool: http://filippo.io/Heartbleed/#lastpass.com to check whether LastPass was vulnerable, it would have shown that we were vulnerable until this morning, when we restarted our servers after the patched OpenSSL software update.

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.

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.

Our next steps

This bug has been out there for a long time, so we have to assume our SSL keys could have been compromised. We requested a reissued certificate this morning, and plan to roll it out today, while we’ve already deployed the OpenSSL software update after restarting our servers this morning.

LastPass customers should not be affected by the certificate transition, we expect it to be seamless with no interruptions to service. 

Because other websites may not be encrypting data the way LastPass does, we recommend that LastPass users generate new passwords for their most critical sites (such as email, banking, and social networks) if those sites utilize Apache, Nginx or show as vulnerable to the Heartbleed bug. However, users should wait until their sites have replaced their certificates, with a start date after today (April 8th, 2014). For more information on replacing passwords with newly-generated ones, please see this article.

Thank you to our community for your vigilance, and we’ll provide further updates if there are any changes to the situation.

Update: April 8th, 4:46PM ET

We have built a tool to help LastPass users check whether other sites and services they use may have been affected by Heartbleed, you can check it out at: https://lastpass.com/heartbleed

The new SSL certificates for LastPass and Xmarks have been reissued as well.

Update: April 9th

LastPass now alerts you if the sites stored in your vault may be impacted by Heartbleed. See our new blog post for more details: http://blog.lastpass.com/2014/04/lastpass-now-checks-if-your-sites-are.html 

Update: April 10th, 2:29PM ET

Many users are still concerned about what the Heartbleed situation means for their LastPass master passwords. To further clarify, we do not see a need at this time for LastPass users to update their master passwords. That said, if you would prefer to, there is no harm in doing so. We continue to update our LastPass Security Check tool to provide you the latest information regarding impacted sites. Thanks to our community for the feedback and input.

347 comments:

  1. "we recommend that LastPass users generate new passwords for their most critical sites (such as email, banking, and social networks)"

    Does this include LastPass itself if we have logged in to the website? Presumably someone could have our key's passphrase?

    ReplyDelete
    Replies
    1. No, this does not include LastPass if you've logged in via the website. Your key's passphrase is not sent over the network, since encryption is done locally.

      Delete
    2. Does this include if you've logged in via https://lastpass.com/mobile/ ?

      Delete
    3. Yes, same principles apply there as well.

      Delete
    4. I was directed here via a support ticket about this issue. You people are terrific!

      Cheers!

      Delete
    5. I assume that recommendation is because even if LastPass kept your password for a given site safe, it might not have been safe once it was *used* on the website the password is for.

      Delete
    6. Enable your 2 factor authentication too!

      Delete
    7. Lastpass was vunerable? Who cares if my data wasn't affected. Their servers could have an *untraceable backdoor installed* now. (Heartbleed leaves NO traces behind!) I suggest they format new servers with new admin passwords and migrate the data to them! There really is no other way to be sure.

      Delete
    8. This is a vulnerability that gives people a view into 64K of random server memory, it's not an vulnerability that allows someone to access/backdoor our servers. We also utilize other levels of protections against that.

      Delete
    9. It does potentially leak your SSL private key though - I trust you regenerated your certificates.

      Delete
    10. Yes, we updated our certificates.

      Delete
    11. gizmodo commented on the threat as well

      http://gizmodo.com/the-simple-secruity-measure-that-couldve-stopped-heart-1561206622?utm_campaign=socialflow_gizmodo_twitter&utm_source=gizmodo_twitter&utm_medium=socialflow

      Delete
    12. JUST WHAT I expected from you - clear, accessible, timely and COMFORTING information! Thanks, and GLAD to be a Premium Customer for the crazy fee of $1 per month.

      Delete
    13. I'll agree with that - you are definitely on top of the task. Thank you for your mini-fireside chat here.

      Delete
    14. After I read about the exploit, LastPass Blog was my first stop. Was not dissapointed. Thanks for being such a great service.

      Delete
    15. This comment has been removed by the author.

      Delete
    16. How about adding a print option for this page along with the various sharing options?

      Delete
    17. Amazing service and technical expertise. That's why LastPass is worth every penny! Thanks guys.

      Delete
    18. If I have logged on the lastpass via the website at https://lastpass.com/?ac=1 are the credentials then passed to the server over SSL?

      I understand that when I logon via the browser addin works differently and does all the work locally. But does logging in via the above website work the same and do all the work locally, or does it pass the credentials over SSL.

      Delete
  2. You are the best - thanks for your extraordinary steps to protect your users' data. Total pros :)

    ReplyDelete
  3. Kevin, you are correct. Your LastPass vault is safe, but once you actually login to a site, that data could have been compromised, depending on the SSL implementation that particular site uses.

    Hopefully this vulnerability wasn't know by anyone until today, and we're all (mostly) safe.

    ReplyDelete
  4. Please clarify the part about how a passphrase is used. As I understand it, I load lastpass.com, then request the login page and a page with "Access Your Vault" comes up. This page asks for my credentials to pull the encrypted file from the server and decrypt it in my computer. Now the question is: I just sent my email:password through ssl to lastpass to pull that file or did lastpass recognnize me in some other way thus never risking my ssl cyphered passphrase? Because that's the same user:pass I'll use to decrypt the file right? Thanks for your help

    ReplyDelete
    Replies
    1. Thanks for reaching out. We never send the master password to the server - nor do we send the encryption key. We only use one-way salted hashes (after going through PBKDF2 rounds) to send to the server for authentication. One-way hashes means no one (including us) can take that password hash and get the original master password or key.

      Delete
    2. So here's a scenario:
      * An attacker who was fast or knew about the vulnerability could have gotten your private SSL key via Heartbeat.
      * Via an eavesdropping attack eg on a public wifi or a compromised home router they could have seen the hash of your password.
      * The attacker could use the hash of your password as input into a dictionary attack
      * In this case case (depending on their resources) you would be busted if you used a low grade password such as your birthday or a 6-letter word that's in the dictionary?

      Delete
    3. Erik, if i remember correctly, LastPass salts your password with your username, then hashes that, then they salt that with another random hash and then hashes that.
      SHA-256(SHA-256(password+username)+salt)
      and (at some or all points, not sure where) it goes through user-defined PBKDF2 rotations.

      Delete
    4. It's possible that they may have your plaintext credentials from memory.

      Delete
  5. Care to comment on this?

    https://twitter.com/raganwald/status/453558864214900736

    Claiming that MITM breach of LastPass.com with compromised SSL certificate that served poisoned JS to all web users.

    ReplyDelete
    Replies
    1. We tell our customers to prefer logging into the extensions -- and that's exactly what the vast majority of our users do -- even if somehow someone implemented a MITM proxy, they'd also need a potential victim to utilize the website to login rather than the extension -- the extensions themselves couldn't be replaced as those are all cryptographically signed.

      The extensions do not utilize javascript from the website, it's built into the extension.

      Delete
    2. Also, we recommend using multifactor authentication for added protection of your account.

      Delete
    3. OpenSSL has been vulnerable since March 2012, so everyone who logged into the website since then until today - even if they usually use the extensions - was at risk to have all their info stolen. Shouldn't you warn your customers about that?

      @Amber: and how would that have helped in this case?

      Delete
    4. @AP^2 - Let's quantify that risk -- you'd need to login to the LastPass website without utilizing the extensions, you'd need to have your network connection compromised as well, intercepting and proxying requests -- a sophisticated attack. That attacker would also need to have obtained the LastPass private key, we've seen no evidence of anyone doing this yet but we're being cautious and saying it's possible, they'd do all this on the hopes that you'd login to LastPass.com in the web browser instead of utilizing the extension -- this seems like a very low probability.

      Delete
    5. Hi Joe,

      First, thanks for all the information you are providing, and the quick turnaround.

      When changing settings, users are required to do this on the website, even if launched from the extension. This applies, e.g., to changing the master password. Can you describe the threat model and mitigations in this case (e.g. where the user is changing the master password)?

      Matthew Green and others have suggested that given how much this bug has cost companies that rely on OpenSSL, a far more prudent, responsible, and cost-effective approach for these companies would be to allocate resources - money or staff time - for the auditing and maintenance of OpenSSL. Is Lastpass willing to advocate for this and to lead by example?

      Delete
    6. @Anon, concerning your last point, I don't really feel an urge to tell LastPass to allocate many resources to OpenSSL, as I'd bet they are a fairly small company compared to something like Google (and I'm not interested in premium rates going up too much). I'd just say, leave it to some bigger company.

      And I'm sure LastPass has explained the information you are looking for in other places...I see people asking about the same things over and over.

      Delete
    7. Thanks, Lastpass, for all the info. I use the free LastPass iPad app as well as extensions. Does that make me any more vulnerable?

      Delete
    8. @Jeremy, LastPass has NOT explained that risk as far as I can see, they have primarily said using the extension is safer. So one can presume the risk was that an attacker with a privileged network position could do some or all of the following:

      -obtain the LastPass private SSL key
      -obtain the user's encrypted data file from the server
      -obtain details about the user's account settings
      -conduct a MITM attack and serve malicious javascript which then collects the user's master password

      Delete
    9. The point being, we all agree that using the extensions and apps is safer. However, given that these extensions and apps redirect the user to the website to change account settings (including master password changes), an attacker who could exploit Heartbleed to obtain LastPass's private SSL key and who occupied a privileged network position (wifi access point, workplace network, ISP, state actor, etc.) could obtain the encrypted data blob as well as the master password. That is an attack that Heartbleed exposes LastPass users to, even those who are scrupulous about using the extension rather than the website, that has not been clearly described.

      Delete
    10. No, it doesn't, because even though you're using a web page hosted by LastPass.com to change your settings and password, there's JavaScript running inside that web page that does all the encryption work _in your browser_. Your master password is _never transmitted over the network_. Even when you log into your account via the page hosted on LastPass.com, your master password _is not transmitted over the network_.

      Delete
    11. Um, no, because an attacker with the Private SSL key obtained by exploiting Heartbleed who occupies a privileged position on the network can serve malicious javascript via a MITM attack.

      Delete
    12. You're right, a MITM attack could serve malicious javascript to the browser.
      But, frankly, I think any actor with sufficient capabilities to execute such a MITM attack at scale would have been able to do so with or without the Heartbleed bug.
      Certainly, in repressive countries where all internet traffic that isn't VPN'd goes through proxy servers, the state actors running those proxy servers can easily do what you propose.
      And I think it may be somewhat naive not to suspect that, e.g., the NSA has the ability to get browser-trusted SSL certs for any company they need.
      It's true that the Heartbleed bug could have enabled an attacker to steal LastPass's SSL certificates without LastPass knowing about it. I just don't see any practical way in which those certificates could have been used to execute a MITM attack at scale by anyone who couldn't have already done it even without stealing the certificates.
      So if you want to start talking about MITM attacks which require advanced capabilities and access, then yes, you're spreading FUD, because IMO it's no different from where we were without Heartbleed.

      Delete
    13. While it is true that such a capable attacker could probably compromise a user "by any means necessary", this vulnerability potentially makes a remote attack much easier in one critical respect: the attacker would possess the *same key* as the legitimate server. Under normal conditions, the end user can defend against a "rogue CA" attack by verifying the CA and the certificate fingerprint, or by using an extension like HTTPS Everywhere with SSL observatory enabled. However, in the case where an attacker has obtained the private key via Heartbleed, fingerprinting doesn't help because the attacker possesses the correct certificate.

      It remains to be seen how feasible key extraction attacks are using the Heartbleed vulnerability. Early tweeters claimed they had extracted private keys but other researchers have not been able to reproduce this. Barring contrary evidence, and assuming a high value target, an attacker with ample resources and 2 years of time, it is not unreasonable to assume key compromise. That's why everyone affected is changing up their server certificates.

      Delete
    14. @Jeremy Yes I believe that Yahoo, Google, Apple, Red Hat, etc., which all use OpenSSL and have bags of money, are the ones who should most pony up for a critical infrastructure fund to support this, if only in their own interest. But LastPass has at least a bit of a platform to advocate from.

      Delete
  6. AFAIS, with your SSL cert an attacker could have provided compromised browser extensions via MITM so declaring nothing could have possibly happen is not the right reaction here.

    Correct strategy would be (after LastPass has a new certificate): Re-install browser extension, set new master password, update every other password.

    ReplyDelete
    Replies
    1. LastPass extensions are always cryptographically signed -- so replacing them is non-trivial.

      Delete
    2. Non-trivial but still possible with enough resources, if you have access to a CA that can issue a convincing-looking certificate.

      And of course, with the considerable incentive to compromise a service like LastPass, you could find large criminal organizations/government agencies with the resources to do that.

      Delete
  7. LastPass always honest and professional. I love you guys :)

    ReplyDelete
  8. If a list of affected sites becomes available, might be nice to see that integrated into the Security Check, with a recommendation to generate new passwords for those sites.

    ReplyDelete
    Replies
    1. Yes, thank you for building the app in the first place. Adding it as a security check would be really nice (and maybe a good way to draw customers :). Building on that, it would be great if you could also capture if they had the vulnerability even if they have fixed it. Since the data may have already been compromised. I know you don't have that data, but it looks like various groups are working to pull that together as well.

      Delete
    2. I agree. I would love for this to be added to the Security Check. You already have a list of the sites used. It is a pain to enter them in one by one.

      Even updating the current functionality would be useful to make the results easier to read to show what the customer needs to do at a glace. Just a simple, SAFE/CHANGE/UNKNOWN would be good.

      Delete
    3. This... it'd be nice to just run a check, then do the tedious work of password changes in the knowledge I was hitting the right places, and knowing which sites to avoid in the meantime.

      Delete
    4. +1 I have to hope LastPass is working on this. Also don't want to change my passwords until other sites fix so would be good to know when that happens.

      Delete
    5. +1 This would raise confidence that I am alerted to the status of all the sites in my LastPass valut that I frequently and infrequently access, and would raise the value of using LastPass tremendously. Please consider implementing this.

      Delete
  9. 1. Mallory acquires Lastpass SSL secret key using heartbleed.
    2. Mallory sets up server with page which looks a lot like the lastpass login page, except the fancy javascript which encrypts the password before transmission isn't there - it's just a plain box. Looks the same to the user though.
    3. Mallory somehow gets user's to access it. Maybe a mitm proxy ish attack, or she has control of some dns server. (this is the most unclear bit of this).
    4. Mallory collects lastpass usernames and passwords. Maybe he returns an error page, or transparently forwards the requests on to lastpass.

    What's not possible about that scenario? Perhaps you would notice if that had happened?

    In short, just because the page *you* serve doesn't send the plaintext password, what's to stop an imposter doing so?

    ReplyDelete
    Replies
    1. We tell our customers to prefer logging into the extensions -- and that's exactly what the vast majority of our users do -- even if somehow someone implemented a MITM proxy, they'd also need a potential victim to utilize the website to login rather than the extension -- the extensions themselves couldn't be replaced as those are all cryptographically signed.

      Delete
    2. Changing your account settings or running the security challenge requires you to connect to the site, though, correct? So, then, even though you start out with the extension, you could inadvertently be exposed to the Heartbleed bug. Please mention these attack vectors as well so users are aware that certain activity while using the plugins could provide a small exposure surface.

      I can see you're doing all you can to fix this, and I appreciate it.

      Delete
    3. "the extensions themselves couldn't be replaced as those are all cryptographically signed." Signed with what private key? Could that key have been compromised?

      Delete
    4. The private key for signing extensions/binaries is not on the web server -- could not have been exposed.

      Delete
    5. I think the one change I would like to see in Lastpass's architecture is allowing master password change without visiting the website. I don't see why, if a user can authenticate to LastPass through the extension, the Extension can't also re-encrypt the password data and tell LastPass "Use this blob and this authentication token from now on". Is there some security reason I am not seeing here? It seems to me a problem of authentication, and I can see no reason why it requires visiting the website to do. As a precaution against accidental data loss, LastPass could store the old blob locally until, e.g., the next successful login. With this one change, it seems to me the maximum exposure when using the extension under a worst-case future Heartbleed-type scenario would be that an attacker could obtain the encrypted blob and see information about the settings (e.g. number of rounds of PBKDF2, 2nd factor settings, allowed countries, etc.).

      Delete
  10. "However, users should wait until their sites have replaced their certificates, with a start date after today (April 8th, 2014)."

    We re-keyed our Digicert certificates this morning and the start date in the re-issued certificate is the same as the start date in the original certificate, so I don't think you can use the certificate start date to determine whether a site has replaced its certificate.

    ReplyDelete
    Replies
    1. Also, checking the date on the certificate isn't good enough, since that won't tell you whether the site using the certificate has actually _patched_ the Heartbleed bug.

      I think LastPass is going to have to help us out here with some sort of tool to make this process easier.

      Delete
    2. Same thing here.. This tool is going to great mass panic and protest among LastPass users and many sites that may have IMMEDIATELY fixed the issue.

      Delete
    3. We're working to account for this scenario. We err on the side of caution, we've softened our language a bit to help our users better understand this. We appreciate the feedback!

      Delete
  11. Discussion on HackerNews, check it out,especially the first comment
    https://news.ycombinator.com/item?id=7553745

    ReplyDelete
  12. Thanks for keeping us in the loop! I always appreciate your straightforwardness.

    ReplyDelete
  13. I am currently in touch with technical support, as apparently I am the sole individual for whom the certificate change didn't work. Sigh.

    ReplyDelete
    Replies
    1. I'm curious, what browsers are you using? all updated? what OS?

      Delete
  14. Whew! Glad there are multiple layers of encryption and glad I use dual factor. Thanks alot for creating the tool to help us check our other services!

    ReplyDelete
  15. Hi there,

    I find your post misleading and an attempt at downplaying the impact of this vulnerability to your service. Yes, agreed that you don't have access to the encryption key with which the user vault is protected. However, you must have some sort of hash token stored on your servers, which is generated from the same key to be able to authenticate your users. And it's this token that may have been compromised because of this vulnerability, which would let an attacker log in to the compromised account and access the vault.

    And since the encryption is handled at the client side, the algorithm is not hidden from the attacker and knowing the authorization token, there is a possibility of the password being retrieved through brute forcing (especially for weak passwords).

    If you disagree, I would like to see you post more technical details to challenge this.

    ReplyDelete
    Replies
    1. Also, for the above reason, instead of:

      "Because other websites may not be encrypting data the way LastPass does, we recommend that LastPass users generate new passwords for their most critical sites (such as email, banking, and social networks) if those sites utilize Apache, Nginx or show as vulnerable to the Heartbleed bug."

      your recommendation to the users should be to re-generate passwords to *all* the sites in their lastpass vault, especially if they aren't using a very strong password for lastpass

      Delete
    2. "However, you must have some sort of hash token stored on your servers, which is generated from the same key to be able to authenticate your users. And it's this token that may have been compromised because of this vulnerability, which would let an attacker log in to the compromised account and access the vault."

      You obviously don't understand the concept of one-way hashes. I am sure LastPass stores a one-way hash of user passwords on its servers, but that absolutely would not allow someone who stole one of those one-way hashes to use it to log into the user's account and access his/her vault.

      Delete
    3. And you probably don't understand how the original password may be derived from 1 way hashes using brute-force or rainbow tables. Read up a little.

      Delete
    4. You guys are both wrong. Yes they store the hashes. No you could not use a rainbow table to reverse them due to how those hashes are created, using unique salts and multiple iterations using PBKDF2. And brute forcing those hashes would take to the end of time, or at least until quantum computing is the norm :)

      Delete
    5. Hello

      The entire point of a one way hash is that it is protected from bruteforce or rainbow table attacks.

      Based on the lengths lastpass already goes to in protecting it's users. I find it highly doubtful they don't salt their passwords.

      It is next to impossible to bruteforce this hash+salt in any meaningful time period.

      Delete
    6. Thor, unlike other responders, you seem to know a bit about this. Yes your are right - rainbow tables aren't helpful in this case. However, did you notice I had specifically mentioned that accounts with weak passwords are vulnerable? Don't be misled into believing that PBKDF2 is going to protect against brute forcing of weak passwords. For example, if some one was foolish enough to chose 5 digit numeric password, since all the parameters of PBKDF2 computation are already known (since it needs to be carried out on the client side), it's trivial to brute force the 10^5 possible combinations and find the one that results in the one way hash captured from the memory dump.

      It simply boils down to this: the client browser takes the password, does some cryptographic computations with it, generates a token and sends it along with the user id to lastpass for authentication. Lastpass compares it with what's stored on their server and authorizes the user. If attacker can retrieve the userid and the token from the server, he can brute force the password (if it was weak enough), by carrying out the same client-side computations on different password combinations. And you'll be surprised how many users still choose weak passwords no matter how much you try to make them understand.

      LastPass's PR statement that "yes we were vulnerable but you all are safe" is basically BS. Asking users to change passwords because "other" sites might be vulnerable is just a cover up.

      Delete
    7. From another "anonymous".
      That's a cogent and very helpful post; we want to be certain that LP is completely secure and comments like yours are an encouragement for us and them to do what we all can.

      Delete
    8. This comment has been removed by the author.

      Delete
    9. I delete my post earlier but figured "why not?", so here's my reply:

      You are generalizing brute force attacks on hashed weak passwords, not taking into account how LP actually works.

      The users’s private key is used to encrypt and decrypt the local password database. This key is derived from a 256-bit hash of the users master password and salt (username), using multiple iterations of PBKDF2 with a SHA-256 as hashing algorithm. Let’s call this “PK”.

      This PK is NEVER transmitted to/from Last Pass. Instead, a second key, let’s call this the Login Key, or LK, is created locally using one additional PBKDF2 iteration with the PK generated earlier as a seed value. Last Pass uses the LK to authenticate the user by hashing the LK with a 256-bit random hex hash salt that was created at account creation. LP then compares that value to a stored hash that was derived in the same fashion at account creation, and if those values match then the user is authenticated and they can download their encrypted password blob.

      Assuming you could intercept the session using Heartbleed or any other vulnerability, you would only obtain the Login Key hash, and would need to brute force that to to obtain the PK hash.

      The LK is for all intents and purposes invulnerable to brute force attacks due to the combined length of the salt and password. In essence LK=PKDF2(SHA-256,PK,mypassword), or in more detail: LK = PKDF2(SHA-256,(PKDF2(SHA-256,5000,myemail,mypassword)),mypassword).

      As an side, even if the original PK’s master password was weak, it would only make the PK vulnerable to brute force attack if you knew the salt and PBKDF2 iterations chosen by the user to create the PK, and that’s assuming you had access to the PK, which is never transmitted to begin with, or could somehow brute force the LK to derive the PK.

      Does that mean I’m advocating for a weak master password? No way! All I’m saying is that LP’s layers of security would seem to mitigate the effect of choosing one. I for one won’t be changing my LP password but will be changing all the passwords for sites I have accounts to. Ironically, even through I trust LP and still keep my email and bank logins in my head only ;)

      Delete
    10. Anon - you obviously don't understand the concept of Salt and multiple rounds of hashing. It doesn't matter how simple your initial password is.

      LP is adding a load of stuff to this call 'salt' hashing that. Adding your username and password to that hash + more 'Salt' and hashing that AGAIN.

      On as if this wasn;t enough, the number of 'rounds's of hash is user configurable on a per account basis.

      It is true that brute force of a simple hashed password in a single round with no salt is vulenerable but then it would also be open to a rainbow table attack.

      LP is the gold standard in thios stuff. They publish openly their entire encryption model and it has been proven to be as perfect an implementation as you can get.

      Please stop with the scaremongering unless you know what you're talking about.

      Delete
    11. Thor,

      That's a pretty good example you laid out there…
      Let me try to explain why such a scheme will not protect a weak-password from being revealed through an offline brute force attack. You would agree that when a login session is initiated, the starting point is just the user name and the master password. All intermediate keys (whether login key or primary encryption key) are generated from this password using PBKDF2. In you example, if I understood correctly, the login key is hashed with a random salt and sent to LP for verification. Since the browser doesn't have this salt upfront (since it was randomly generated during a/c creation), it must be something that it's able to retrieve from LP before an authenticated session is established. Now, the browser will compute the LK from master password, generate the hash token based on the random salt and send it to LP along with the user id for authentication. Let's assume the attacker grabs both the username and hash token from the memory dump by exploiting heartbleed. Now since the random salt can be retrieved from the server without authentication, the attacker has all the ingredients except the master password itself, that are required to generate the PK, LK and the final hash token and also knows what this token value should be. At this point, all he needs to do is to try different master password combinations and check which one results in the correct hash value. Of course, the difficulty of this task would grow exponentially with the strength of the master password. But for really lame passwords (just numeric digits, for example), he just has to try a few thousand combinations to find the right one. Unfortunately, many users still choose passwords based on a certain date, DL#, social security, etc, which makes these kind of attacks very practical. No matter how complex your key derivation is and how many layers of encryption you add, your weakest link is still the master password. The attacker would always go after that, and not after any intermediate keys used during the authentication process (which are pretty much impossible to obtain through brute-force).

      Kudos to you for not trusting LP with your banking information! If you're still not convinced, consider this: if you have a really really lame password (say a number between 1 and 100), do you still think is safe from an offline brute force attack, since LP added multiple layers of encryption on top of it?

      Sorry, but I have to ignore all other comments that are based purely on speculation. And to those who are not getting the point, I'm not trying to say that LP encryption model is flawed, all I'm trying to say is that despite it being quite robust, accounts with weak passwords may have been compromised because of this vulnerability. And since the implications are very serious, I expect LP to not pretend that none of its users could have been affected by this bug.

      Delete
    12. Update: I just intercepted and analyzed the LP login session. There is no "random" salt involved in the hash computation. The only inputs are username & master password (provided by user) and the iteration count (retrieved from LP). Any salt used in the token generation is ultimately derived from these three parameters. Maybe Thor meant that the LK is sent to LP for authentication and it stores hash of this key salted with some per-account random data also stored on their server.

      When going through the above post, just ignore the bit about random salt being retrieved from LP. The client browser already has the salt it needs.

      Delete
    13. This comment has been removed by the author.

      Delete
    14. Stupid typos...
      That is correct. The login key is derived from the master password and the private key (PK) as the salt. Recall that the PK was generated itself from the master password and the user id (as the salt) over multiple iterations of PKBDF2. Interestingly that login key (LK) is not stored on their server, only a hashed version is stored which was hashed with a 256-bit random salt at the time the account was created. Both that 256-bit salt and the hash of the LK are what is stored on their server. When you create the LK again (new session) they just have to rehash the LK you provide with the stored 256-bit salt and then compare that (Auth Key) to the stored version. Here is a diagram I created some time ago but only today published to my blog. Keep in mind that this is my analysis and I could be wrong, although I doubt it. http://all4usability.blogspot.com/

      Delete
    15. Actually, the very first request out to the server in the authentication process is to retrieve the iteration count for the given user-id (it doesn't require an authenticated session):
      https://lastpass.com/iterations.php?email=username%40server.com

      Also, how the LK is authenticated/stored on the server is actually irrelevant here. Since all that an attacker needs for an offline brute force attack is to grab the post-data with the user-id & the LK from the memory dump. Thereafter, all that stands between him and the unencrypted vault is the strength of the master password...

      Delete
    16. Also, just to put things in perspective, if your master password is coming straight out of the dictionary and the attacker was able to dump your post-data, he would have your vault open in a matter of hours as opposed to a few zillion years.

      LastPass, do you still believe *all* your customers are immune to this bug?

      "While this bug is still very serious, it could not expose LastPass customers’ encrypted data due to our extra layers of protection."

      Delete
    17. Did you review the diagram I posted? The LK hash is a concatenation of the PK+Password, not just the password! But first let's backup to the PK creation. For the PK, if my userid is: user@gmail.com and my password is '12345'. The resulting 256-bit hash is a8b49b9596612e2a45df8d6c93542a70a9969808a6b3614948e734297442d5a7, which is difficult enough to brute force, but this is the PK and is never transmitted to LP! To create the LK they hash the above string+MyPassword, or for clarity: a8b49b9596612e2a45df8d6c93542a70a9969808a6b3614948e734297442d5a712345 (see my weak password tacked on to the end? but the WHOLE string is now the password I'm about to hash!). The resulting LK hash is d04ba5bc06a92a086746b0e3b7a0533ea0399e8cb5d72df4fdb1276211606584. You will never brute force that hash, thus the LK is pretty darn secure (and that's not even mentioning iterations). Feel free to disagree, but before doing so I recommend reading up more on salted hashes and review the diagram I posted.

      Delete
    18. Oh man... I don't think you've understood what's being brute-forced here.

      Also, I've written more than enough crypto code in several programming languages to know what salted hashes and brute-force techniques are and can tell you that starting with your password, username and #iterations, the computation of LK would take a fraction of a second on a modern computer (even for a high number of iterations). Most crypto libraries provide pbkdf2 function (including gcrypt, tomcrypt, openssl and even core java libraries or you can even write your own - fairly simple). Just take your pick and write a few lines of code and see for yourself how long it takes (you can easily find example programs on the net). In fact, let me make it even easier for you - go here: http://anandam.name/pbkdf2/ enter your parameters to derive the PK (and that's a pretty slow javascript implementation). Now this is important: once you get your PK, you don't brute force anything... You proceed to compute the LK just like you did and compare it with the LK that you captured from the memory dump. You start with "1" as a password, generate the LK and compare it with the correct LK value that you already now. If it doesn't match, you repeat the process for "2". You loop through this process say until 99999, and soon as you hit "12345", you'll find that the LK you generated matches the LK you captured from the server memory dump. That tells you that "12345" is the correct password and it wouldn't take more than a few minutes for such simple a password.

      Now the number of possible combinations to try would increase exponentially with the strength of the password (as you go from numeric to alphanumeric to special char sets and increase the length of the password). But you can easily launch a dictionary attack. Instead of 1...99999, you try each word you find in the dictionary (few hundred thousand). If the master password is a word straight out of dictionary, you'll hit it within a few hours if not minutes.

      Delete
    19. LastPass doesn't store login keys in their database. They store uids and login hashes. You could, theoretically, do a brute-force attack against a uid and login hash, assuming that you had also managed to obtain the email address associated with them (it doesn't do any good to know the master password if you don't know the email address it's for!), but if LastPass knows what it's doing, and they do seem to, then the uids and login hashes aren't accessible in the memory space that would be readable by the Heartbleed bug. That is presumably why LastPass was able to assume with confidence the nonexistence of the threat you're claiming, without actual knowledge, exists.

      Putting it another way... There are a lot of facts we don't know about how LastPass's servers function. Yes, you can assume a set of facts which make them vulnerable to brute-force attacks because of the Heartbleed bug, or you can assume a different set of facts which make them not vulnerable. They've asserted the latter. Without any evidence, you've asserted the former. If you think they're lying, maybe you should take your passwords somewhere else.

      A lot more about this at:

      http://blog.kamens.us/2014/04/10/how-lastpass-protects-your-data/

      Delete
    20. @anon. I already like you…but without knowing the salt used to create the LK you are SOL. Full stop. No brute force. PERIOD. You keep saying “weak” password, but the “password” that was hashed for the LK was not JUST ‘12345’ as you keep arguing. The password that was hashed for the LK is the combination of the salt+password. And that salt was a previously created SHA-256 bit hash! So when you run your hashcat tool, what salt are you going to give it? A list of usernames? What exactly? Trust me, I do understand what you are saying; however you are generalizing the reversal (brute force) of a hash where you either know the salt, or you at least know that it consists of usernames or emails (which at the rate of billions a second, WOULD be trivial to iterate through). Interestingly, if you could obtain the salt, then you would not even need the master password, as technically the salt used to create the LK is the private key that was used to encrypt the database to begin with!

      @jtk. You are wrong about something important. Last Pass doesn’t store the Login Key (LK)! Nope, they store a hashed version of the LK that was created at account inception using another SHA-256 hash and a random hex hash salt that is also stored in their DB. Thus if you were to obtain their database, you would see a list of userIDs and an associated crazy long salt salt and the hashed version of the LK. Having access to the salt in this scenario (unlike the client side logic I’ve been discussing with anon) does not aid in entropy, but rather in reducing parallel attacks across other accounts in the DB. But even though you have the salt, in this case the “password” portion of the hash you are trying to reverse does not consist of a few letters and numbers, but rather another SHA-256 hash that resulted from hashing the LK and the stored salt. This is crazy secure in my opinion.

      @anon. Just as a challenge I have created Login Key that is a single iteration SHA-256 hash of a salt and 4 letter password. JUST FOUR LETTERS. However the salt is single iteration hash of a short email address and that same 4 letter password. Just like LP does it. If you can brute force this LK and obtain the password I will personally mail you a nice bottle of wine…or case of beer (if that’s legal) or equivalent gift card.

      LK = fb8747e9772034869fea787fa5f024ea005284fa573c4fb352f15e383a03fde9

      Delete
    21. Thor, you're not correct.

      Please go read the blog posting I linked to above.

      There is no salt involved in the creation of the login key.

      The only inputs that go into the creation of the login key are the email address and master password. This is confirmed by both the LastPass documentation and the podcast I link to in my blog posting.

      Therefore, anon is correct that if there is a LastPass account with a weak master password, and an attacker manages to get his hands on the email address, uid and stored login hash for the account (the latter two stolen from the LastPass server), he _can_ do a fast brute-force attack to determine the user's master password. The catch, as I noted above, is that I don't think account uids and stored login hashes were compromised by Heartbleed (anon thinks they were but presents no evidence to support this).

      Delete
    22. jtk. I don't give a sh!t about someone's blog. From Last Pass's own documentation: https://enterprise.lastpass.com/enterprise-administration-basics/getting-started-tab/set-up-create-new-user-2/lastpass-provisioning-api/

      Go read the "adding a user" part. Pay special attention to the first value used in the user's login key (referred to as the password hash). Notice it is "Key", AND ITS THE SALT. And furthermore that Key is the output of the private key creation routine just above it. Funny thing is I just found this documentation and it 100% confirms how I described as working. Believe what you want at this point. I don't care.

      Delete
    23. There is nothing at the page you referenced that proves what you are saying or disproves what I am saying. Your understanding of the LastPass authentication algorithm is flawed.

      The "key" argument to the second call to PKCS5_PBKDF2_HMAC on that page is not a "salt," it's the user's encryption key, as the text on that page says explicitly: "Now that you have the user's encryption key, you can use it to generate the user's password hash."

      There is no way that LastPass stores the user's encryption key anywhere on their server for blindingly obvious reasons, so there is no way that the "key" argument, which the documentation you referred to clearly and explicitly identifies as the user's encryption key, is the "SALT" that you claim is stored on the server.

      Then there's this page (https://helpdesk.lastpass.com/security-options/password-iterations-pbkdf2/), which describes the same process that's shown in the API page you referenced, at a higher level:

      "LastPass utilizes the PBKDF2 function implemented with SHA-256 to turn your master password into your encryption key. LastPass performs x number of rounds of the function to create the encryption key, before a single additional round of PBKDF2 is done to create your login hash."

      You're absolutely correct that the PBKDF2 function has an argument named "salt". when PBKDF2 is used in the "traditional" way to do create one-way hashes of passwords for later authentication purposes, then that salt is supposed to be a different random sequence of bytes for every encrypted password. But LastPass isn't using PBKDF2 that way, because if it were using it that way, _your master password would have to be sent to the LastPass server during login_.

      The way LastPass is using PBKDF2, the first time it's used, to create the user's encryption key, the "salt" specified to it is the user's email address, and the second time it's used, to create the user's login hash, the "salt" that's passed to it is the user's master password. Neither of these are traditional, random salts, because LastPass is doing something different, and cleverer, than what PBKDF2 is normally used for.

      Your "I don't give a shit" comment implies that you are either unwilling or unable to consider the possibility that you may be incorrect, so I shall now stop wasting my time trying to enlighten you.

      Delete
    24. jtk, you are confusing the salt used in generation of the login key (password hash), and the random salt generated (and maintained) on the server that was used to hash the login key. Those are two different salts. In fact there are three being used if you count the initial salt (the user's login ID) used to create the encryption key. The r API is clear enough in showing that both the encryption key hash AND the subsequent password hash (what I've been calling the LK) are both salted. The source code examples show that fact clearly, so why do you continue to argue that they don't salt their second iteration of PBKDF2? "Before a single additional round of PBKDF2 is done to create your login hash." just states that it uses only one iteration, which is also confirmed by the source example, but it doesn't state either way whether it is salted; however the source example shows that it is!

      Let's start with the encryption key:
      unsigned char key[32]; <--a variable named "key" is used to store the value that is computed on the next line:
      PKCS5_PBKDF2_HMAC(password, strlen(password), username, strlen(username), iterations, EVP_sha256(), 32, key);
      In the above line they hash the password (first value in the function) with the username as the salt (second value in the function), followed by the iteration count (5000 in the example), the hash type (SHA-256), and the output size (32 bytes).
      This is stored in "key". This is your master secret and is used to encrypt and decrypt the password database in you local cache when needed. It is not transmitted to LP. Are you in agreement with me so far? If not, then go study the example in the API documentation.
      NEXT we are going to create the password hash (a.k.a Login Key) that will be used to authenticate us against the LP database. This LK WILL be transmitted to LP. First they declare a variable (hash) to store the hash. Then they compute it (this is all client side mind you):

      PKCS5_PBKDF2_HMAC(key, 32, password, strlen(password), 1, EVP_sha256(), 32, hash);

      Now check this out. The first value is "key", with 32 bits in length. What is key? It's the value we computed just two lines above. Then the salt is provided, which is the master password (the order is reversed but it doesn't matter since those are concatenated when computer), followed by the number of iterations (1, which matches their other documentation), followed by the hash type and output size.
      That hash (along with your username) is sent to Last Pass. once they receive it they grab a stored 256-bit hash that was created at account inception, and they hash the client provided hash with that salt. If the result matches the hash created at account inception (generated in the same fashion) then you are golden to login.

      I think what is confusing people is the separation of the private key used for encryption that is also used as a parameter in the generation of the login key (password hash), from the salting that goes on server side during authentication (which uses a different salt entirely).
      Anyway, I suppose we could keep this argument going for a long time, but then you would not be arguing with me, but rather with the straight forward code examples and descriptions provided in last pass's own documentation.

      Delete
    25. Thor, I gladly accept your challenge.
      I just need to know what email did you use as the salt for the PK and a confirmation that the 4-letter password is all lower-case (a-z).

      I do want to point out that I have my doubts if you are doing this exactly like LP. This is what LP does:
      - Create 256-bit PK by hashing master-password with the user/email-id as the salt
      - Create 256-bit LK by hashing 256-bit PK with the master-password as the salt
      Note that the master-password is used as hash-data in the first step and salt in the second step. If this is exactly what you're doing, I shall have your master password.

      If I don't, it would mean we are doing things slightly differently. In which case, I'd have to ask you to let LP do the job. Which means, creating a fake last-pass account with the same password and providing me the email-id & LK (I'll tell you exactly how to capture the latter). Sounds good?

      But let me try your example first, if you can confirm the email-id and the password being all lower-case a-z chars.

      Delete
    26. Sounds good. the email was myemail@gmail.com and was used as the salt in generating the PK. The four letter master password was all lower case and used as the salt when generating the LK. I went ahead and regenerated the hashes so that they match the Last Pass order of LK creation (the PK as the password and the weak master/secret password as the salt).

      I only used a single round/iteration of sha256($pass.$salt) using http://www.insidepro.com/hashes.php?lang=eng
      The updated LK is:
      29784ce3043bcf78e49da9c849eb20e7c075b6e06a6bbb9b45b0701a67397133
      (as I needed to reverse the ordering of the pass and salt as identified in the LP documentation).

      Delete
    27. What you just described is exactly how I describe the protocol in my blog posting. What you are calling the "salt" I am calling the "uid". I completely agree with the protocol you just described.

      I can't fathom why you think that the protocol you describe precludes a brute-force attack if the attacker has access to the data on the server. It doesn't. And here's a fully formed program that demonstrates that: https://gist.github.com/jikamens/10413385

      Delete
    28. Using the referenced site for this wouldn't work for the second step.
      It seems for generating LK, you just pasted 64-char hex-string representing the PK. It should really be the 32-byte binary data for the PK, which you cannot paste in that field. But let me see...

      Delete
    29. FYI, I've received confirmation from LastPass that their SSL is terminated on nginx servers that don't have business logic on them, so an attacker using the Heartbleed bug would not have been able to steal user data.

      Delete
    30. That's bullshit. All data coming up the wire is read into memory buffer before the application processes it and puts it away. That's exactly where it can be dumped from by exploiting heartbeat (and it includes user-id as well as the hash token). Just grab some heartbeat scripts floating around the web and point them to the sites that are still vulnerable. You can see for yourself how trivial it is to grab post-data from the clients. On the other hand, if you just want to blindly believe what LP is telling you, I can't help you.

      Delete
    31. jtk, I will admit that the logic in the program supports the arguement for (relatively) easily brute forcing the password from the login key, provided the attackers knows 1) the login email, 2) the number of iterations used, 3) and has a copy of the LK to compare to, and most importantly, the password is "weak", as we've been discussing (in the code sample it is set to a max length of 5000 chars). I had not considered that knowing all those factors you would merely reproduce what the client does in creating the PK then LK and then comparing the result to the illicitly obtained LK, and if there is a match, then bam you know the true PK and master password values. The process used to generate the LK doubles the brute force computation time, but it doesn't make it exponentially harder, as I first assumed (I was mentally figuring an attack directly on the LK without the aid of trying to reproduce the PK first). As such, I'll admit you and Anon were right in that using a weak master password would be a bad idea. Thankfully I don't :)

      Delete
    32. Okay, Thor this approach will not work for the reason I stated above. You would think you're replicating the LK generation process that LP employs, but you're actually not. So let's make your challenge even more real...

      Go ahead and sign-up for a new LP account using any fake email-id and similar 4-char password. Thereafter, sign in to the account and change the #iterations to 10 (to save me some time) and sign back out.
      Now open the LP login page in Google Chrome and click Ctrl-Shift-I to activate the chrome-developer-tools. Navigate to the network tab within the dev-tools frame. Now, proceed with the login process and you'll see a whole bunch of requests show up below. Find the one labled "Login.php" method type POST. Clicking on "Login.php" in the leftmost column will show the raw data associated with your login request. Just grab "hash", "username" & "iterations" and post it here. This is exactly the data that would have been exposed to the attacker by exploiting heartbleed... let's see what we can do with it.

      Delete
    33. anony, jtk already provided the proof that knowing those factors: username, iterations, hash (LK) you could derive the mp by recreating the PK and then the LK and then comparing to the pilfered hash. (as an aside, why would my client iterations ever need to be sent to LP, since those are ONLY used to create my PK, but I digress). If you want your free beer, and an apology, you're going to have to crack the 64 byte output I gave you. It's only one extra step and thus should be easy. Or maybe jtk gets the free beer or wine?

      Delete
    34. Love, Anonymous

      Delete
    35. dzrdmwjx at gmx dot com

      Delete
    36. as an aside, why would my client iterations ever need to be sent to LP, since those are ONLY used to create my PK
      >> Because when you initiate a new login session, the browser doesn't know what # of iterations you've set your account to use and it's not something you input alongside your email/password.

      Btw, @jtk you may want to strike off this assumption from your blog as it's not entirely accurate:

      The LastPass server doesn’t know your encryption key, and your encryption key cannot be reconstructed from the data that the server knows.

      LP has the necessary data and the ability to reconstruct the encryption key if the user happened to choose a weak enough password.

      Delete
    37. Thanks, but I just did it for fun... Also, I'm located in Canada - so won't be as convenient to send anything this way. I do appreciate the offer!

      Delete
    38. >All data coming up the wire is read into memory buffer before the application processes it and puts it away. That's exactly where it can be dumped from by exploiting heartbeat

      I agree. I installed nginx on my desktop at home, configured it to be an SSL reverse proxy for my local web server, installed a CGI script that does nothing but reverses its input, called the CGI script repeatedly through nginx in one window, and then called https://github.com/sensepost/heartbleed-poc/blob/master/heartbleed-poc.py repeatedly in another window and searched the output for strings matching either the input to the CGI script or its reversed output.

      heartbleed-poc.py was easily able to successfully snoop data sent to the server, but it didn't capture any data sent from the server back to the client. I think that's because the incoming requests are handled by a separate nginx worker process, so the response data is in a separate process from the main nginx process that heartbleed-poc is talking to.

      In any case, this does seem to imply, at least at first glance, that if the Heartbleed bug was known by someone before it became public and exploited on LastPass.com, user email addresses and login keys could have been stolen and used to brute-force master passwords.

      I'm going to reach out to LastPass support and see what they have to say about this.

      Delete
    39. >Btw, @jtk you may want to strike off this assumption from your blog as it's not entirely accurate

      I've updated the blog posting to reflect the fact that things are a bit more bleak I'd previously thought.

      Delete
    40. Good luck, but I doubt if you'll get an acknowledgement of a possible data breach from LastPass (especially since heartbleed leaves no trace, so nothing could be proven). I find it odd that there's not a single comment from the LP staff on this thread, even though it's grown quite long. I'm pretty sure they are watching this conversation but have strict instructions not to comment, so that this doesn't get much attention. Consider the amount of damage it would do to their reputation... they probably handle the most sensitive client data compared to any other cloud service. But I do find it highly responsible on their part not to warn their clients about the potential ways this could have affected them and try to cover it up instead.

      Delete
    41. I've actually been conversing with @jik in our ticket system -- we don't tell our staff not to participate.

      We route all our web requests (hundreds of millions of them per day) though front end nginx boxes, requests with the only data that would be interesting to an attacker are few and far between (less than 1%) making this far harder to get interesting data (really only a full login where the password was typed would send a login hash which could be useful -- login checks where you were kept logged in are useless)

      It's hard to conceive that we (who monitor bandwidth excessively) would not have noticed anything organized to attempt to exploit this especially considering how many requests would be necessary to give you a chance at getting anything useful.

      What data is potentially at risk is far less useful than literally every other service as well -- we basically just don't get interesting data! You can't decrypt the data without brute forcing a master password into a login hash which is not feasible either.

      If you're concerned, or use a weak master password without multifactor by all means change your LastPass master password and setup multifactor but I don't think it's necessary otherwise given all that we know.

      Delete
  16. This comment has been removed by the author.

    ReplyDelete
  17. It looks like lastpass.com is indeed using a reissued certificate, but according to your own tool this is not the case for lastpass.eu.
    I would like to point this out so you can take action there as well.

    ReplyDelete
    Replies
    1. Both IPs responsible for that domain seem to be pretty up to date.. https://www.ssllabs.com/ssltest/analyze.html?d=lastpass.eu

      Delete
    2. I think I'm missing your point. The certificate issue date for that domain is 2013-11-17.
      What does your response have to do with that?

      Delete
    3. https://lastpass.com/heartbleed/?h=lastpass.eu

      Detected server software of LastPass
      That server is known to use OpenSSL and could have been vulnerable.

      The SSL certificate for lastpass.eu valid 5 months ago at Nov 17 00:00:00 2013 GMT.
      This is before the heartbleed bug was published, it may need to be regenerated.

      Delete
    4. So LastPass.eu was updates as well -- unfortunately they reissued a certificate with the same date, others have reported this happening as well -- we're looking at how we can detect this today.

      Delete
  18. Please provide an automated tool as part of the LP security check that will go through all the sites in my safe and alert me as to those that are still vulnerable. Checking one site at a time is going to take forever.

    ReplyDelete
    Replies
    1. How do you imagine LP can do that? They do not and can not know what sites are in your vault.
      What you are asking of them is to have every site you go to...Them being able to do that is much much worse than heartbleed bug! It compromises every single principle they claim to stand for!

      Delete
    2. Surely they could just have the heartbleed check run client-side? The client knows the site list for display.

      Delete
    3. Yes, implemented now: http://blog.lastpass.com/2014/04/lastpass-now-checks-if-your-sites-are.html

      Delete
  19. Thank you for doing all that is required. Coming from a security team i am sure this is more than i can ask for $ i spend on lastpass. More assured that someone trustworthy is working 24x7 for protecting my data for small i spent. Thanks and you guys rock.

    ReplyDelete
  20. Dear LastPass team, Thank you for being so forthright and attentive here and on the frontline. Not only does this pan-OpenSSL incident underscore why I trust LastPass' methodology, it shows the prowess of your skills and architectural forethought. Thank you for the countless hours sweating the details and for exploring the "what ifs" and "what thens" avenues, unmapped side streets, hidden tunnels, and obscure paths. Behind all the keys, hashes, algorithms, and computation, the heart in you work absolutely glows. I am wholly grateful. ~ Mahalo

    ReplyDelete
  21. Please can someone terll me what to actually do? I am a simple user who uses LastPass without a lot of technical know-how. 2 questions: should I change my LP master password. And what does logging in to an extension mean? Thanks
    and sorry to be ignorant....

    ReplyDelete
    Replies
    1. me too - it would be great to have an easy guide like Fixing Heartbleed for Dummies. Thanks

      Delete
    2. To be on a safe side, yes change your master password.
      At this point in time, it looks like if you were always logging in through browser addon/extension(as opposed to directly on lastpass.com website) you were safe.
      If you still feel cautious, change your passwords on other services too because chances are they did not/do not respond to such security issues as quickly as LastPass did.

      Delete
    3. @MsJinnifer - Logging in via browser extension/add-on reference typically means clicking on the LastPass icon (star on red square) in the IE/Firefox/LastPass menu/toolbar. An alternative (more dangerous in this context) is to first go to www.lastpass.com, choosing log-in in the upper right, and entering account name and password (e.g., if you used another person's computer without installing LastPass).

      @mxx - "always logging in through browser addon/extension" - "always" as in never in the last _two_ years gone directly to lastpass.com? Used another's computer to access LP?

      @mxx - "If you still feel cautious" - Actually, this is backwards: other sites are more vulnerable. Initial expert estimates are that a substantial majority of all external web sites were vulnerable and so should be changed if sensitive (including email, banks, and shopping and payment sites with credit cards on file) -- once that site is updated.

      Delete
  22. Just came here to say that you guys rock. Thank you!

    ReplyDelete
  23. Can you integrate the heartbleed check into my security check of lastpass, I have over 400 sites I need to check!

    ReplyDelete
    Replies
    1. Agreed.
      Otherwise it's going to take weeks,i.e., it won't happen

      (thanks for the quick rollout of that check, btw)

      Delete
    2. Seconded. I came here to specifically ask the kind Lastpass developers if they could roll this into the security check. At a minimum, it could just spit out a list of potentially compromised sites (like the e-mail address check). Even better, ding the security score for all passwords that haven't been changed since those sites were patched, and make it a category of bad passwords like "duplicate passwords" and whatnot.

      Delete
    3. I agree as well. Something to color code the sites in my list. Green would be for sites that are not vulnerable (no OpenSSL Implementation) or that have changed their version and updated keys and I have changed my password since they changed keys. Yellow for sites that have changed version and keys, but my password is older than their change. Red for sites that have not changed their version or keys. No matter when i change my password, they should always be red.

      Delete
    4. It's now integrated into the Security Check (http://blog.lastpass.com/2014/04/lastpass-now-checks-if-your-sites-are.html) and we've improved the lookup tool results as well to be a ltitel clearer.

      Delete
  24. Here's my idea for how to make it easy for LastPass to help users recover from this bug: http://blog.kamens.us/2014/04/09/we-need-a-heartbleed-txt-standard-and-we-need-it-asap/

    ReplyDelete
  25. Basic question: Should the end-users start with deleting all the current certificates? Just checking for a revoked certificate won't cut it for this.

    ReplyDelete
  26. MsJinnifer speaks for many of us, I’m sure. Most who have posted here have impressive knowledge of computer security. However, I have to believe the majority of LP users have little desire to become computer security experts. So, with no apologies for being ‘ignorant,’ I hope you’ll provide a simple explanation of ‘extensions’ and an easy-to-follow ‘check list’ of recommendations (the Fixing Heartbleed for Dummies mentioned above). We’ll do the first aid, but leave the brain surgery to LP.

    ReplyDelete
    Replies
    1. Thanks for the feedback, I recommend starting with the actionable steps now shown in the LastPass Security Check: http://blog.lastpass.com/2014/04/lastpass-now-checks-if-your-sites-are.html

      Delete
  27. Can anyone comment as to why the LastPass Heartbleed checker is giving me different results from the "official" checker at http://filippo.io/Heartbleed? Chase.com shows up vulnerable from LastPass, but Filippo shows it as safe.

    ReplyDelete
    Replies
    1. LastPass' checker is checking if it MIGHT have been impacted -- and if the site has updated it's SSL certificate yet, instead of checking if it's currently vulnerable. This vulnerability isn't as simple as "Now it's fixed" -- sites need to regenerate their SSL certificates to be safe if they were impacted.

      Delete
    2. This comment has been removed by the author.

      Delete
  28. Does Two-Step Authentication help here?

    ReplyDelete
  29. Alex van der BaanApril 9, 2014 at 11:28 AM

    Thank you for this post,

    You mention that you have a more secure implementation. As a user of security services including Lastpass I must say that over the last years more companies have promised security and 'water proof' implementations. How can we as users of Lastpass be 100% sure that what you say is actually true?

    Do you for instance have yearly external auditors that look at the whole security chain? Not just technology and crypto but also the human factor? It is unfortunate to say but with all that is happening today I need to see more than reassuring statements. Can Lastpass provide us with more?

    ReplyDelete
    Replies
    1. Alex, I think you miss the point.

      Statements and audits stop nothing. What DOES work is for LP to openly publish their technical architecture and for this to be reviewed on the world stage by world renowned security experts.

      They have been open from day one and NO ONE can find any issues with their approach.

      The very fact that LP have been so proactive and honest about the potential threats should speak volumes.

      This is not the first time LP have been so reactive. A few years ago there was a vulnerability found in one of the hashing algorthims so LP instantly upp the number of rounds the hash is done to make it unfeasible for a brute force attack.

      They then made this a user configuable option on a per user basis making it even more secure.

      I'd be far more worried about Google, Facebook and you Bank if I were you!

      Delete
  30. The tool for checking vulnerabilities is great, but I have a small suggestion. Make it easier to read. Right now it spits out sentences explaining what information you gathered about the site. You could simplify this to simple state the results, and use a color coded.

    Here's a mockup:
    http://imgur.com/npmhpOl

    ReplyDelete
    Replies
    1. YES!!!!!!!!! Lastpass do this. I commented on something above asking for something exactly like this mockup.

      Delete
    2. Thanks for the suggestion; you may also want to run the security check now (LastPass Icon > Tools > Security Check) for more actionable results.

      Delete
  31. This comment has been removed by the author.

    ReplyDelete
  32. Since lastpass has a tool to test whether a site is vulnerable or not, would it be possible for lastpass to somehow scan our list of sites and advise us if any of them have been or are still vulnerable?

    ReplyDelete
    Replies
    1. Marc, to do this would mean giving LP access to your decrypoted vault.

      Did you know you can export a copy of your vault in CSV? You could then use this to automate an HTML lookup of the Heartbeat checker site.

      I personally don't want any feature to be built that allows LP access to my vault. That's the whole reason for using LP in the first place!

      Delete
    2. It could be a tool you run when logged in to your account.

      Delete
    3. LastPass is Awesome. You can now use the security check tool to see which sites are vulnerable and weather you should wait or not to change your passwords.

      Delete
  33. If your LastPass heartbleed checker indicates a site is vulnerable, but they have not yet replaced their SSL certificate since the leak was announced, is there any point in changing my password at that site yet? After all, they are still just as vulnerable until they update their SSL certificate, correct?

    ReplyDelete
    Replies
    1. There's no point in changing your password for a site until the site is patched and the SSL certificate is replaced.

      Delete
  34. I think there's a bug in your bug tester. I have a host that does not listen on https at all. But if I enter it into the tester, it gets:
    Detected server software of LastPass

    And the rest of the info is the same as if you'd entered lastpass.com instead. I haven't been able to reproduce this with any site other than our own. And I don't want to post our site's hostname out here as bait for anyone reading it (who knows if it's vulnerable to some random thing). If you post an email address, I'll drop you a line with the info so you can figure it out.

    FWIW, http://filippo.io/Heartbleed/ properly says "i/o timeout" with this site.

    ReplyDelete
    Replies
    1. Actually, this might be easier. If you can see the IP of people posting (I assume you can), look at the IP of this message. Change the last number to 68 and do a reverse lookup. That should give you the host name to try.

      Be sure to look up the ip on this one and not the original comment.

      Delete
    2. You're welcome to send details to security[at]lastpass.com and we can take a look.

      Delete
  35. Users are redirected to the LastPass website to change account settings, even if they are using the extension. What risk might the OpenSSL bug have exposed users to while changing their master password or other account settings?

    ReplyDelete
    Replies
    1. There's no risk, as we've reissued our certs and updated the affected OpenSSL.

      Delete
    2. What was the risk in the two years before the update?

      Delete
  36. I dont get this heartbleed thing can anyone sum it up in a paragraph for me

    ReplyDelete
    Replies
    1. There has been a bug that's been "exploitable" for two years, in which someone "may" have been able to access data that was otherwise thought to be secure. That little lock that appears in your browser telling you you're on a "secure" site wasn't necessarily correct. The main thing is to ensure you're using a password manager, and start updating your passwords for critical sites.

      Delete
  37. Good advice. My password manager Sticky Password (www.stickypassword.com) made a similar statement. I think you guys should join forces!

    ReplyDelete
  38. You may want to contact the mashable team : http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/?utm_cid=mash-com-fb-main-link

    ReplyDelete
  39. From what I can see, every effort is being made to make the whole process as secure as possible.

    We are quick to try and point the finger at someone when there is a problem, but in reality these attacks are part of the beast, are here to stay. So the only way to combat this sinister beast is to work together. Responsibility must be shared between user and provider equally.

    Transparency and honesty is paramount. I don't expect ANYONE to 100% guarantee complete immunity, this would be arrogant. I prefer swift and accurate information for the best way for me to be proactive in keeping my data secure.

    Thanks LastPass, keep up the good work.

    P.S. If you're not a premium member...then become one!! You only get what you pay for.

    ReplyDelete
  40. Soo, if you change your password and other security details on a site BEFORE checking if that site is 'safe', have you now exposed ALL of your reset data (sec questions etc)? whereas this data couldn't have been sniffed before (assuming you haven't changed them in the last two years)

    ReplyDelete
    Replies
    1. It's best to wait until you've confirmed that the site has updated their OpenSSL and reissued their certs.

      Delete
    2. Ok thanks, I've run the security scan now, very useful indeed.
      Like many on here I'm glad I'm a LastPass Premium subscriber, the response to this issue has been second to none. Thanks.

      Delete
  41. As a paying Lastpass customer, I should not have had to learn about the Heartbleed issue from Twitter and Facebook. The Lastpass company should have informed its customers personally, as soon as you knew about in the problem. Your actions are very similar to Adobe when they were hacked.

    ReplyDelete
    Replies
    1. An email is on the way, we appreciate the feedback. The blog is where we can get to fastest and we roll out communication from there - I recommend also subscribing to the blog!

      Delete
    2. I'm afraid Anon is correct, you should have emailed everyone the second you heard. I went onto the website and the forum straight away, but didn't see any links to the blog. There should at the very least been a big notice on the home page with the news. Sending a brief email out to your clients with a link to the blog would have taken minutes and would have been very much appreciated by everyone.

      Delete
    3. Thanks Simon, our blog roll is at the bottom of the homepage - we'll see if we can get this more visible in the meantime.

      Delete
  42. There is an issue with the heartbleed checker that's been created, I do love it and appreciate it, but for a couple of the results are incorrect. Companies including Cloudflare and Google are showing as "Wait!" because they last reissued their SSL certs a week ago? This is why they reissued them, Cloudflare at least, have publicly announced on their blog that they updated their certs before the exploit was made public, to ensure the highest possible security for their customers. But the Lastpass checker states these sites and certs as exploitable... any way that could be fixed? Or will the results just have to be taken with a pinch of salt?

    ReplyDelete
    Replies
    1. We continue to update and expand the list based on the information we have and the information we're able to check.

      Delete
    2. That's good news, thank you. Really value your service and didn't want it to be seen as giving out false information. Continue doing what you guys do best! :D

      Delete
  43. If lastpass.com was using the openssl lib affected, why do we not need to change our master password?

    ReplyDelete
    Replies
    1. Because your master password is never transmitted over the network and never stored on LastPass's servers and therefore even an attacker taking advantage of the Heartbleed bug couldn't have obtained it.

      Delete
    2. Since this has not been denied by LastPass, one can assume that an attacker exploiting the Heartbleed bug to obtain the LastPass private key and occupying a privileged network position from which to serve malicious javascript via MITM attack could have obtained the master password when, e.g., the user changes the master password or logs in on the website. Practically, this attack could probably only be carried out by large state actors so the vast majority of users should not be concerned.

      Delete
    3. No, one cannot assume that, because even when you are using LastPass.com, _your master password is never transmitted over the network_. Please stop spreading FUD.

      Delete
    4. I don't think you understand how a MITM attack works. Explaining clearly the potential exposure from a vulnerability is not FUD.

      Delete
    5. I suppose I must be lost then, how does the extension I login to on my broswer connect to lastpass.com? not with ssl?

      Delete
    6. @Maxwell - yes but the extension never sends your password to LastPass. Rather, it does a bunch of operations - concatenating your password with your email address and passing it through a one way cryptographic key derivation function that cannot be reversed to make the encryption key; then concatenating your key and your password and passing that through a one way hash - and sends this completely scrambled, unreversable blob to the server to authenticate you (on the server this blob is combined with a random salt and hashed and stored there), along with any second factor you have enabled. Once you are authenticated, LastPass releases the encrypted blob of your password data to your browser extension, and the extension then decrypts the blob on your machine. The password and encryption key never leave your system. The extension is very tamper-resistant as it is signed with a code signing key that is not the SSL key and is kept offline by LastPass. So it would be very, very difficult, all but impossible, for an attacker to change code in the extension so as to transmit your password or otherwise grab your information.

      Delete
    7. Thanks Anonymous, that helps understand, you should work for lastpass!

      Delete
  44. This is all great information. I tried to read through and see if this was already asked, but it's all so technical! I put a few sites into the checker and it said wait until the site is updated before changing my password. How would I know when the site is updated?

    ReplyDelete
    Replies
    1. Hi Ella: I would wait and run the security check again at a later time, we continue to expand and update the list based on the information we have access to. Thanks!

      Delete
  45. What are the tests that Lastpass uses to check for site vulnerability? Only OpenSSL 1.0.1 through 1.0.1f (inclusive) are affected, so I hope that the check isn't a blanket check on OpenSSL

    ReplyDelete
    Replies
    1. Just an FYI, this site: https://www.ssllabs.com/ssltest/index.html, comes up with different results than your test.

      Delete
    2. We're looking at what could have been affected, not what is just currently still affected. Our tool has been doing SSL certificate checking, and server header checking, and known vulnerable list checking from sources we're tracking - we're actively taking reports of sites whose details have changed.

      Delete
  46. Are apps on your phone safe? If I used the Chase bank app, Citi app etc. Are those affected?

    ReplyDelete
    Replies
    1. The primary concern is if you ever logged in to the web version of those sites, which seems likely in the last two years. We recommend updating passwords for critical financial sites.

      Delete
  47. I am not a current lastpass user but would like to sign-up. Would it be OK to sign-up today given the current state of affairs?

    ReplyDelete
    Replies
    1. Yep, now is the best time! Get it installed, get it setup, get an idea of where all you have sites, and then get started with using the features.

      Delete
  48. I am a long time LastPass (and will continue) paid user and after following the instructions (The LastPass Security Check can be run from the LastPass Icon menu. Click the LastPass icon in the browser toolbar, click the Tools menu, and select the Security Check.) and only get sent to the link https://lastpass.com/index.php?securitychallenge=1&lang=en-US&fromwebsite=1&lpnorefresh=1 ..... what am i doing wrong??

    ReplyDelete
  49. Using the Security Check, I was able to see which accounts are needing to get passwords changed on, but one is not acknowledging that I am safe. The site is fitbit.com and the Security Recommendation shows my password age as "31 minutes", but it still says "Go Update!" Any idea what may cause this?

    ReplyDelete
  50. I was impressed with LastPast's response to the heartbleed bug so I signed up and became premium. Highly recommend to others.

    ReplyDelete
  51. TNO with end to end encryption. It's the only way to surf!

    ReplyDelete
  52. I heard LastPass was supposed to fill in logins on mobile apps. I have been a premium member for almost 1 year and haven't seen that feature. Is it in the settings?

    ReplyDelete