Three layers of encryption keeps you safe when SSL/TLS fails

No 1Password data is put at any risk through the bug reported about CloudFlare. 1Password does not depend on the secrecy of SSL/TLS for your security. The security of your 1Password data remains safe and solid.

We will provide a more detailed description in the coming days of the CloudFlare security bug and how it (doesn’t) affect 1Password. At the moment, we want to assure and remind everyone that we designed 1Password with the expectation that SSL/TLS can fail. Indeed it is for incidents like this that we deliberately made this design.

No secrets are transmitted between 1Password clients and 1Password.com when you sign in and use the service. Our sign-in uses SRP, which means that server and client prove their identity to each other without transmitting any secrets. This means that users of 1Password do not need to change their Master Passwords.

UmbrellaBearYour actual data is encrypted with three layers (including SSL/TLS), and the other two layers remain secure even if the secrecy of an SSL/TLS channel is compromised.

The three layers are

  1. SSL/TLS. This is what puts the “S” in HTTPS. And this is what data may have been exposed due to the Cloudflare bug during the vulnerable period.
  2. Our own transport layer authenticated encryption using a session key that is generated using SRP during sign in. The secret session keys are never transmitted.
  3. The core encryption of your data. Except for when you are viewing your data on your system, it is encrypted with keys that are derived from your Master Password and your secret Account Code. This is the most important layer, as it would protect you even if our servers were to be breached. (Our servers were not breached.)
