text:
Apr 8, 2014
LastPass and the Heartbleed Bug
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.
345 comments:
- AnonymousApril 8, 2014 at 10:58 AM
"we recommend that LastPass users generate new passwords for their most critical sites (such as email, banking, and social networks)"ReplyDelete
Does this include LastPass itself if we have logged in to the website? Presumably someone could have our key's passphrase?Replies
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
- AnonymousApril 8, 2014 at 11:12 AM
Does this include if you've logged in via https://lastpass.com/mobile/ ?Delete
Yes, same principles apply there as well.Delete
- AnonymousApril 8, 2014 at 11:18 AM
I was directed here via a support ticket about this issue. You people are terrific!Delete
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
- AnonymousApril 8, 2014 at 11:26 AM
Enable your 2 factor authentication too!Delete
- AnonymousApril 8, 2014 at 2:54 PM
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
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
It does potentially leak your SSL private key though - I trust you regenerated your certificates.Delete
Yes, we updated our certificates.Delete
- AnonymousApril 9, 2014 at 4:47 AM
gizmodo commented on the threat as wellDelete
- AnonymousApril 9, 2014 at 2:21 PM
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
I'll agree with that - you are definitely on top of the task. Thank you for your mini-fireside chat here.Delete
After I read about the exploit, LastPass Blog was my first stop. Was not dissapointed. Thanks for being such a great service.Delete
This comment has been removed by the author.Delete
How about adding a print option for this page along with the various sharing options?Delete
Amazing service and technical expertise. That's why LastPass is worth every penny! Thanks guys.Delete
- AnonymousApril 11, 2014 at 2:40 AM
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?Delete
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.
- R. J. S.April 8, 2014 at 11:24 AM
You are the best - thanks for your extraordinary steps to protect your users' data. Total pros :)ReplyDelete
- AnonymousApril 8, 2014 at 11:26 AM
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.ReplyDelete
Hopefully this vulnerability wasn't know by anyone until today, and we're all (mostly) safe.
- AnonymousApril 8, 2014 at 11:36 AM
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 helpReplyDeleteReplies
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
So here's a scenario:Delete
* 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?
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.Delete
and (at some or all points, not sure where) it goes through user-defined PBKDF2 rotations.
- AnonymousApril 10, 2014 at 10:24 AM
It's possible that they may have your plaintext credentials from memory.Delete
Care to comment on this?ReplyDelete
Claiming that MITM breach of LastPass.com with compromised SSL certificate that served poisoned JS to all web users.Replies
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
The extensions do not utilize javascript from the website, it's built into the extension.
Also, we recommend using multifactor authentication for added protection of your account.Delete
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?Delete
@Amber: and how would that have helped in this case?
@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
- AnonymousApril 9, 2014 at 12:24 PM
Hi Joe,Delete
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?
@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.Delete
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.
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
- AnonymousApril 10, 2014 at 10:28 AM
@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:Delete
-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
- AnonymousApril 10, 2014 at 11:03 AM
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
- AnonymousApril 10, 2014 at 11:25 AM
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
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.
- AnonymousApril 10, 2014 at 12:32 PM
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.Delete
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.
- AnonymousApril 10, 2014 at 12:46 PM
@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
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.ReplyDelete
Correct strategy would be (after LastPass has a new certificate): Re-install browser extension, set new master password, update every other password.Replies
LastPass extensions are always cryptographically signed -- so replacing them is non-trivial.Delete
- AnonymousApril 9, 2014 at 11:34 PM
Non-trivial but still possible with enough resources, if you have access to a CA that can issue a convincing-looking certificate.Delete
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.
LastPass always honest and professional. I love you guys :)ReplyDelete
- AnonymousApril 8, 2014 at 11:51 AM
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.ReplyDeleteReplies
This makes sense.Delete
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
- AnonymousApril 9, 2014 at 12:12 PM
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.Delete
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.
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
- AnonymousApril 9, 2014 at 5:55 PM
+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
- John SApril 9, 2014 at 9:01 PM
+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
- AnonymousApril 8, 2014 at 11:53 AM
1. Mallory acquires Lastpass SSL secret key using heartbleed.ReplyDelete
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?Replies
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
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.Delete
I can see you're doing all you can to fix this, and I appreciate it.
- AnonymousApril 8, 2014 at 9:45 PM
"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
The private key for signing extensions/binaries is not on the web server -- could not have been exposed.Delete
- AnonymousApril 10, 2014 at 2:37 PM
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
"However, users should wait until their sites have replaced their certificates, with a start date after today (April 8th, 2014)."ReplyDelete
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.Replies
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.Delete
I think LastPass is going to have to help us out here with some sort of tool to make this process easier.
- AnonymousApril 10, 2014 at 3:27 PM
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
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
- AnonymousApril 8, 2014 at 12:10 PM
Discussion on HackerNews, check it out,especially the first commentReplyDelete
Jumped in there -- thanks.Delete
You guys are awesome.ReplyDelete
Thanks for keeping us in the loop! I always appreciate your straightforwardness.ReplyDelete
I am currently in touch with technical support, as apparently I am the sole individual for whom the certificate change didn't work. Sigh.ReplyDeleteReplies
I'm curious, what browsers are you using? all updated? what OS?Delete
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
- AnonymousApril 8, 2014 at 5:31 PM
Hi there,ReplyDelete
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.Replies
- AnonymousApril 8, 2014 at 5:41 PM
Also, for the above reason, instead of:Delete
"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
"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."Delete
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.
- AnonymousApril 8, 2014 at 6:44 PM
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
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
- AnonymousApril 8, 2014 at 10:38 PM
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.
- AnonymousApril 8, 2014 at 11:25 PM
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.Delete
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.
- AnonymousApril 9, 2014 at 6:14 AM
From another "anonymous".Delete
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.
This comment has been removed by the author.Delete
I delete my post earlier but figured "why not?", so here's my reply:Delete
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 ;)
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.Delete
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.
- AnonymousApril 9, 2014 at 4:24 PM
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.
- AnonymousApril 9, 2014 at 4:54 PM
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.Delete
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.
This comment has been removed by the author.Delete
Stupid typos...Delete
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/
- AnonymousApril 9, 2014 at 7:34 PM
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):Delete
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...
- AnonymousApril 9, 2014 at 8:05 PM
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.Delete
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."
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: email@example.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
- AnonymousApril 9, 2014 at 10:29 PM
Oh man... I don't think you've understood what's being brute-forced here.Delete
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.
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.Delete
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:
@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!Delete
@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
Thor, you're not correct.Delete
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).
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/Delete
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.
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.Delete
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.
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!Delete
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.
- AnonymousApril 10, 2014 at 2:15 PM
Thor, I gladly accept your challenge.Delete
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.
Sounds good. the email was email@example.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).Delete
I only used a single round/iteration of sha256($pass.$salt) using http://www.insidepro.com/hashes.php?lang=eng
The updated LK is:
(as I needed to reverse the ordering of the pass and salt as identified in the LP documentation).
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.Delete
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
- AnonymousApril 10, 2014 at 3:45 PM
Using the referenced site for this wouldn't work for the second step.Delete
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...
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
- AnonymousApril 10, 2014 at 5:09 PM
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
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
- AnonymousApril 10, 2014 at 5:21 PM
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...Delete
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.
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
- AnonymousApril 10, 2014 at 6:15 PM
Love, AnonymousDelete
- AnonymousApril 10, 2014 at 6:17 PM
dzrdmwjx at gmx dot comDelete
- AnonymousApril 10, 2014 at 6:26 PM
as an aside, why would my client iterations ever need to be sent to LP, since those are ONLY used to create my PKDelete
>> 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.
Red or white?Delete
- AnonymousApril 10, 2014 at 7:36 PM
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
>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 heartbeatDelete
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.
>Btw, @jtk you may want to strike off this assumption from your blog as it's not entirely accurateDelete
I've updated the blog posting to reflect the fact that things are a bit more bleak I'd previously thought.
- AnonymousApril 10, 2014 at 9:11 PM
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
I've actually been conversing with @jik in our ticket system -- we don't tell our staff not to participate.Delete
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.
This comment has been removed by the author.ReplyDelete
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.ReplyDelete
I would like to point this out so you can take action there as well.Replies
Both IPs responsible for that domain seem to be pretty up to date.. https://www.ssllabs.com/ssltest/analyze.html?d=lastpass.euDelete
I think I'm missing your point. The certificate issue date for that domain is 2013-11-17.Delete
What does your response have to do with that?
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.
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
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.ReplyDeleteReplies
How do you imagine LP can do that? They do not and can not know what sites are in your vault.Delete
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!
- AnonymousApril 9, 2014 at 10:21 AM
Surely they could just have the heartbleed check run client-side? The client knows the site list for display.Delete
Yes, implemented now: http://blog.lastpass.com/2014/04/lastpass-now-checks-if-your-sites-are.htmlDelete
- AnonymousApril 9, 2014 at 12:39 AM
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
- AnonymousApril 9, 2014 at 3:46 AM
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. ~ MahaloReplyDelete
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? ThanksReplyDelete
and sorry to be ignorant....Replies
- AnonymousApril 9, 2014 at 6:42 AM
me too - it would be great to have an easy guide like Fixing Heartbleed for Dummies. ThanksDelete
To be on a safe side, yes change your master password.Delete
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.
@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).Delete
@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.
- AnonymousApril 9, 2014 at 9:17 AM
Just came here to say that you guys rock. Thank you!ReplyDelete
- AnonymousApril 9, 2014 at 10:03 AM
Can you integrate the heartbleed check into my security check of lastpass, I have over 400 sites I need to check!ReplyDeleteReplies
Otherwise it's going to take weeks,i.e., it won't happen
(thanks for the quick rollout of that check, btw)
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
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
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
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
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
- AnonymousApril 9, 2014 at 10:28 AM
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.ReplyDeleteReplies
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.htmlDelete
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.ReplyDeleteReplies
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
This comment has been removed by the author.Delete
Does Two-Step Authentication help here?ReplyDelete
- Alex van der BaanApril 9, 2014 at 11:28 AM
Thank you for this post,ReplyDelete
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?Replies
Alex, I think you miss the point.Delete
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!
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.ReplyDelete
Here's a mockup:
- AnonymousApril 9, 2014 at 12:33 PM
YES!!!!!!!!! Lastpass do this. I commented on something above asking for something exactly like this mockup.Delete
Thanks for the suggestion; you may also want to run the security check now (LastPass Icon > Tools > Security Check) for more actionable results.Delete
This comment has been removed by the author.ReplyDelete
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?ReplyDeleteReplies
Marc, to do this would mean giving LP access to your decrypoted vault.Delete
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!
It could be a tool you run when logged in to your account.Delete
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
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?ReplyDeleteReplies
- AnonymousApril 9, 2014 at 3:57 PM
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:ReplyDelete
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.Replies
- AnonymousApril 9, 2014 at 4:03 PM
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.Delete
Be sure to look up the ip on this one and not the original comment.
You're welcome to send details to security[at]lastpass.com and we can take a look.Delete
- AnonymousApril 9, 2014 at 9:43 PM
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?ReplyDeleteReplies
There's no risk, as we've reissued our certs and updated the affected OpenSSL.Delete
- AnonymousApril 10, 2014 at 10:23 AM
What was the risk in the two years before the update?Delete
- AnonymousApril 10, 2014 at 12:41 AM
I dont get this heartbleed thing can anyone sum it up in a paragraph for meReplyDeleteReplies
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
- AnonymousApril 10, 2014 at 1:51 AM
Good advice. My password manager Sticky Password (www.stickypassword.com) made a similar statement. I think you guys should join forces!ReplyDelete
You may want to contact the mashable team : http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/?utm_cid=mash-com-fb-main-linkReplyDelete
- AnonymousApril 10, 2014 at 5:26 AM
From what I can see, every effort is being made to make the whole process as secure as possible.ReplyDelete
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.
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)ReplyDeleteReplies
It's best to wait until you've confirmed that the site has updated their OpenSSL and reissued their certs.Delete
Ok thanks, I've run the security scan now, very useful indeed.Delete
Like many on here I'm glad I'm a LastPass Premium subscriber, the response to this issue has been second to none. Thanks.
- AnonymousApril 10, 2014 at 9:40 AM
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.ReplyDeleteReplies
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
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
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
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?ReplyDeleteReplies
If lastpass.com was using the openssl lib affected, why do we not need to change our master password?ReplyDeleteReplies
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
- AnonymousApril 10, 2014 at 11:09 AM
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
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
- AnonymousApril 10, 2014 at 11:27 AM
I don't think you understand how a MITM attack works. Explaining clearly the potential exposure from a vulnerability is not FUD.Delete
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
- AnonymousApril 10, 2014 at 1:17 PM
@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
Thanks Anonymous, that helps understand, you should work for lastpass!Delete
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?ReplyDeleteReplies
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
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 OpenSSLReplyDeleteReplies
Just an FYI, this site: https://www.ssllabs.com/ssltest/index.html, comes up with different results than your test.Delete
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
- AnonymousApril 10, 2014 at 12:08 PM
Are apps on your phone safe? If I used the Chase bank app, Citi app etc. Are those affected?ReplyDeleteReplies
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
- AnonymousApril 10, 2014 at 3:12 PM
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?ReplyDeleteReplies
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
- AnonymousApril 10, 2014 at 3:22 PM
Thank you!Delete
- AnonymousApril 10, 2014 at 6:21 PM
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
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
I was impressed with LastPast's response to the heartbleed bug so I signed up and became premium. Highly recommend to others.ReplyDelete
TNO with end to end encryption. It's the only way to surf!ReplyDelete
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


text:
Get on the list for product trends
coupons and special offers.
Say Good-Bye to your uncomfortable sexy bra and Hello to your New sultry wireless bra! Not only does it scream comfort, but it puts your bra bumps and bulges to rest. Cups form to your shape and its wireless design is comfortable, yet functional. Back, side, and underbust smoothing design slim you. There is nothing left to add to this bra.
OMG This is as heavenly made bra.I got this one and the strapless balconet bra and I have to say this are the best bras I ever had, i couldn't find my cup size in the chart but I love the design so much that I ordered one cup size less and it fits perfectly!!!! This bra is comfort and style all in one! Thank you Leonisa I'll order in other colors.
out of
found this review helpful. Did this review help? Yes
Your review has been successfully submitted
There was an error while submitting your review. Please try again.
To avoid altered measurements wear a fitted panty.
You have two options to choose the size of your panty
Was our size chart useful?
A comfortable fit with no panty lines is here! This boyshort provides a perfect fit that adjusts to your body. It has very few super flat seams for more comfort and no-show wear.
I love this boyshort, it's very comfortable and it adheres to the body.
out of
found this review helpful. Did this review help? Yes
This is HIGH quality. Love that it sits below belly button. Covers everything on backside. Took off 1 star because size chart is off. You need to go down at least 1 size. I have now 2 with 1st short too big. Bought panty from well known Intimate store that was more expensive. This is priced well for the great quality. Don't hesitate to buy!!!
out of
found this review helpful. Did this review help? Yes
If you would rather wear nothing to avoid panty lines, but want to wear something - this undetectable thong panty is perfect for you. Its laser-cut fabric seamlessly transitions to your skin without detection, and its DuraFit™ fabric feels light and soft. It is like wearing nothing, but with the comfort of wearing something!
I used to dislike thongs, but the second I put this on I was in love. I went to the gym with it, and forgot I was even wearing it. Also, it looks great on my butt and my boyfriend loves it.
it's very comfortable, no-show, I will buy lots of these!!!
This panty is hot!Its so pretty and I feel so sexy wearing it!

