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.

Your 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

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.

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.

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.)

Thanks for posting this so quickly, Jeff! I was at Yoga when you wrote this so I didn’t have a chance to proof read it and give you feedback before it went live. So here I am desperately looking for a typo so I can keep my editor job here, but dang, I couldn’t find any. ?

In all seriousness, if anyone is interested in knowing more of the details before Jeff’s followup post is ready, you can read the Transport Security section of our 1Password White Paper, including this bit:

Because parts of systems can fail, it is useful to design the overall system so that a failure in one part does not result in failure. This approach is often called defense in depth.

As great as the White Paper is, I’m really looking forward to seeing Jeff’s upcoming post that elaborates on all these layers and how they work together to protect user data. ?

I would blindly follow the 1Password team to the ends of the earth and back, as I believe that’s how secure our data is. You guys are always a step ahead and I sleep better at night for it. Thank you Dave and Jeff and your fantastic team. Polly, devotee for a loooooong time.

This is what I really appreciate about your team. When I first read about this on Wirecutter, I immediately wondered if I needed to change the master password. I saw that a link was already posted in their comments section by you. Your post told us right away what I think most of us were wondering. Then you provided more information. The irony to me is that the more technical insight you provide the better I feel about using your secure services (I see a number of commenters feel the same way). The thing is, I don’t feel that I need to know everything about how it works, I just need to trust that Agilebits cares and know what to do. I’ve been a customer for many years now and this responsiveness (like with the recent certificate issue), along with the robust features of the software, are what keep me a customer as well as a confident endorser to those I tell about 1Password. As always, keep up the great work!

Thank you for your incredibly kind words Phil, they mean a lot to me. And thank you so very very much for recommending 1Password to your friends and colleagues. We live and breath by word-of-mouth and wouldn’t be here without awesome customers like you. ?

You’re right though, it’s absolutely dizzying to think how crazy things are for all the non-Zero Knowledge Systems out there tonight. Those developers need a hug and a coffee. ? And a nudge to change their apps to be zero knowledge. ?

I’m curious what API stuff 1Password is doing – I use it without any of the Teams features, or any shared Vault stuff, just regular old iCloud syncing between my iOS and Mac devices. I had tended to assume that that meant I wouldn’t be talking to 1Password servers at all.

I’m sorry for the confusion. If you are not using a 1Password account (but instead are synching your data on your own through Dropbox or iCloud) then none of this is relevant to you. Just as we have done with with 1password.com accounts, the security of your data synchronization with Dropbox or iCloud does not depend on the secrecy of HTTPS.

Yesterday’s news isn’t about Dropbox or iCloud, but if it were our answer would be largely the same: We have designed 1Password to keep your data secure even if the security of the connection between you and whatever sync service you use is compromised.

So while that is generally true, we are getting a lot of questions about CloudFlare, and so the blog post focuses on that and on that technology instead of stating thing more generally for all sync services. This is so that we can give a direct, clear, and useful answer to those who are asking.

It’s too soon for me to say for sure what will be happening with Watchtower and sites that are using CloudFlare. I’ve been typing a lot so far this morning so please allow me to copy and paste an answer I wrote to The Ponderer earlier today:

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.

I’m sorry to mask your link but I think it’s an over reaction to recommend every password be changed on every site that uses CloudFlare. As much as I like your script and how crafty you were to recommend our users only export the URL field of their Logins, at this time I just don’t believe we should be recommending people do this for every website[^1].

Instead we’re adding sites that are known to be affected to Watchtower and we’ve added some 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.

In theory we could add every single website to Watchtower, but it doesn’t seem to be an effective way to do things here. 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;

[^1] Of course the other concern is your script changes between the time I looked at it and when one of our users downloads it. I’m sure you would never do something like that, but we must be cautious in everything we publish in these comments.

Days like today I wish I lived in Austria or was at least visiting so I could have more time to respond to all the lovely comments here. By time I woke up here in Canada I was well over 20 messages behind, and they’re coming in as fast as I’m answering them! I guess I know what I’ll be doing all day today – good thing I enjoy it ?

I’m glad Jeff’s post was able to calm you down this morning. He does have a soothing way with words. ?

As for Watchtower, we absolutely will be adding affected sites. In fact we’ve added some 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.

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.

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.

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…)

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:

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.

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?

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:

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.

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.

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.

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:

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.

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:

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 ?

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.

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.

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.

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?

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.