121 replies
« Older CommentsNewer Comments »
  1. olli
    olli says:

    Thanks for the blog posting. To say things clear, I’d prefer if you could mention that you’re indeed using CloudFlare in your services. Currently that’s not clear there.

    Reply
    • Dave Teare
      Dave Teare says:

      Hi Olli,

      That’s a fantastic point. No where in the post do we mention if or how we are using CloudFlare. We have indeed been using CloudFlare.

      We enabled CloudFlare for a while to take advantage of it’s web application firewall (WAF) and it’s DDoS protection features. We have been slowly but surely replacing these features with ones provided by Amazon Web Services, and are no longer using them for that purpose. At the moment we’re still using CloudFlare as our DNS provider. However, we have had plans in the works for months now to move our DNS services to another provider so once the dust settles from that migration we won’t have CloudFlare as part of our infrastructure any more.

      I think it’s important to point out that our decision to move away from CloudFlare has nothing to do with this incident. CloudFlare provides an invaluable service, and the internet is a better place as a result. They are one of the good guys and have contributed a lot to the open source community.

      This comment from Hacker News thread summarized things up quite well I thought:

      I’d guess it’s because of the crude and reductive way you describe the service cloudflare provides. I don’t know what type of programming you do, but many small services don’t have the infrastructure to mitigate the kind of attacks cloudflare deals with and they wouldn’t be around without services like this.

      I don’t like the internet becoming centralized into a few small places that mitigate DDOS attacks like this, but I like the alternative (being held ransom by anyone with access to a botnet) even less.

      I’m going to take a more even handed approach than what you’re suggesting. Any time you work with a service like this you risk these kinds of things – it’s part of the implicit cost/benefit analysis humans do every day. I’m not ready to throw out the baby with the bathwater because of one issue.

      I hope that helps clear things up on how we are and have been using CloudFlare. And I’m sure Jeff will be talking about this in more depth during his followup post, so stay tuned for that as well.

      Take care,

      ++dave;

  2. drgardner
    drgardner says:

    Thanks for a very informative post.

    As I read it, this seems to apply to information communicated via 1Password (i.e., for database synchronization across devices).

    If I understand correctly, there is still some possibility — rather remote — that a password submitted to a site via 1Password might have been exposed. So it might be prudent to rotate at least critical passwords? (In my case, at least, it’s been awhile since I’ve done so, which means it’s probably about time anyway…)

    Thanks,

    Reply
    • Dave Teare
      Dave Teare says:

      You’re right, once the data leaves 1Password and is placed into the browser, the only thing protecting your username and password when it’s submitted to the website is TLS/SSL, which is what was compromised here.

      With Heartbleed from years ago, it was the server’s TLS/SSL certificate secret that (potentially) exposed, and this caused a great deal of fear and uncertainty as it meant all future (and in many cases past) communications to be easily decrypted.

      As I mentioned in my reply to LM earlier this morning, I suspect we will be adding several sites to Watchtower as a result of this issue, but it really is too early to tell for sure. I’ve read reports that no SSL/TLS certificates were leaked, and if this is true, then the issue is much smaller than Heartbleed. If SSL/TLS certificates were leaked, then I suspect we’ll be writing up a new post similar to the Heartbleed one from 3 years ago:

      Heartbleed: Imagine no SSL encryption, it’s scary if you try

      Long story short, I’ve spent most of my time looking at this issue through the lens of how it affects 1Password (thankfully our data was not at risk) so it’s hard for me to comment authoritatively yet. Give myself and my team some time to analyze the news as well as the affected websites time to understand the impact to them and we’ll be sure to post some more information once its available.

      Take care,

      ++dave;

    • Dave Teare
      Dave Teare says:

      Thank you! ❤️

      It’s always great when we get to show off our design, albeit I do wish we didn’t need to have events like CloudBleed and HeartBleed to get people excited about reading our White Paper ?

      ++dave;

  3. The Ponderer
    The Ponderer says:

    Thanks for this. So I don’t need to change my master password in 1Password. But couldn’t this leak still expose my individual site passwords, assuming they are transmitted from my side to the sites that that are hosted on Cloudflare? For instance, Fitbit.com was listed. If I store my Fitbit password inside my 1Password vault, and use that to login, couldn’t this code error still expose that Fitbit.com password? Or is it inherintly “safer” because I was using 1Password to logon to Fitbit.com?

    Reply
    • Dave Teare
      Dave Teare says:

      This is a very good point. It’s certainly true that once your data leaves 1Password and is placed into the browser, the only thing protecting your username and password when it’s submitted to the website is TLS/SSL, which is what was compromised here.

      With Heartbleed from years ago, it was the server’s TLS/SSL certificate secret that was (potentially) exposed, and this caused a great deal of fear and uncertainty as it meant all future (and in many cases past) communications could be easily decrypted.

      As I mentioned in my reply to LM earlier this morning, I suspect we will be adding several sites to Watchtower as a result of this issue, but it really is too early to tell for sure. I’ve read reports that no SSL/TLS certificates were leaked, and if this is true, then the issue is much smaller than Heartbleed. If SSL/TLS certificates were leaked, then I suspect we’ll be writing up a new post similar to the Heartbleed one from 3 years ago:

      Heartbleed: Imagine no SSL encryption, it’s scary if you try

      Long story short, I’ve spent most of my time looking at this issue through the lens of how it affects 1Password (thankfully our data was not at risk) so it’s hard for me to comment authoritatively yet. Give myself and my team some time to analyze the news as well as the developers of the affected websites time to understand the impact to them and we’ll be sure to post some more information once its available.

      Take care,

      ++dave;

  4. Neil
    Neil says:

    I can’t say I’m overly happy at 1Password’s response to this.

    The lead researcher, Tavis Ormandy, has confirmed that 1Password was leaking API data and they have the proof.

    Please read and respond to these two tweets:

    “Cloudflare have been leaking customer HTTPS sessions for months. Uber, 1Password, FitBit, OKCupid, etc.”

    https://twitter.com/taviso/status/834900838837411840

    “Yes, they [1Password] worded it confusingly. It was exploitable for months, we have the cached data.”

    https://twitter.com/taviso/status/834918182640996353

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi Neil,

      [updated response]

      I’m quite confident that Tavis was referring to CloudFlare’s blog post and not ours when he said “it was confusing”.

      We simply don’t know how much of our HTTPS traffic ended up in those caches or may also have been visible to anyone who might have been aware of this bug before it was fixed. We have made no claim on this matter. We have to assume that some data was exposed, and that is why felt it necessary to point out that even if that HTTPS traffic was leaked, it would not threaten 1Password security.

      But the point is that exposure of that data doesn’t matter because we have additional layers of encryption. That is we designed the 1Password so that we don’t need the secrecy of HTTPS during sign in and use.

      Take a look at Julie Haugh’s response to Tavis on Twitter:

      @taviso @dxgl_info The API isn’t security critical. I provide API pubs and UUIDs to BC pentesters. No breaches, even with $25K bounty.

      (We may up that to include a t-shirt)

    • Paula
      Paula says:

      Not to mention, that second tweet (“Yes, they worded it confusingly.”) doesn’t actually refer to 1Password, but refers to Cloudflare as the tweet is in response to someone asking about Cloudflare’s post-mortem. Hopefully that is reassuring.

    • Dave Teare
      Dave Teare says:

      I think you’re right, Paula, but I much prefer relying on our security design than trying to understand Twitter threads ?

      I love how Julie summarized things:

      The “BC” in her tweet was in regards to our Bug Crowd bug bounty program.

      ++dave;

    • Dave Teare
      Dave Teare says:

      That’s a great question, LM.

      I suspect we will be adding several sites to Watchtower as a direct result of CloudBleed, but it really is too early to tell for sure. I’ve read reports that no SSL/TLS certificates were leaked, and if this is true, then there should be no need to add any sites to Watchtower.

      If SSL/TLS certificates were leaked, then I suspect we’ll be writing up a new post similar to the Heartbleed one from 3 years ago:

      Heartbleed: Imagine no SSL encryption, it’s scary if you try

      Time will tell. I’ve only had a few hours to look at this myself, and to be honest, I’ve spent the majority of that time looking at it from the 1Password perspective. We’ll keep you posted once we have more time to analyze how other websites are (or are not) affected.

      ++dave;

  5. Dave
    Dave says:

    Would it be possible to confirm this (non) issue only affects users of the online 1Password.com service and has no impact on users of the (depricated?) 1Password Client?

    –Dave

    Reply
    • Dave Teare
      Dave Teare says:

      Good morning, Dave! ☀️

      As far as I can tell, neither Dropbox nor iCloud rely on CloudFlare in any way, so indeed they do not appear to be affected by this issue.

      However, it’s important to note that even if Dropbox or iCloud were using CloudFlare, encryption layer #3 that Jeff talked about in this post would have protected your 1Password data. Namely, your data would have been encrypted with your Master Password.

      Your Master Password is never sent to Dropbox or iCloud so even if these services experienced an SSL/TLS failure, your data would still be safe. You can read more about this in Jeff’s write up from a few years ago:

      1Password security doesn’t depend on SSL

      The part in this post that is only applicable to our new 1Password memberships is encryption layer #2: SRP. SRP, or Secure Remote Password, is an augmented password-authenticated key agreement (PAKE) protocol, which is a fancy way of saying we encrypt the data an additional time with a different encryption key. This additional layer of protection was added specifically to address any SSL/TLS weaknesses or compromises that may be found, and also allows provides mutual authentication between our servers and the clients attempting to connect to them.

      I hope that helps shed some more light on this issue. Please let me know ?

      ++dave;

  6. Vincent
    Vincent says:

    When are you planning to update the white paper ? Last update is dated from 2015 and still has sections without explanations. Anyway, good to know you are not affected, but this kind of scenario keeps me from putting my sensitive data into the “cloud”. Problem came from a typo in code, which anyone can make…even your devs.

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Oh, that is a very good question. The current internal draft of the white paper still has loads of unfinished sections and so would feel a bit embarrassing to publish (as lots still remains unfinished after all of this time), but it does have a number of improvements. So perhaps we should just release it soon instead of waiting to fill in more of those blanks.

  7. Jondb
    Jondb says:

    Hi – It turns out any password that I used for any other website using cloudflare is now probably sitting in some web crawlser’s logs.

    When will watchtower be updated to show me which URLs/Domains point to cloudflare so I can change my passwords?

    Reply
    • Dave Teare
      Dave Teare says:

      Hello,

      We have been adding affected sites to Watchtower already. We’re monitoring a number of news sources and we’re adding sites to Watchtower as soon as companies indicate their customers were at risk.

      The knee jerk reaction in situations like these is to add every website related to the service. In theory we could do this but CloudFlare protects a huge portion of the internet, supporting millions of websites. And from what we can tell, it appears that only a small percentage of those were ever considered affected.

      From some of the posts I’ve seen, only about 150 customers had data stored in public caches. Now this problem wasn’t just limited to caches, however, so that doesn’t tell the full story. The other numbers we can look at to get a sense of how many domains were affected can be found in CloudFlare’s incident report:

      The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).

      It’s not easy to wrap our heads around these numbers as CloudFlare serves a lot of traffic so that 0.00003% of requests can quickly grow to affect a lot of domains, but I think it’s fair to say more people were not affected than those who were. It also appears that it only affected sites that used CloudFlare’s email obfuscation, Server-side Excludes and/or Automatic HTTPS Rewrite features.

      The other aspect of this is a website might not be relying solely on SSL/TLS to protect its information. That’s certainly the case for 1Password. I wouldn’t want anyone jumping to conclusions about how we use CloudFlare so I want to extend the same respect to other developers.

      So our plan is to continue to watch and listen. When developers or companies announce they were affected and recommend their customers change their passwords, then we’ll add those sites to Watchtower.

      Take care,

      ++dave;

  8. Daryl Knight
    Daryl Knight says:

    Hey guys, thanks for posting this so fast. So to clear up any confusion about this; I understand that our master passwords are safe. However, the actual passwords for those websites will still need changing, right?

    Reply
    • Dave Teare
      Dave Teare says:

      Hi Daryl,

      You’re right, your data is safe within 1Password as it wasn’t affected but once your data leaves 1Password and is placed within the browser, the only thing protecting your data en route to the server is TLS/SSL. So it could have wound up in the wrong place.

      To help track down the sites you need to change your password on, we have been adding affected sites to Watchtower. We’ve added several already in fact. We’re monitoring a number of news sources and we’re adding sites to Watchtower as soon as companies indicate their customers were at risk.

      The knee jerk reaction in situations like these is to add every website related to the service. In theory we could do this but CloudFlare protects a huge portion of the internet, supporting millions of websites. And from what we can tell, it appears that only a small percentage of those were ever considered affected.

      From some of the posts I’ve seen, only about 150 customers had data stored in public caches. Now this problem wasn’t just limited to caches, however, so that doesn’t tell the full story. The other numbers we can look at to get a sense of how many domains were affected can be found in CloudFlare’s incident report:

      The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).

      It’s not easy to wrap our heads around these numbers as CloudFlare serves a lot of traffic so that 0.00003% of requests can quickly grow to affect a lot of domains, but I think it’s fair to say more people were not affected than those who were. It also appears that it only affected sites that used CloudFlare’s email obfuscation, Server-side Excludes and/or Automatic HTTPS Rewrite features.

      The other aspect of this is a website might not be relying solely on SSL/TLS to protect its information. That’s certainly the case for 1Password. I wouldn’t want anyone jumping to conclusions about how we use CloudFlare so I want to extend the same respect to other developers.

      So our plan is to continue to watch and listen. When developers or companies announce they were affected and recommend their customers change their passwords, then we’ll add those sites to Watchtower.

      I hope that helps,

      ++dave;

« Older CommentsNewer Comments »

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *