Secret Key Being Transferred Automatically?

Hi @KevinUre! Your account’s Secret Key works as an extra layer of security on top of your Master Password. It is stored in 1Password’s internal database encoded on your Android device and access to it is governed by the Android application sandbox. The only app that can read this database is 1Password.

We use Android’s backup service to store your 1Password account’s sign-in address, email address, and Secret Key. This data is stored with your device backup and cannot work independently to access your 1Password account. The Master Password, which is only known to you, is required to be able to successfully sign-in and decrypt your data.

Your 1Password account is protected by your Master Password and your Secret Key. Both are not known to us and is never transmitted to our servers. Your Secret Key is stored locally on your device after signing in and with your backup if enabled on your device.

I hope that answers your question. Let us know if you have any others!

So really the value proposition of the SK is that compromising AgileBits servers alone can't unlock my vault, right?

That would be an extreme way of putting it, but it does capture our primary concern of AgileBits' servers cannot be used for password cracking. But this doesn't mean that it is ok to put the Secret Key anywhere except on AgileBits servers. The fewer places it lives and can be stolen from the better.

Though I guess if they can break TLS we've all got bigger things to worry about right?

1Password is designed to withstand failures of TLS. We use TLS as an additional layer, but we've built things so that don't rely its secrecy, and only rely on its authenticity checks when using the web-client.

Sight unseen

One of the things that I really love about using the QR codes is that the "network" activity is completely transparent to the user. It is being transmitted from device to device using line of sight and a camera. From an ideal security perspective it would be really nice to keep things that way. And it is great for people like you who understand the importance of not losing your Secret Key.

But there are a sizable portion of people who do not understand the importance of not losing the Secret Key. All of the explanations during signup and all of our encouragement for people to save a copy of their emergency kit just isn't up to the job. I don't blame users for failing to fully understand the implications of the SK. Most people are told for every single site and service they create a password for that they must not lose that password; yet only a few of those services really leave data unrecoverable if credentials are forgotten or lost. On top of that, nobody has encountered anything like our Secret Key before. No matter what we say and what explanations we provide, some people are going to treat it as a license key or some other thing that they don't need to take large efforts to preserving.

Of course this means that we should continue to find ways to help people treat their SK's appropriately. This is an on-going effort, and we make refinements here and there. But it also means that we have to help people not lose their SKs. And so when an operating system offers an end-to-end encrypted backup mechanism for application configuration information, we will try to get the
SK onto those backups.

So we are taking a two pronged approach to lose of the secret key.

1. Improve our encouragement Emergency Kits or user-made backups of it.
2. Finding safe (end-to-end) places to automatically back it up that are still far from us.

So my SK is in Android's crypto-vault, sure. my new phone was able to read data from my old phone's crypto-vault though, which means that either they share some common way of deriving the decryption key, which i would like to know what is if you happen to know; or the vault was stored in my backup without at-rest encryption, right? would the answer to the former be the Google Play account secrets that @jpgoldberg eluded to? Any additional readings you have on the subject would be appreciated.

@KevinUre: Exactly. I'm having trouble finding good public available documentation on this, but the summary is that there are a few layers of security here:

1. 1Password's app data is encrypted with unique keys generated for the app itself (so that others cannot access it)
2. 1Password user data (the things you store in it yourself) are encrypted using keys derived from your Master Password (and Secret Key, in the case of a 1Password.com account)
3. Anything backed up through Google is encrypted using your account's keys

The tricky thing is that the Secret Key is probably both (1) and (2) here, if you have your 1Password.com account credentials saved in your vault (2) as well as the being stored expressly for recovery purposes (1), as in your original question.

I think it helps to take a step back and look at things from a wider perspective and break things down. Let's take "traditional" 1Password (the standalone version with local vaults) for an example:

1. 1Password's app data is encrypted with unique keys generated for the app itself (so that others cannot access it)
2. 1Password user data (the things you store in it yourself) are encrypted using keys derived from your Master Password
3. Anything backed up through Google is encrypted using your account's keys
   = Your Master Password is required to access the decrypted data, either on the original device, or after syncing the data to a new device; the "keys" to decrypt it are not stored with the data, (even if you store the data "in the cloud").

When we compare that to 1Password.com, we see that the security model is very similar:

1. 1Password's app data is encrypted with unique keys generated for the app itself (so that others cannot access it)
2. 1Password user data (the things you store in it yourself) are encrypted using keys derived from your Master Password and Secret Key
3. Anything backed up through Google is encrypted using your account's keys
   = Your Master Password alone is required to access the decrypted data when the Secret Key is already available locally, either on the original device, or after syncing the data to a new device; the "keys" to decrypt it are not stored with the data, which is always on the 1Password.com server...

But with one important difference: The Secret Key provides an extra layer of security for the data itself, and is only not required when you've already authorized the app/browser (because it is already stored locally). This additional layer is really overkill at the device level, and this is why the Secret Key isn't required each time you unlock 1Password on your phone.

My initial inquiry can be broken down into two parts i think. the first part is how exactly did this situation transpire, which you all have done a great job of explaining :) .