subset: commoncrawl


text:
Keep track of all the delicious Slow Food URBAN San Diego events here!
Categories ▾
−Oyster Mushrooms Cultivation11:00 am – 2:00 pm
Learn how to cultivate your own mushrooms!
From the event website:
Help us grow the farm and learn all you need to know to cultivate your own oyster mushrooms at home! You'll even be able take home a 1lb bag of mushroom culture upon completion of the workshop!
Cost: Cost is $30 per person ($25 for Friends of the Farm) to attend the workshop. You will make and take home your own starter kit of oyster mushrooms to grow at home!
Instructor: Chris Young, Owner & Founder, SoCal Shrooms
During the workshop you'll learn all about the life cycle of oyster mushrooms – how long they take to grow and when to harvest them. Participants will also have a hands on experience of starting oyster mushrooms from the beginning to the end. Be prepared to prep the growing medium which includes breaking the straw down into smaller pieces and pasteurizing it. We will then dry it, seed it, and pack it for growing. By the time you are done with the workshop you'll be ready to start growing them at home. Make sure to bring your favorite oyster mushroom recipe to share!
To register for this workshop, click here+11:00 amOyster Mushrooms Cultivation
−Slow Food Urban San Diego Food Justice Networking Night6:30 pm – 8:30 pm
Join us for the Food Justice Networking Night at Casa de Luz in North Park!
The event features guest speaker Erin Rempala, Associate Professor of Biology at San Diego City College and Manager of Seeds@City Urban Farm and City College's new sustainable urban agriculture program!
The cost of attendance is free, and food and beverages will be available for purchase from Casa De Luz, which features a plant-based and predominately gluten-free kitchen.
RSVP using our Facebook event page.+6:30 pmSlow Food Urban San Diego Food Justice Networking Night
−The Third Annual Permaculture Convergence!9:15 am – 11:00 pm
The third San Diego Permaculture convergence is being held September 8, 2012 at the Green Owl Sustainable Living Center. The event is taking shape, we have amazing speakers and a good mix of hands on and lecture style workshops lined up. However, your input and help is always welcome.
Find more information here: http://www.meetup.com/SanDiegoPermaculture/events/45330352/+9:15 amThe Third Annual Permaculture Convergence!
−An Evening of Aloha, in support of the Friscia Family4:00 pm – 8:00 pm
San Diego's chefs and mixologists are coming together at Stingaree to raise funds for the recovery of Stacy Friscia, wife of Chef, Antonio Friscia. After a severe accident on the 4th of July, Stacy and the Friscia Family have a long road to recovery ahead of them. Funds from the event will help pay Stacey's medical expenses.+4:00 pmAn Evening of Aloha, in support of the Friscia Family
−Front Burner Fund Taco Fiesta12:00 pm – 4:00 pm
Local Chefs Build Their Finest Tacos to Support San Diego Culinary Community Hook, Line and Sinker
Sunday, SEPTEMBER 9th
WHO:The Front Burner Fund founders Maria Sparks of Cork & Platter & GRO Café, Julie Darling of Just Call Us Catering & Kitchen Rental, Flor Franco Urban Chicken and Ron Troyano of Alchemy Cultural Fare and several other premier chefs and restaurateurs will join together to cook and raise funds to assist back of the house restaurant staff with emergency medical bills.
WHAT:TACO PARTY – seventeen of San Diego's culinary talents will converge at Catalina Offshore Products for a tasting of So Cal's finest tacos. Premier chefs will bring their best interpretation, ranging from yellowtail to lamb belly, to raise money for the Front Burner Fund. Along with tasty tacos, side dishes and desserts are included in the cost of the event. Participants are invited to BYOB & BYOC (bring your own chair). Guests will cast their vote in a friendly taco competition as well!
Event sponsors include Specialty Produce, Newport Meats, Catalina Offshore Products and Bay Bird Inc PR.
WHY:The Front Burner Fund serves as a monetary benefactor to help cover emergency medical needs and healthcare costs of the independent "back of the house" culinary community.
Participating Chef's
Ricardo Heredia, Alchemy
Maria Sparks, Cork & Platter & GRO Cafe
Kim Moreira, Just Call Us Catering & Kitchen Rental
Flor Franco, Urban Chicken
Tommy Frailoi, Sea Rocket Bistro
Leah Di Bernardo, EAT Market Cafe
Ian Espanol, Sbicca's Del Mar
Eric Manuel, Firefly Restaurant & Bar at Dana Inn
Mike Arquines, The LAB Dining Experience
Olivier Bioteau, Farmhouse Cafe
Kate Murray, Miss Sushi San Diego
Hanis Cavin, Carnitas Snack Shack
Tommy Gomes, Catalina Offshore Products
Mitch Conniff, Mitch's Seafood
Hector Casanova, Casanova Fish Tacos
Ben Rollins, What's Ben Baking
Jenny Wenny, Jenny Wenny Cakes
buy your tickets here!+12:00 pmFront Burner Fund Taco Fiesta
−San Diego Tequila Trail 20122:30 pm – 6:00 pm
This event is the start of the 2012 Spirits of Mexico Festival, a week of activities centered around the spirits of Mexico. The Tequila Trail takes place in Old Town San Diego and features agave spirits paired with delicious food from Barra Barra Saloon, Café Coyote, Miguel's Cocina, Old Town Mexican Café, El Fandango, The Cosmopolitan, Casa Guadalajara, La Pinata and Rockin' Baja Lobster and more.
See event website for more details, tickets, and additional information about other festivities surrounding the festival.+2:30 pmSan Diego Tequila Trail 2012
−Slow Food's Fresh Food Picnic11:00 am – 6:15 pm
Slow Food Russian River is hosting a Fresh Food Picnic September 15 at Rancho Mark West, an historic Sonoma County Farm. The Picnic will celebrate Northern California's emerging food and farming talent and advocate for the Slow values of good, clean and fair.
Meet Carlo Petrini and Alice Waters while supporting Slow Food International's 1,000 Gardens in Africa Project.
This is a great opportunity to meet some of the founding members of Slow Food International and USA. Read more about the event here.+11:00 amSlow Food's Fresh Food Picnic
−18th Annual San Diego Festival of Beer6:00 pm – 11:00 pm
Drink beer and raise money to fight cancer! This is the 18th Annual San Diego Festival of Beer, sponsored by San Diego Professionals Against Cancer, featuring delicious beer from over 70 different breweries and live music in beautiful downtown San Diego.
Tickets are $35 for general admission, $25 for designated drivers.
See event website for more details.+6:00 pm18th Annual San Diego Festival of Beer
−Suzie's Farm Autumnal Equinox Dinner5:00 pm – 9:00 pm
Head down to Suzie's Farm for their annual Autumnal Equinox Dinner, featuring music, drinks, a 2-acre sunflower maze, and the culinary creations of local chefs Christian Graves, Joe Magnanelli, Javier Plascencia, and Lhasa Landry. A portion of proceeds benefits Slow Food Urban San Diego.
See the Suzie's Farm website for details.+5:00 pmSuzie's Farm Autumnal Equinox Dinner
−Tenth Annual Celebrate the Craft11:30 am – 3:00 pm
This premier Southern California event focuses on regionally grown ingredients and innovative cooking and winemaking.
See website for more details.+11:30 amTenth Annual Celebrate the Craft


