Why didn't iOS ask for my secret key?
I erased my iPhone, and when I installed 1Password again, I was very surprised that it didn't ask me for my secret key: my master password was enough to sign me into my family account.
This means that if someone breaks into my iCloud account AND gets my 1P login password, they can get into my 1P account --- but I thought one main purpose of a secret was to prevent exactly that kind of attack?
1Password Version: 7.2.7
Extension Version: Not Provided
OS Version: iOS 12.1.4
Sync Type: 1P Web (family account)
Comments
-
Hi @rbondi
I erased my iPhone, and when I installed 1Password again, I was very surprised that it didn't ask me for my secret key: my master password was enough to sign me into my family account.
With iCloud Keychain enabled your 1Password sign-in address, account email address, and Secret Key are synced via that service.
but I thought one main purpose of a secret was to prevent exactly that kind of attack?
The purpose of the Secret Key is to protect you in the unlikely event that encrypted data was stolen from 1Password.com.
This means that if someone breaks into my iCloud account AND gets my 1P login password, they can get into my 1P account
That's true. I'd recommend using a strong unique Master Password as well as a 1Password generated password for your iCloud account. I also recommend enabling Apple's two-factor authentication:
Two-factor authentication for Apple ID - Apple Support
With this system you need to approve logins from a trusted device before a device can become associated with your Apple ID.
Ben
0 -
Thanks, Ben. I already do all of the things you suggest, but I did not know that iCloud Keychain also has my secret key. I want to use iCloud Keychain for other things, but not for my 1Password information.
1) Where does 1P documentation say that all three items (email, password, and secret key) are stored there?
2) How can I remove that information without turning of KeyChain? (I could delete the info from Keychain via macOS, but would 1P just put it back in the next time I used it on an iOS device?)Thank you, |r:b:
0 -
Hi Ben,
Clarification: I see that Keychain doesn't have my 1P password, only the three things you listed (sign-address, account email, secret key). However, I still don't want those things in the Keychain. Any information on how to remove it permanently, without having to disable iCloud Keychain, would be great.
Thanks, |r:b:0 -
Hi @rbondi,
How can I remove that information without turning of KeyChain?
You would have to turn off iCloud Keychain to accomplish that.
I could delete the info from Keychain via macOS, but would 1P just put it back in the next time I used it on an iOS device?
It would, yes.
Where does 1P documentation say that all three items (email, password, and secret key) are stored there?
That's a good question. Off-hand I'm not sure that it does, though it probably should. I'll have to do a little more research on that.
It may help to know that we've set the item in iCloud Keychain so that only the 1Password application can read it from iCloud Keychain and also iCloud Keychain data is end-to-end encrypted (i.e. even Apple can't read it).
Ben
0 -
Hi Ben,
Thanks for your replies.
There seem to me two problems here that 1P should address. One is about communication, the other is about choice.
When I decide to use 1P, I'm making a choice to put all my eggs in one basket -- 1P's basket -- and that the risks of that outweigh the risks of trying to look after my eggs myself. This is a choice based attack surfaces: I believed that 1P's layers of defenses was independent of Apple's and Google's.
Communication problem
The communication problem is that 1P doesn't do a good job of telling me that if I use OSX, iOS, or Android, I'm actually choosing additional baskets: Apple's and Google's. 1P doesn't do a good job of this because the instructions say of the secret key: "Only you have access to it." https://support.1password.com/secret-key-security/. Only if I parse 1P's language about "access" carefully, and only if I read to the very end of that page do I discover that Apple and Google have my secret key too.
By "have" I mean on their servers, rather than on my devices: I am willing to take Apple and Google at their word that they do not have access to the plaintext of key material I keep on my devices.
Furthermore, "have" also means an additional attack surface. For example, I didn't worry about the recent Keychain attack when I read about it (https://www.patreon.com/posts/mr-steal-yo-14556409). I believed that 1P didn't use Apple's Keychain at all. I believed my eggs were safe inasmuch as I believed they weren't in Apple's basket. Now I see that is not so.
Even worse, what Apple and Google have on their servers to is the larger part my two pieces of key material: the secret key has more entropy than my password.
Choice problem
The choice problem is that 1P isn't giving me a choice to not store my secret key on Apple's and Google's servers. You've said that I can't delete my secret key from the iCloud Keychain except by disabling the iCloud Keychain altogether. That, I think, should be a choice given to 1P users. (Personally, I would prefer to have to manually type in (or scan) my secret key when setting up a new iOS device, rather than have it kept for me in the iCloud Keychain.)
Android
Separately, could you tell me how 1P stores my secret key with Android/Google? The last sentence on the About your Secret Key page merely says: "It's the same for Android backups."
- Does this mean that the cleartext of the secret key is stored in a backup of my Android device on Google's servers, enciphered by Google with my backup password?
- What if I haven't chosen to encrypt my Android device in Android Settings: is my secret key then stored in the clear on Google's servers, inside the backup of my Android device?
Kind regards, |r:b:
0 -
Thanks for the continued feedback on this @rbondi.
That, I think, should be a choice given to 1P users. (Personally, I would prefer to have to manually type in (or scan) my secret key when setting up a new iOS device, rather than have it kept for me in the iCloud Keychain.)
We have evaluated that approach and decided against it. The reality is that the threat of losing the Secret Key is much greater than that of it being stolen by Apple/Google. Before we started doing this we had an unacceptable number of customers who were losing all of their data because they were not saving the Secret Key anywhere. This implementation has cut down on that significantly. Though an often forgotten part, information availability is a critical part of information security (the "CIA triad:" confidentiality, integrity, and availability). If the information isn't available to those who are supposed to have it then you've (we've) lost the game. As such, unless the landscape shifts, we will not be changing this.
I do think you've made a fair point regarding the communication of this though, and we'll evaluate how we can better address that. Additionally I will ask one of my colleagues who is more familiar with Android to chime in on your questions regarding that platform.
Ben
0 -
Hi @rbondi! I'm happy to jump in here at @Ben's request to try to add some clarification for how this pertains to Android backups. As you noted, things have changed relatively recently with the introduction of encrypted Android backups and Google's new Titan technology.
If your device is running Android 9 and is included in Google's rollout of encrypted Android backups, then that would mean that your Secret Key is encrypted using a locally generated encryption key before it is backed up to Google's servers. That key is then encrypted with your passcode and transmitted to Google to be stored in their Titan modules.
If your device is not eligible for encrypted Android backups (for example, if the Android version or device are not supported), then the Secret Key is sent with your backup data through an encrypted connection to Google's servers. Your backup data is encrypted at rest on Google's servers with an encryption key that is known to Google and stored separately from your backup data.
In both cases, your data is encrypted at rest on Google's servers. The difference though is that in the latter case, Google does have access to the key that was used to encrypt your data, so it is only inaccessible to them as far as their own policies are enforced. I hope that helps to answer your questions!
0 -
Hi guys,
Ben: Sounds good, thank you very much. I really appreciate it.
mverde: Thanks for the extensive answer. I'm confused by your reference to "Titan modules" though. IIUC there are two kinds of Google hardware called Titan: did you mean one of those, or something else?
One Titan is just Google's version of a 2-factor hardware key like a Yubikey, and only stores a seed for hashes, not actual password or key material: https://cloud.google.com/titan-security-key/. So I don't understand what you are referring to when you say "and transmitted to Google to be stored in their Titan modules."
Another Titan is a type of chip used in some Google servers that uses cryptography to validate boot software, but is not used to store otherwise unrelated keys: https://cloud.google.com/blog/products/gcp/titan-in-depth-security-in-plaintext. Servers with Titan chips would, like any server, process any kind of files, not just Android 9's files. A Titan chip isn't called a "Titan module" AFAIK.
Kind regards, |r:b:
0 -
I can definitely appreciate where there may be some confusion, as there do seem to be a number of "Titan"s out there. :)
Google has an overview of the software and hardware protecting the keystore on their blog:
https://www.blog.google/products/pixel/titan-m-makes-pixel-3-our-most-secure-phone-yet/
Like most good security, it's a combination of things, rather than relying on a single measure to protect against a wide range of potential threats. They go into more detail on their security model here:
https://security.googleblog.com/2018/10/building-titan-better-security-through.html
Hope this helps. Cheers! :)
0 -
Ah, a third Titan, Titan M, for Google Android phones aka Pixel 3 for now -- which does use Titan for user key storage!
Excellent, thanks for all this information.
Kind regards, |r:b:0 -
I didn't actually realize it was three either. I hadn't bothered to think about all of that together and count! :lol:
0