Question about new feature on setting up new accounts

Hi everyone,
in the release notes of 1Password for iOS 6.7, a new feature is mentioned:

  • OPI-3993 - our new setup screen display all your accounts and only requires your master password

This was also mentioned in the release notes of 6.6.BETA-11:

  • 1Password.com Accounts can now be restored from the iOS keychain during the first run setup flow

Can anyone shed some light on how this is achieved technically without compromising security? I always assumed that the 1Password Account Secret Key should remain, well, secret. With this new feature it seems that the Secret Key is stored in iCloud Keychain.

Is that assumption correct? If so, can this feature be somehow disabled?

Thanks! :)


1Password Version: 6.7
Extension Version: Not Provided
OS Version: iOS 10.3.2
Sync Type: 1Password Account

Comments

  • I am wondering the exact same thing. Maybe agilebits assumes the iCloud keychain is a safe place to store the secret key?

    I hope it is possible to choose not to store the secret key in the icloud keychain.

  • I too was surprised a lot by that statement in the release notes. I think you need to get out an explanation soon. Was this just a poorly phrased release note?

  • AGKyleAGKyle AgileSupport 1Password Alumni

    I'm happy to answer any questions you might have about this new feature. We're pretty excited about it.

    Because 1Password now stores your account information in iCloud Keychain it makes it even easier to add your account to other devices and provides less dependency on having your Emergency Kit always readily available.

    What's stored

    If iCloud Keychain is enabled the item will be stored there. If iCloud Keychain is disabled a Local Items keychain takes its place and the item will be stored there instead.

    Note that these items do not store your Master Password when saved to iCloud Keychain.

    How it works

    Initial setup

    When starting over in 1Password, tap 1Password.com in the list of setup options. A list of accounts that were previously added will be shown.

    Add Account From Keychain

    Tapping the account will prompt for the Master Password of the account and upon successful entry it will add the account. If you have multiple accounts tapping each will allow you to add those as well.

    Account list

    You'll also see it in 1Password Settings > 1Password Accounts > Add Existing Account, where it will behave identically to the above workflow.

    It's safe to store your Secret Key in iCloud Keychain

    iCloud Keychain is a safe place to store your Secret Key because it's encrypted and only accessible to you, the user. Apple does not have access to the contents of iCloud Keychain, just the encrypted data.

    Your iCloud Keychain data is encrypted separately from your iCloud account as well. Also note the iCloud Keychain section here.

    The only app that has access to data 1Password stores in iCloud Keychain is 1Password. Programmatically no other application can access this data. And to quote Apple's documentation above:

    iCloud Keychain encryption keys are created on your devices, and Apple can't access those keys. Only encrypted keychain data passes through Apple's servers, and Apple can't access any of the key materials that could be used to decrypt that data.

    The Secret Key is primarily meant to protect you from anyone who gains access to your data from our server. It also protects you by strengthening your Master Password and providing two-secret key derivation. Learn more about how your Secret Key keeps you safe.

    Our advice is to keep your Secret Key secret and never share it publicly. Storing it in iCloud Keychain is private. Only you can access your iCloud account and know the Secret Code that’s necessary to access iCloud Keychain on a new device.

    A quick word about the Emergency Kit

    This is not a replacement for your Emergency Kit and you should still keep a copy of it in a safe place. But this does mean there's a little less reliance on it for day to day use making the Emergency Kit necessary more in situations that are actual emergencies.

  • pervelpervel
    edited May 2017

    Thanks for the clarification. It seems to me that this change does increase the attack surface for hackers to a degree. The only question is how much and if it's worth it. There is always a trade-off between convenience and security. It just seems to me that the added convenience here is very small. Both because dealing with the Secret Key is not very difficult and because you only do it when setting up a new device. So you have a "one-time", small convenience and a "long-time" lower security. I'm not saying it's a big deal. It just seems a bit unnecessary to me.

    Also, wasn't one of the "selling points" of the Secret Key that it is only stored locally on your device? It seems that you will need to modify that point. Now the Secret Key is in fact "in the cloud" - although importantly it's a different cloud than your password data. Again, this may not be a big deal. But it makes it a lot harder to explain why and how 1Password is secure. And that's not unimportant.

  • Pervel definitely has a good point. I think it would be a good idea to have a toggle which stores a Boolean whether or not to save the master key into apple's iCloud (probably in the document and keychain save location just to be sure in case in is disabled)

    But for most novice users, this improvement is probably pretty good. The concept of having a secret key could potentially be foreign to them and they could lose access to their wallet when they switch devices. Furthermore your explanation of what it does should be stored in the docs somewhere. A web search for this feature linked me to this post (at least a few hours ago before this answer has been posted).

    Thank you for this feature. It is probably pretty useful for many users but you should also not forget more advanced users.

  • brentybrenty

    Team Member

    @pervel, @Matt3o12: I also had a very weird feeling about this at first, but it helped me to think of it this way:

    It's effectively no different than having my 1Password.com account credentials stored in my vault. We do this anyway by default now, but I've been doing that since day one. I'll highlight this portion of Kyle's response, since I think it sums things up nicely:

    The only app that has access to data 1Password stores in iCloud Keychain is 1Password. Programmatically no other application can access this data. And to quote Apple's documentation above:

    iCloud Keychain encryption keys are created on your devices, and Apple can't access those keys. Only encrypted keychain data passes through Apple's servers, and Apple can't access any of the key materials that could be used to decrypt that data.

    Since these credentials are only accessible to 1Password, and even then they require your Master Password, it's no different than locking them in a local vault on a device, or in a 1Password.com vault on an authorized device (where you don't have to enter your Secret Key, only the Master Password, to access it).

    Let me know what you think. :)

  • It's effectively no different than having my 1Password.com account credentials stored in my vault.

    Is the Secret Key in the iCloud Keychain encrypted with your Master Password?

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    edited May 2017

    Hi all, I have been out for most of the day (and then my power went out, and then my household server didn't restart after the power came back up1), so my apologies for joining the discussion late.

    Yes, it does involve a risk, but ...

    Several people have pointed out that putting the Secret Key increases the attack surface against its secrecy. This is correct, but it is also useful to review what those threats are.

    But what new risks does it add?

    Let's keep in the purpose of the Secret Key as part of Two-Secret Key Derivation (2SKD). It is so that data stored on our systems (or captured in transit) cannot be used for taking guesses at your Master Password. This is described in the Modern Authentication blog post. The Secret Key does not protect you if an attacker breaks into your computer or captures data from your devices. In those circumstances, you depend on the strength of your Master Password.

    Roughly speaking, we believe that any attacker who can acquire information from your iCloud Keychain has already completely broken into one of your Apple Devices. As Kyle pointed out, the iCloud Keychain is not something like your iCloud photos or Pages documents. Getting at the iCloud Keychain requires both the iCloud password and the ability to unlock a device that is already set up with it. So other than some rare situations, and attacker who would be in a position to get at your Secret Key from your iCloud Keychain would already be able to capture it without bothering with the iCloud Keychain.

    Apple, like us, have designed the iCloud Keychain so that a compromise (or inside attack) on the iCloud servers cannot reveal the contents of what is stored there. So because Apple uses well-designed end-to-end encryption for iCloud Keychain, the threat against the contents of it means a successful compromise of your local device. But a compromise of your local device already exposes the Secret Key; so use of iCloud Keychain does not add a new attack vector. Except ...

    The exception

    The one thing that gave us pause with this reasoning is the case where you may use 1Password on only a proper subset of Apple devices for which you use iCloud Keychain. With our scheme, the Secret Key would spread to a device that it otherwise would never be deliberately used on. And so a compromise of that specific device would expose the Secret Key under the new set up, where such a compromise wouldn't before.

    These are the kinds of things that we have to consider when balancing risks.

    Ideally, we would have some opt-in or prompt for all of this, but the people we are trying to help (those who would lose their Secret Keys without the automatic addition to the iCloud Keychain) are the ones who are least likely to opt in. It's like the problem we have with Emergency Kits: The people who do store a copy in a safe place are the ones who are least likely to end up needing it.

    More secure than the Emergency Kit

    We don't know exactly how people are saving their Emergency Kits. We know what we advise, and we know that a lot of people writing into us telling us that they have lost their Secret Key never saved a copy in a safe place. It is more than likely that a number of people are just putting the PDF on their their computers, perhaps in some folder that is not very secularly synched or backed up to some cloud service.

    We are going to continue to encourage people to save an Emergency Kit despite those risks. Again, that is one of those choices we have to make that involve security/security tradeoffs, but I think it is the right one. Automatically saving the same information (without the Master Password) to the iCloud Keychain is safer than the typical behavior we already encourage with the Emergency Kit.

    Is the Secret Key encrypted with the Master Password?

    No, the Secret Key is not encrypted with the Master Password.

    I know that that sounds odd, but there are very good security reasons for that. First remember that your data is encrypted with keys derived from blending together your Master Password and your Secret Key. So the Secret Key does no good encrypted with your 1Password data (unless you want to enter your Secret Key every time you unlock 1Password, and you do not want to do that.)

    But why not encrypt the Secret Key with the Master Password before storing it locally or in the iCloud Keychain? The reason is because of what an attacker can do if they capture such an encrypted Secret Key versus what they can do if they capture the unencrypted Secret Key. Let's call the Secret Key encrypted with the Master Password c.

    Eve and Oscar

    c = Encrypt(key: MP, data: SK)

    Let's now consider two attackers, Oscar and Eve. The only difference between them is that Oscar has c and Eve has SK.

    Both Eve and Oscar need your Master Password to get any further. So now let's consider a bunch of scenarios.

    • Neither has any of your other data
      Eve (who has SK) can make password guesses and try logging in to our servers for each guess. Each guess involves the full computation of the SRP-x (PBKDF2 rounds, etc), and going through the authentication process for each guess. She has to keep this up (and not trigger rate limiting) until she guesses the right MP.

      Oscar can through MP guesses at decrypting c. He can do all of that entirely off line until he gets something that decrypts properly. This way he will be able to test MP guesses much more quickly and without fear of trigging server detection. Only after he has an MP guess that decrypts c will he try actually logging in.

    • Each has the encrypted personal keyset

      In this scenario neither Eve nor Oscar need to try to log into the server (until they are sure that they have both the MP and the SK). Eve, with the SK has one way to test MP guesses. She goes through the normal key derivation stuff to try to get a Master Unlock Key (MUK) that she can test against the encrypted personal keyset.

      Oscar can take Eve's approach (with the added step of decrypting c with each guessed MP) or he can test MP guesses against c itself (as in previous scenario). Oscar can choose whichever approach is going to be faster for him given his set up and the nature of how c is encrypted.

    • c is encrypted in a way that doesn't reveal whether a decryption is correct

      The above two scenarios assume that Oscar can tell whether guess at a MP decrypts c correctly. But now suppose that c is encrypted by the MP in a way that a wrong guess will result in something that looks like a Secret Key but won't be the real Secret Key.

      In that case, Oscar has to do the same thing that Eve has to do. He is no better off than Eve, but he is only marginally worse off.

      However, there are risks to using encryption with those properties. It can be done, but it needs to be done very very carefully. It would make the normal user decryption of c vulnerable to chosen ciphertext attacks as we couldn't use authenticated encryption for it, and unless the "false" decrypts were truly indistinguishable from a true decrypt (other than the SK and MP pair actually working to at the next stage) then is could still give Oscar an advantage in guessing the MP that Eve doesn't have.

    So, paradoxically, encrypting the SK with the MP can never add much defense, but it could actually give the attacker a much easier way of guessing the Master Password.


    1. The problem with using inexpensive PCs for lightweight servers is that their power supply units are not designed to support non-stop use for eight years. I always meant to create a fail-over server on an Arduino, but never got around to it. Now I've got to restore from backup. ↩︎

  • I don't have my iCloud Keychain on, so will this still apply to me?

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    Sorry, @prime. This feature is only useful for those who have iCloud Keychain enabled on their devices.

    Note that you can have iCloud Keychain enabled but not use it for most passwords. You are using 1Password for that. But I have mine on because it helps sync things like email setup passwords across my Apple devices.

  • @jpgoldberg thanks! I keep mine off. How easy the subscription is when setting up a new device, I really don't see a need for this.

  • brentybrenty

    Team Member

    @prime: I agree. The reason this feature exists though is for folks who are less fastidious about having their Emergency Kit or a contingency plan. This way they may be able to authorize a device by entering only their Master Password (if it already has access to the rest) so they can get into their data. We definitely want to help folks avoid data loss where possible. :)

  • deviantintegraldeviantintegral Junior Member

    Thanks for the detailed explanations - the release notes gave me pause too.

    Is this coming to OS X as well? Will the iCloud keychain item be shared between OS X and iOS?

  • brentybrenty

    Team Member

    @deviantintegral: This was added to 1Password for Mac in a recent beta. Cheers! :)

    ref: OPM-4936

  • If a person is concerned about the exception mentioned by jpoldberg, can one prevent this by turning off the iCloud keychain in the iOS settings, after backing up the device to iCloud with iCloud Keychain turned on? Or is this closing the barn door after the horse is already out? And if a device that wasn't being used with 1Password fell into rogue hands and the iCloud Keychain button was flipped on, could they then potentially access the secret key that way. In other words by the potential problem mentioned in that "exception".
    Is there a way to exclude 1password from being backed up when backing up when a device to iCloud? I like to have my device backed up to iCloud, but I don't particularly need to have 1password backed up that way since I do have my emergency kit safely stored. Apparently I have already backed up my secret key to iCloud because 1Password was restored when I set up a new iPad from the back up of a different iPad. I had not realized that would be possible and don't particularly want it to be possible for me. So I guess my question boils down to whether I can get the horse back in the barn? Thanks.

  • BenBen AWS Team

    Team Member

    If a person is concerned about the exception mentioned by jpoldberg, can one prevent this by turning off the iCloud keychain in the iOS settings, after backing up the device to iCloud with iCloud Keychain turned on? Or is this closing the barn door after the horse is already out?

    You'd need to turn off iCloud Keychain on all devices associated with your Apple ID in order to remove all data from iCloud Keychain.

    And if a device that wasn't being used with 1Password fell into rogue hands and the iCloud Keychain button was flipped on, could they then potentially access the secret key that way. In other words by the potential problem mentioned in that "exception".

    Turning on iCloud Keychain on only a device that doesn't have 1Password wouldn't have any effect on 1Password. But also remember that someone would need to be able to access your device to even do that.

    Is there a way to exclude 1password from being backed up when backing up when a device to iCloud?

    No.

    Apparently I have already backed up my secret key to iCloud because 1Password was restored when I set up a new iPad from the back up of a different iPad.

    It sounds like your assumption is correct.

    I had not realized that would be possible and don't particularly want it to be possible for me. So I guess my question boils down to whether I can get the horse back in the barn? Thanks.

    I believe I answered this above (first paragraph). If not please feel free to clarify.

    Thanks!

    Ben

  • brentybrenty

    Team Member
    edited June 2017

    @Bronwen224466: Just to clarify, 1Password doesn't backup your data to iCloud, just the Secret Key. There are a few reasons for this: for security, it's good to not have these stored together in a backup, in case your iCloud account were to be compromised. But it would also be a technical problem if you restored 1Password and its data, and then the app tried to sync outdated information with your account.

    And, in case it helps put things in perspective, I think it bears mentioning that the Secret Key serves a very specific security function, which is still fulfilled even if it is backed up to iCloud: the Secret Key ensures that, in the event of 1Password.com being breached, the attacker will not be able to perform a brute force attack against people's Master Passwords to access any of our customers' data. Put another way, a long, strong, unique Master Password protects you; the Secret Key protects us from being used to get our customers' most important, sensitive data. The Secret Key is only necessary because we store our customers' data. The security of local vaults, with "only" a Master Password, is more than sufficient to withstand attack, provided you're using a strong password. The Secret Key offers an additional layer of security because the threat model is different when we're centrally hosting people's encrypted data.

  • Thank you. I think I understand that part. The part that concerns me is what jpgoldberg said about the SK being accessible on a device that I don't use 1Password or other sensitive things on, and don't normally think of being a security weakness, and therefore one that I don't use as good security on. For example, an iPod used only for accessing my iCloud music. But if I understand jpgoldberg, a talented person could potentially access my SK on said iPod. Now I also understand this alone would not get the person very far, so perhaps it is not worth worrying about...

  • brentybrenty

    Team Member
    edited June 2017

    @Bronwen224466: That's a really good point, and I'm glad you brought it up. This doesn't need to be a concern for you. Other apps cannot access this data, and someone malicious with access to your device can't get it either, due to both sandboxing and device encryption. And if someone gets your Secret Key in another way, you can always regenerate it to get a new one, so it isn't the end of the world. Cheers! :)

    Edit: I just wanted to clarify that this applies to iOS devices primarily. The security model there is very strict. On macOS someone who has full administrator access to the machine may be able to access Keychain data.

  • The Mac should be fine if my security there is good, though, right? Decent log in password, and Filevault on. Thanks again.

  • FrankFrank

    Team Member

    Hi @Bronwen224466 - Indeed! It's good to have a strong password for your user account, in addition, someone would need to also guess or gain access to your Master Password which is only known by you. I hope this helped a bit more. Let us know if you have any additional questions. :+1:

  • Many thanks.

  • BenBen AWS Team

    Team Member

    You're most welcome. If we can be of further assistance, please don't hesitate to contact us.

    Ben

This discussion has been closed.