Indeed. This has a very simply answer: Despite our best (ongoing) efforts in the apps themselves and our documentation, a lot of people lose their Secret Keys (or simply never saved them anywhere in the first place). :(

The second part is how this effects my security, or maybe how i should shift my perception of how 1Password protects me. I understand that the SK needs to be stored on each device somewhere and that Android's crypto-vault is the obvious answer; I've no further questions on the at-rest encryption on the device. Where I'm still a bit uneasy/uneducated is what having it in my backup means for security. From @saad 's post it makes it sound like you guys monitor how Google is doing their security pretty closely so hopefully you can help me understand. I would guess that Google encrypts my backups with a derivative of my account password (and maybe a google held salt thats unique to me or something). Is having my google password the only thing needed to rummage through my backups?

No. More on that in a bit.

I guess the real underlying question here though is if an attacker targeting my 1Password vault gets one of my backups in the format that Google stores it, does that grant them any advantage?

Arguably, but not a helpful advantage. If you're using a strong Master Password, it's the difference between being able to brute force your data potentially before the heat death of the universe, rather than after it.

If they're able to gain access to your encrypted data and Secret Key, then they "only" need to guess your Master Password correctly to decrypt. But then we're back to the "traditional 1Password" level of security, which isn't by any stretch of the imagination obsolete or in sufficient. More on that later.

why or why not.

Fantastic questions! Hopefully my illustrations above helped to make things clearer already, but I'll reiterate here because it's so important: No matter what, the data you store in 1Password is never in a position to be compromised with an attack on an account/service/server.

In this case we're talking specifically about Google, if your data and/or Secret Key is backed up there. Someone compromising your Google Account will still only be able to access encrypted data: they'll need your Master Password to decrypt it. This applies equally to Dropbox, 1Password.com, or anything else 1Password users might utilize for convenience to access their secure data.

So getting back to Google again, someone accessing your account would still need to get past the app-level encryption (to get your actual 1Password data, still encrypted), the Secret Key, and also successfully guess your Master Password. That's not only more trouble than it's worth, the encryption on its own is sufficient to protect your data. So regardless of the 1Password setup you use, an attacker will need to get the Master Password from you before they can decrypt your data.

Perhaps the key here (pun not intended) is that the purpose of the Secret Key is to ensure 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.

Apple gets some laughs and criticism when they talk about "courage", but they do take some risks when it comes to aggressively pushing things forward, if only in the sense that they end up alienating people sometimes. That's the business they're in. Conversely, we're in the security business — it's actually the only business we're in — and are rather cowardly when it comes to protecting our customers' data (and our own!) as well as our reputation. The Secret Key is a testament to that, and its saving grace is that we've found a way to have it both protect 1Password users' data and also not be a horrendous usability problem. Otherwise 1Password.com might not exist today. Cheers! :)

@KevinUre: Thanks! I fear I may have misunderstood part of your original question — perhaps not what you asked exactly, but the thing you were trying to understand. When your Android device is backed up to Google, the data you stored is not part of that. Since 1Password.com has all your data to be accessed on demand, this simply isn't necessary: everything's backed up — encrypted — on our server. So this affords us two things: your Secret Key is not backed up in the same place as the data encrypted using it (and your Master Password), which is probably the part you care about; but it also means that the server doesn't suddenly get a bunch of old data dumped on it when you restore, so we avoid having to try to reconcile this, which could cause sync conflicts. I apologize if I muddled that earlier. There are just a lot of different "backups" involved in all of this. :)

Getting back to the Secret Key though, I did want to clarify that what your device has, and what is backed up to Google in your device backup (if enabled), is the Secret Key itself. "At rest" this is protected by Android app sandboxing and device encryption, and "in transit" it's protected by Google's backup service and account security. But since we don't have strict control over these ourselves, we treat this roughly the same as we do in any other authorized device or (especially) browser: we should assume that an attacker with unrestricted access to the device/browser can get it if they want to. More on why we don't encrypt this using your Master Password below.

Two side notes:

it's the difference between being able to brute force your data potentially before the heat death of the universe, rather than after it.

That was hilarious.

lol thank you. A bit fanciful, but I figured you'd get the idea. ;)

and secondly: i had a thought during our exchange. you mentioned that people put their SK and MP inside their vault (2) itself, and i was wondering if that weakens security. Its obviously the key inside the locked house analogy from above but it brings to mind the way the vigenere cipher is solved. Does encrypting your MP and SK with a key made form them leave any telltale mathematical evidence, or does the salting of them cover that flank?

Your Secret Key is not encrypted using your Master Password. It doesn't sound like that's what you're asking, but this applies indirectly and is really important because if someone captured a Master-Password-encrypted Secret Key, they could run a brute force attack on that to try to discover the Master Password. If they do, they will then have both. That is, the encrypted Secret Key would provide a "test" for whether a Master Password guess is correct. You're on the right track. The derivation process which uses both your Secret Key and Master Password to encrypt the encryption keys used to encrypt each vault means that we can't mathematically discover one without the other, different from trying to discover the Master Password used by itself to encrypt the Secret Key (as described above).

Anyway, I hope this helps tie things together a bit better, but with all of this in mind, and since you mentioned it already, it might be worth taking another look at the security white paper, since it really offers a comprehensive view of how all of this fits together. We're happy to answer any questions you have here (and frankly, it's a lot of fun!), but the scope is more limited due to the medium. Cheers! :)