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 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. Pete Wilson
    Pete Wilson says:

    However, I would still question the wisdom of using a third party service such as CloudFlare or even third party CDN services in what is apparently the API path for 1Password. And why would HTML optimization or obscuration need to be active for an API?

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Those are great points, Pete.

      Let me take your second question first. No HTML optimization is needed for our traffic, but the CloudFlare bug meant that when it was performing HTML optimization for site A that it fronts for it would occasionally spew in traffic for site B that it also hosts for, even if site B doesn’t need any optimization. So that is how some of our HTTPS traffic could end up being exposed. (Though again, exposure of that traffic does not put 1Password data at risk.)

      Using a service like CF has security implications, but so does not using such a service. These choices are “security versus security” trade-offs. Imagine if a major security bug had been found in nginx but users of CloudFlare were protected because their self-managed vulnerable (in our hypothetical) nginx servers were safe because they were hidden behind CloudFlare. Our move away from CloudFlare last week (the timing was entirely coincidental) involved a careful consideration not only of the security threats that having a third party in there introduces but also on the security benefits that CloudFlare offers.

      In our case, the biggest risk of using something like CloudFlare is largely obviated by our design that is meant to stay secure even when TLS fails. If we had been more dependent on the secrecy of TLS, we would have weighed certain risks differently.

  2. Sean DMR
    Sean DMR says:

    Are customer details on affected? Any purchase information from software licenses etc?

    The Agile Bits domain is listed as potentially affected on the super helpful GH repo, but doesn’t have the same not-affected note like the domain.

    • Dave Teare
      Dave Teare says:

      Hi Sean,

      That’s a great question! In our excitement to make it incredibly clear that your 1Password data was safe and continues to be safe, we didn’t have a chance to talk about our other websites and the customer information that we do (and do not) store. Now that the hysteria has calmed down and I have had time to breath, I’m happy to talk about this ?

      First and foremost, we have multiple websites but the only ones that store any customer information and used CloudFlare during this period of time are and The unencrypted customer information on includes names and emails for those who purchased standalone licenses, and has names and email addresses for our 1Password memberships. Neither of these sites store any credit card information. We use Stripe for all payment processing and Stripe was not and is not using CloudFlare.

      As for itself, we used CloudFlare there for a very small period of time, perhaps for a few weeks while we experimented with CloudFlare’s features. In theory any purchase made during this time may have exposed the customer name, email, and state/country information (we keep the later for tax purposes but avoid storing full address information for privacy reasons).

      The majority of our purchases happen through other stores so the number of customers potentially affected by this is quite small. And the likelyhood of any of these transactions being affected by the CloudFlare incident is incredibly rare. From 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).

      Now just because this is incredibly rare doesn’t mean we should ignore the issue that some personally identifiable information could have been leaked. But given the fact this did not include any payment information or other critical, plus the fact you are likely able to find more information about someone from a phone book, I think we’re safe to say we’re good here.

      Thanks again for the great question. Take care and enjoy the rest of your weekend.


    • Dave Teare
      Dave Teare says:

      Hi Daryl,

      I’m sorry for the confusion. It is indeed very natural for you to be confused given all the Tweets flying around. The biggest issue is the popularity of 1Password and the incredibly important secrets we keep make us a wonderful addition to any clickbait headline. It helps people pay the bills but it’s very unnerving to say the least. I guess I now know how Apple feels and I should be honoured that we have this privilege ?

      Thankfully there are some really good journalists remaining like Glenn Fleishman who write informative headlines instead of clickbait ones like this one in MacWorld:

      Cloudflare data leakage doesn’t reveal 1Password secrets

      Now to be clear, I have the utmost respect for Tavis and he does some absolutely critical and amazing work, and 1Password was indeed using CloudFlare, so I’m not saying he was juicing his headlines. But other people ran with his headline and assumed the absolute worse without doing any research whatsoever. It created a ton of noise and hysteria.

      All this noise can be deafening so if you’re only slightly confused, than you are doing better than most! ?

      Take care Daryl, I hope you have a good weekend. Thankfully the hysteria has died down considerably so I might be able to enjoy the outdoors today at some point. Might. ?


  3. Toby M
    Toby M says:

    Probably a silly question, but if i use a VPN to access the internet, this counts as a 4th layer? Has this protected my other passwords too or should I be looking at reseting everything?


    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi Toby,

      First of all, you do not need to be resetting all of your passwords. Keep an eye out for notifications from other services that have been using CloudFlare to see if they recommend a password change, but 1Password is unaffected.

      The VPN protects only protects your traffic within the VPN. But when you log on to something that is outside of your VPN and is vulnerable, that service would still be vulnerable.

  4. jamesontv
    jamesontv says:

    You guys are the best! Thanks for the quick reply. Gives me something to link to when panicky relatives or forum posters act like the sky is falling. (Nope, just the cloud!)

    • Dave Teare
      Dave Teare says:

      Thanks, James! I’m glad we could help ?

      Just for the record though, please don’t be picking on “the cloud”. Their a friend of mine and help me out big time each and every day. I couldn’t live without them! ? ☁️

      Take care,


  5. Vern
    Vern says:

    Can you explain what you mean when you say:

    “No secrets are transmitted between 1Password clients and when you sign in and use the service.”

    Isn’t that what a cloud-based password manager does…send secrets back and forth to your server?

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi Vern, that should be “no unencrypted secrets”

      During sign in, no secrets are sent at all. When you use the service, all of your secrets are encrypted. So it means that there really wouldn’t be any harm if we actually just used unencrypted HTTP instead of HTTPS. We use the encryption of HTTPS as simply an extra layer.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      You are very welcome, Eric. I’m glad that we got this post out quickly (even if it has taken us more time to respond to comments).

      And thank you for using the proper second person plural in English!

  6. Seth Talley
    Seth Talley says:

    Jeffrey, Dave – I sincerely appreciate that everything internal to 1Password is secure. Unfortunately for me, I have passwords that 1password fills out on webforms on at least a few of the affected websites. Which websites? Well, all I need to do is run a grep command on a 22mb zip file and then search through “4,287,625 possibly affected domains.”

    When Heartbleed hit, y’all did your customers a solid by highlighting websites within our database that had been compromised. Will you please do that again, or explain in terms to people who are not comfortable running grep commands on 22mb zip files why our security doesn’t depend on you doing that?

    • Dave Teare
      Dave Teare says:

      Hi Seth,

      I’m sorry it’s taken me a full day to respond. I needed to sign off “early” yesterday (just a 10 hour day) as my wrists were on fire ? from RSI.

      In the interest of keeping my RSI in check, I’m going to copy and paste a reply I gave earlier today to John:

      You bring up a great point. Some people have raised similar questions in other comments, and other folks have asked about our Watchtower service and what are plans are there with respect to CloudFlare. I’ll combine my previous answers into one an elaborate a bit here.

      First and foremost, it is 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 affected during this CloudFlare incident.

      This is absolutely a concern. The question then become is this likely to have happened, and if so, should we alert all 1Password users to change their login passwords for every website that relied on CloudFlare?

      Depending on those answers we could add those sites to our integrated Watchtower service so users who have logins for those site could be alerted. Let’s dig in to see what sites we should be (and are) adding to Watchtower.

      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 past communications could be easily decrypted for a particular website. From everything that I’ve read, no private certificates from CloudFlare nor any website where leaked in this incident. So that greatly narrows the available attack surface.

      For Heartbleed we added all affected sited to our Watchtower service so users could see the sites that required their passwords changed. In the case of CloudFlare, 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. Several have been added already.

      In theory we could add every single website that relied on CloudFlare to Watchtower, but it doesn’t appear like an effective approach here. CloudFlare protects a huge portion of the internet, supporting millions of websites (it’s smaller than those affected by Heartbleed, but still very significant). And from what we can tell, it appears that only a small percentage of those sites 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. So we need to keep looking to get a sense of how many domains were affected. Some more numbers 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 important aspect of this discussion 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.

      Now with all that said, if you have a website that’s super critical to you and you’re losing sleep at night over the mere possibility that you could have been affected, I doubt any set of numbers or statistics will make you sleep nearly as well as simply changing your password for that site. Passwords are free to create and easy to update, so by all means don’t let me tell you not to. If it would help your inner peace, just go ahead and update it. ?

      I hope that helps. Take care and enjoy the rest of your weekend.


  7. oscar
    oscar says:

    What about the web version (as opposed to the native clients)? When I click to reveal a password, it is shown in the browser in cleartext, transmitted over https. And even before clicking to reveal, it seems to be embedded in the javascript. I don’t see how those additional security layers add any protection here.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi Oscar,

      Despite appearances when using the web client, your passwords are not coming in clear text from our server. They are being decrypted locally in your browser by the JavaScript that is delivered from our server.

      By the time you look at it (and the JavaScript has already performed the decryptions) it is all blended together, but if you open up a debug console in your browser and check carefully, you will see that what is sent by us really is encrypted the way that we say it is.

      I hope that this clears things up.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Such a simple question and such a complex answer! My first draft of an explanation of how HTTPS is used during first sign-up (instead of sign-in) and what gets transmitted then and what the risks from exposure are took more than 1400 words.

      So I might end up putting that in a whole other blog post or something. Signup is different and the reasons that users don’t need to worry or do anything are technically very different than the reasons that apply to sign-in and use. But explaining what happens and why people don’t need to do anything or change Master Passwords is much more complicated to explain.

      So I will get to it, but perhaps it will come in pieces or perhaps in an entirely separate blog post.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      So Steve, here is my much fuller answer to your deceptively simple question.

      The very astute reader may have noticed that I wrote about what happens during sign-in and use of 1Password. I did not say anything about what happens during sign-up. It’s not that anything particularly bad happens then, but it is much more complicated to explain.

      Let me make it clear that during signup, you are still not sending your Master Password or secret Account Key over HTTPS. Those stay completely local to your device. (You pick your Master Password and the 1Password client generates the secret Account Key in your browser on your machine.) But the information that is transmitted on first signup is a bit more sensitive than the information transmitted during signin and use.

      First of all, during first signup your name and your email address are transmitted to us only using HTTPS. So someone who breaks the HTTPS layer and is listening in during signup will be able to know that you are signing up with that name and email address. As we haven’t even had the chance to count how many people signed up during that time, we haven’t worked out a notification policy to tell people that their names and email addresses may have been leaked if an attacker was exploiting the bug at the time.

      Note also that credit card information is never sent to us, so that is entirely unaffected. Stripe, our credit card processer, does not use CloudFlare.

      SRP verifier

      Now here is where it gets tricky. When you first sign up, your system computes a pair of authentication secrets from your Master Password and your secret Account Key. This is why we call this “Two-Secret Key Derivation”. These are known as SRP-x (which stays locally on your machine or is recomputed when you signin again) and the SRP verifier. The verifier is mathematically related to the SRP-x and gets sent to the server protected only by HTTPS. So verifiers could have been captured.

      Now I did call the verifier a “secret”, but let me first explain what cannot be done with a captured verifier.

      1. Knowledge of the verifier cannot be used to sign in. Sign-in requires the SRP-x (or the ability to compute the SRP-x).
      2. One cannot compute the SRP-x from the verifier. They are mathematically related, but while it is easy to compute the verifier from x (and some non-secret information), it would take many times the age of the universe to compute x from the verifier. (Although the actual computations are different, at an abstract level the math is analogous to what I’ve described in Mind your Ps and Qs)
      3. One cannot compute a Master Password or Account Key from the verifier (or from x). It would take many times the age of the universe to make a dent in such a computation. In this respect, the verifier is like a password hash.
      4. Neither the SRP-x nor verifier can decrypt your data. They are only used for being able to sign in
      5. .

      So exposure of the SRP verifier, which is only sent during first registration over HTTPS is not a big deal, but it is something that we do try to keep secret.

      Where it gets trickier

      OK, so I’ve talked about what an attacker cannot do with an SRP verifier, it is time to talk about what they can do. This is where the tricky part gets even trickier. This is because we have additional defenses aimed at thwarting an attacker who might get a hold of SRP verifiers.

      It is hard to explain what our solution is without people already having an understanding of what the problem is. As I correctly said, it is impossible to compute a Master Password from the SRP verifier, but that isn’t entirely the end of the story. I think I am going to have to just point everyone to Is Password Cracking Infeasible? as a starting point in which my minor quibble about the wording of someone’s announcement gave me a launching pad to talk about some deep problems in defending against password cracking.

      The short version of what I am about to say is that just as we designed 1Password so that it would remain secure if HTTPS failed, we also designed it to remain secure even if someone captured the SRP verifiers from our server (or from an HTTPS failure). We have all seen cases where some server has been breached, the password hashes acquired by bad guys, and people being told to change their passwords before the bad guys can crack the hashes. Well, we didn’t want to be in that position even though SRP verifiers are a lot like password hashes when it comes to being useful for password cracking.

      Now we have done all of the usual things in deriving the SRP x (and the verifier computed from the x) from a password. There are 100,000 rounds of PBKDF2-HMAC-SHA256, there is a sixteen byte random salt. And, of course the computation of the verifier from x involves a couple of big computations as well (raising a small number to a 77 digit number all modulo a 1200 digit number among other computations.) But as I argued in that blog post that you have all read and digested, all “the usual” stuff only gets you so far.

      “Only so far” wasn’t good enough for us. We wanted the SRP verifiers to be useless to an attacker, even an attacker that was going to pour enormous resources into cracking passwords.

      Our solution is your secret Account Key. It is a secret that is stored on your devices and gets combined with your Master Password to derive your SRP-x (from which the verify is computed). This is why you need to print out a copy of your Emergency Kit with your Account Key on it. If you lose your Account Key or forget your Master Password bad things happen.

      Your secret Account Key is 128 bits of random gibberish that is created by your client when you first sign up. Think of it as being appended to your Master Password (that isn’t how it works, but it is a useful way of thinking about it now.) By adding it to a Master Password it makes the combined password completely unguessable.

      What all these means is that without your secret Account Key, the SRP verifier is entirely useless for trying to guess your Master Password. Now some of you (is there anyone still reading at this point?) may be noting that the Account Key isn’t all that hard to capture if you break into an individual’s computer because of how 1Password clients need to store it on local devices. But – and here is the awful beauty of the whole thing – an attacker who can read your computer disk (to get your Account Key) doesn’t need the SRP verifier to launch a Master Password guessing attack. This is why you still need to have a strong Master Password despite the Account Key. Your Master Password is your defense if someone steals your data from you. Your secret Account Key is your defense if someone steals your data (including SRP verifier) from us.

      An even trickier case

      There is one other thing an attacker could theoretically do with the the SRP verifier if they were able to put a whole bunch of other things in place. But even if they succeeded at that, the worst they could do is disrupt your usage of 1Password; they could not use it to decrypt your data. And I’m exhausted at this point, so I’m going to leave that for another time.

      And in conclusion

      We do not believe that anyone’s SRP verifier was captured, but we can’t rule it out. But just as we designed 1Password to not depend on the secrecy of HTTPS, we also designed 1Password to remain strong even in the event of data like the SRP verifier being captured.

  8. Dave
    Dave says:

    This entire discussion is about the 1Password apps, not browsers, correct?

    When my browser signs into, it can see a list of every password in my vault. If I understand correctly, that session is only encrypted with TLS/SSL, not triple-encrypted. If it were triple-encrypted, browsers wouldn’t be able to read it, right?

    Can you clarify if sessions were triple-encrypted, whether cloudflare touched any of those sessions, and whether I should expect the parts of my vault that showed up on my browser screen last month to be living in plaintext on a caching server?

    Thanks, and sorry if I’m missing something obvious.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi Dave, you are missing something, but not something obvious.

      When you have stuff show up in a web page, it is very natural to think that everything you see there is what has been sent from the server you are connected to. And so when you see your decrypted passwords in your web browser when connected to your account on the obvious conclusion is that the decrypted content you see was sent from the web server. But sometimes what is obvious is wrong.

      Our web server sends you a bunch of JavaScript, which defines a program that runs in your browser. This kind of thing is typically called a “web app”. The 1Password web app is a program that is running locally within your web browser on your machine. The web app does talk to our server, but it uses the same protocols for talking to our server as the native 1Password apps do. The web app logs in the same way (using SRP) and the communication between the web app and our server is encrypted with all three layers. All of the decryption happens in the web app running in your browser on your machine.

      None of this is obvious, none the less, that is how it works.

  9. Ian
    Ian says:

    What about people who use 1password in their browser occasionally (e.g., from machines that do not have a 1Password Desktop Application)?

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      That is a great question, Ian.

      When you use in your web browser by visiting (this is separate from using the 1Password browser extension), what you get from our server is a program written in JavaScript (Actually it is written in TypeScript and translated to JavaScript, but that is another story.) That JavaScript program, called a “web app”. That web app runs on your machine in your browser on your computer. It talks to our server the very same way that the native clients do.

      So the web app, running on your machine in your web browser signs in to our server the same way that the native apps do, and it fetches encrypted data the same way that the native apps do. And it decrypts that data with your keys on your local machine the same way that the native apps do.

      I know that it appears that the decrypted data is coming from our server given how we think about web pages shown in our browser, but sometimes appearances can be deceiving. And so the secrecy of the HTTPS session is just as irrelevant when using the web app as it is when using the web client.

      There is, however, one important difference that isn’t relevant in the CloudFlare problem. Although the secrecy of the HTTPS session doesn’t matter for the security of 1Password whether run through the web app for a native client, the integrity of the HTTPS session does matter for the web app. If an attacker can do more than just read the HTTPS traffic (and reading is all that was possible in the CloudFlare case), then there is no potential for harm. But if the attacker can tamper with the HTTPS connection then the attacker might be able to maliciously modify the web app itself.

      This is one of the reasons why we are so strict about our TLS settings. We insist on the most modern and most secure browsers and we set the service to use settings like HSTS to prevent certain sorts of possible attacks on TLS.

      Because the web app can’t be code signed the same way that the native apps can be, it does mean that when using the 1Password web app (using for example) its security does depend on the integrity of the HTTPS session. Note that the 1Password browser extension (unlike the web app) is code signed, so neither the 1Password browser extension nor the 1Password native apps depend on the integrity of the HTTPS sessions.

  10. Jeffrey Goldberg
    Jeffrey Goldberg says:

    For those trying to follow some apparently conflicting reports on Twitter, the short answer is that our Session IDs are not intended to be secret. Session keys are. I will explain what all of that means below, but distinction (or failure to know that distinction) has led to some confusion in some technical discussion.

    As mentioned, we talk about three layers of encryption when your data is sent back and forth from your client and our server.

    The most important layer is that your data is encrypted with keys derived from your Master Password and your secret Account Code. Those keys never leave your device. This is the layer of encryption that protects you even if the data we store on our servers were to be breached (not something that has happened).

    There is the HTTPS layer. That is what was broken through the CloudFlare bug. We have designed 1Password to not depend on the secrecy provided by HTTPS.

    Details about the middle layer

    The middle layer is the hardest to describe (and it not yet properly documented in our white paper). Our API (the protocol used between the clients running on your machine and the service if you are using accounts). It is this middle layer that the particular discussion I’m alluding to centers around.

    When you sign in, our server and your client go through a process of proving to each other who they are and they also work out a secret session key. Through the magic of SRP, they do this without transmitting any secrets. Now they also establish a session ID. The session ID is not secret. (Note that “session key” is a meaningful term at the HTTPS layer as well, but that is not the layer we are talking about here. We are looking at this as if HTTPS is stripped away.) Session keys and session IDs are only used for your particular log in session.

    That SRP establishment of a session key remains secure even if someone is sitting in the middle of that conversation. Only our server and your client know the session key. (And only your client knows the keys to actually decrypt your data.) So a breach of CloudFlare would not expose the session keys used in our middle layer. It would expose the session IDs, but we don’t care. Session IDs are not intended to be secret.

    When your 1Password client talks to the server and when the server responds they may send data with what we call a payload. At our middle layer, we encrypt that payload using AES-GCM using the session key. (Again, this is in addition to the other two layers.) We are careful to use a different GCM nonce for each and every payload. Because GCM mode is an authenticated encryption mode, the recipients of those payloads can be certain that the sender of the payload had the session key.

    And so at this layer (as well as at the deepest layer) nothing at CloudFlare would ever see the encryption keys, though they might see the non-secret session IDs.

  11. Patrick Dinnen
    Patrick Dinnen says:

    Thanks for the quickly shared reassurance. One question, does your illustrated bear know that it’s undermining the message of the post? Clearly neither of the lower two umbrellas are sufficient to protect the bear from a drenching if the first layer umbrella fails.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Oh, you have touched upon a very sore spot, Patrick.

      When Umbrella Bear was first unveiled more than a year ago, there were fierce debates about cuteness versus the accuracy of the analogy. And as with many of our fierce internal debates, it was settled on a beach with water pistols drawn.

      Here is a picture of our then security team under the protection of Umbrella Bear.

      1Password security under an umbrella bear

  12. Oscar
    Oscar says:

    You haven’t talked about accessing saved passwords through the web page instead of the native client. In that case the passwords appear to be embedded in the javascript and sent over HTTPS only, without any additional layers of protection. When I look at the javascript in chrome, I can see my passwords in plaintext. So unless the javascript was somehow transmitted encrypted and then decrypted in the browser, this was actually a security problem and users needed to change their passwords.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi Oscar,

      All of your data is decrypted locally in your browser on your machine. The JavaScript that performs that magic is transmitted from our servers, but your data is only decrypted on your system in your browser. I hope that this clears things up.

    • Dave Teare
      Dave Teare says:

      You’re very welcome, Niles! I’m glad I could help ?

      Take care and enjoy the rest of your weekend. The sun is shining here and after 15 more responses I’ll be able to go out and enjoy it. ☀️ Unless any more comments come in of course ?


    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      I’m sorry for the confusion. The difficulty is that explaining it more fully may lead to yet more confusion. There are a lot of details that I’ve had to skip over just to not get caught up in things.

      Your Master Password isn’t encrypted. But don’t worry it isn’t unencrypted either. Your Master Password gets processed through something called a key derivation function (KDF). One result of the key derivation function (and our KDF is a doozy) is a 256 bit number. That number, which we call the Master Unlock Key, isn’t stored or encrypted either. That key is used to decrypt yet another key (which is stored encrypted). And that key can be used to decrypt the keys that are needed to decrypt your data.

      There are reasons for all of these levels of indirection. And I haven’t given you the full description either. But the point is that your Master Password isn’t stored and so it isn’t encrypted. It gets processed when you enter it to to derive a key that it used to decrypt other keys that are stored.

      I really don’t know whether I have helped resolve your initial confusion or merely added to it. Our key derivation process is described in gory detail in our security white paper (PDF).

  13. Stefan
    Stefan says:

    You Guys Rock. Shit happens, which is very inconvenient if it hits the fan. But its this open honest communication and the incredible thoughts that went in to the design and maintenance of 1Password that gives reassurance to have chosen to trust the right service out there (not that there would be a lack of thereof nowadays). I and all my clients rest assured to know that you guys are on top of this and any future developments in security to make or keep the product as secure as it is and can be. Thanks for that! There is only one wish/feature I personally would look forward to. If 1PW would offer a automatic password change for at least the most common services/sites out there that would just be fantastic, especially in such cases and we can only expect them to increase if we look at breaches like yahoo, now this and many others. Thanks for the consideration.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Thank you so much Stefan!

      I was first attracted to 1Password (or 1Passwd as it was called back then) nearly a decade ago because of how open Dave and Roustem were about its design (and how much I liked that design). That openness is simply part of how we think security products and systems should be done.

      And to be open about things, it is really hard to get automated password changing done right. We’ve taken a few shots at it, but if it isn’t useful or reliable enough to work most of the time for most people it would end up creating more problems than it would solve.

      I was intrigued at PasswordsCon in Bochum Germany last December to hear a proposal to help make these things more useful. Here is a video of a talk by Peter Mayer on “Enabling Automatic Password Change in Password Managers Through Crowdsourcing” I think that the proposed scheme needs some substantial changes before it can be made to work, but I think it is a promising place to start.

« 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 *