text:
Already have a Hyatt Gold Passport number? Activate your account and create a profile
- Enjoy free nights with no blackout dates
- Receive special recognition
- Enjoy exclusive privileges
- English
Hyatt Gold Passport Assistance
U.S. & Canada, call 800 228 3360
More Contact Information
Hyatt Gold Passport Special Offers
Take advantage of free nights, bonus points and more on your Hyatt stays.
Free Nights
Free Time® is our reward to you. Enjoy free nights at Hyatt with as few as 5,000 Hyatt Gold Passport points and no blackout dates.
The tables below identify the number of points required for a free night stay at any Hyatt worldwide and a listing of each hotel within each category.
View Hotels by Category
Hyatt Gold Passport Points Per Night in Each Hotel Category.
Call 1-800-228-3360 or your nearest Hyatt Worldwide Reservation Centre to reserve.
Minimum 3-night award stay required at Hyatt, Park Hyatt, Andaz, Grand Hyatt, Hyatt Regency and Hyatt Resorts.
Award applies to two-bedroom suites at Hyatt House.
Not valid at Hyatt Place.
Cannot redeem for suites at participating M life resorts.
Hyatt Gold Passport points required per room per night.
|Single or Double Occupancy
|Standard Room
|Suite Night
|Additional Points per Person
|Hyatt Zilara Cancun
|Hyatt Ziva Los Cabos
Call 1-800-228-3360 or your nearest Hyatt Worldwide Reservation Center to reserve.
Maximum of four people per room.
Enjoy the fully appointed residential accommodations of Hyatt Vacation Club ™ Resorts. Condominiums feature a fully equipped kitchen, a master bath with jet/action spa tub, designer decor and a private balcony or patio (amenities in studio accommodations may vary)
Hyatt Gold Passport Points required per room, per night.
Call 1-888-36 HYATT to make your studio condominium award reservation.
Hyatt Vacation Club Locations
For your convenience, below is a complete listing of Hyatt Vacation Club locations.
- Hyatt Piñon Pointe (Sedona)
- Hyatt Carmel Highlands, A Hyatt Vacation Club Resort (Carmel)
- Northstar Lodge - A Hyatt Residence Club (Truckee)
- Hyatt Grand Aspen - A Hyatt Residence Club (Aspen)
- Hyatt Mountain Lodge - A Hyatt Residence Club (Avon)
- Hyatt Main Street Station - A Hyatt Residence Club (Breckenridge)
- The Residences at Park Hyatt Beaver Creek (Beaver Creek)
- Hyatt Siesta Key Beach - A Hyatt Residence Club (Sarasota)
- Hyatt Beach House (Key West)
- Hyatt Coconut Plantation (Bonita Springs)
- Hyatt Sunset Harbor (Key West)
- Hyatt Windward Pointe (Key West)
- Hyatt High Sierra Lodge (Incline Village)
- Hyatt Wild Oak Ranch (San Antonio)
Puerto Rico
- Hyatt Hacienda Del Mar (Dorad)
For all Hyatt Gold Passport Award reservations, photo identification and a credit card guarantee/cash deposit for all incidentals will be required at check-in. Complete Terms and Conditions