Can someone explain how saved accounts work on Android?
I did a factory reset on my phone today and when I opened 1Password it gave me the option to pick a saved account. Doing so I only needed to enter my master password and not the URL or key. Where is this stored. Assuming with the Android backup in drive. Is it encrypted if so how?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
@tommyent: Thanks for reaching out. Great question! You might not want to read the whole thing, but there was a similar discussion not long ago when we initially introduced this feature on iOS and @jpgoldberg went into a great detail in this post about this.
Of course, the details are slightly different on Android compared to iOS, but we're doing fundamentally the same thing: the email address, sign in URL, and key are stored in your Google Account using its backup feature. That way this can be sync'd to a new device and you only have to enter your Master Password to add the account in 1Password there when setting it up (unless of course you've made changes to you account which has made the backed up credentials obsolete). So this information is encrypted in your Google Account along with the rest of the data you have stored there. I hope this helps. Be sure to let me know if you have any other questions! :)
0 -
Where is the info about encryption? All I can find is this on the developer site.
"Auto Backup preserves app data by uploading it to the user's Google Drive account, where it is protected by the user's Google account credentials."
This would leave me to believe it's not encrypted. Protected and encrypted are way different in my book and this concerns me. Perhaps @jpgoldberg can shine a little light on Android backup.
0 -
Best I can tell is you've given Google a plain text copy of my Secret Key. Which looks to most likely be stored in plain text on their end. I was not given the option to opt in or out and would have assumed that something like this would never be acceptable with an app like this. You guys go through all the effort to not hold this or that but then you give it to someone else?
0 -
Where is the info about encryption? All I can find is this on the developer site. [...] This would leave me to believe it's not encrypted.
@tommyent: Details about the specifics of how Google stores data aren't available. Google does have a good track record in this area though, and more importantly, to paraphrase Goldberg's comments in the earlier post I linked...
Roughly speaking, we believe that any attacker who can acquire information from your [Google Account] has already completely broken into one of your Devices. [...] Getting at the [this] requires both the [account] 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 [Google account] would already be able to capture it without bothering with [that].
We're using the Key/Value Backup APIs, which store these account details locally on your device in 1Password's own app sandbox and device encryption, and then the Android Backup Service transmits these to be securely stored on Google's servers. But just to clarify, neither your 1Password data nor Master Password are included in this.
Best I can tell is you've given Google a plain text copy of my Secret Key. Which looks to most likely be stored in plain text on their end. I was not given the option to opt in or out and would have assumed that something like this would never be acceptable with an app like this. You guys go through all the effort to not hold this or that but then you give it to someone else?
No. I think you're misunderstanding the purpose of the Secret Key. It isn't the same as your Master Password, that's why it isn't something you choose yourself. We never have it, so it isn't possible for us to "give it to someone else" or have it stolen from us along with your data. That's the point. The Secret Key is meant to be a strong second factor (along with your Master Password) used to encrypt your data. So these three pieces — encrypted database, Master Password, and Secret Key — which are needed to access your data are never stored or transmitted together. The Secret Key exists to protect each Password.com user from brute force attacks against their Master Password (which is almost certainly weaker than a 128-bit, randomly-generated string) in the event that the database is stolen.
We have to be realistic about the threats we're talking about here. Even if someone was able to break into your account on Google's servers and retrieve your Secret Key from a backup, they'd still need to get the database (by breaking into 1Password.com or your device) and your Master Password (by breaking you). With that in mind, an attacker might as well just target you for all three.
0 -
No. I think you're misunderstanding the purpose of the Secret Key.
Not at all. I never said you have it I said you hand it over to Google. You do this by backing it up.
That's the point. The Secret Key is meant to be a strong second factor (along with your Master Password) used to encrypt your data.
Exactly. My problem is I never explicitly gave permission for it to be backed up. Hell I was never event told my key would be anywhere other than my devices. I've read the white paper and in several places it stated how it's stored locally but no where does it say that it's stored on a Google server.
Roughly speaking, we believe that any attacker who can acquire information from your [Google Account] has already completely broken into one of your Devices. [...] Getting at the [this] requires both the [account] 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 [Google account] would already be able to capture it without bothering with [that].
@jpgoldberg was talking about iCloud. You can't swap in Google for iCloud keychain. It's not the same. I can with any device get access with just a password.
As @AGKyle pointed out
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.
Keyword encrypted.
Honestly what this backup offers is no better than snapping a pic of a QR code and if you don't have that option the convenience is not worth it.
The Secret Key exists to protect each Password.com user from brute force attacks against their Master Password (which is almost certainly weaker than a 128-bit, randomly-generated string) in the event that the database is stolen.
Even if someone was able to break into your account on Google's servers and retrieve your Secret Key from a backup, they'd still need to get the database (by breaking into 1Password.com or your device) and your Master Password (by breaking you).
If you read those back to back you have to see a problem with this.
So you give Google the secret key which as you put it "exists to protect each Password.com user from brute force attacks against their Master Password". You also give them my URL eliminating the brute force protection as you put it. With the URL and Key all the have to do is break my "almost certainly weaker than a 128-bit" password.
0 -
Not at all. I never said you have it I said you hand it over to Google. You do this by backing it up.
We did not introduce this until we were satisfied with the end-to-end encryption built into Android backups. Google does not have the capacity to decrypt what is sent there.1
I never explicitly gave permission for it to be backed up. Hell I was never event told my key would be anywhere other than my devices.
You're not wrong. Indeed. And I understand your anger. We did not manage to communicate this change effectively enough. (It was in release notes, but that isn't always enough.)
A year ago you could hear me loudly proclaiming that the Secret Key (neé Account Key) never left your own devices. This was indeed a "selling point" of the Secret Key. So yes, we've changed our tune. I've changed my tune, and didn't succeed in finding a way to communicate either the fact of this change or the reason for it.
Why the change?
One thing that we found is that a fair number of Android users wipe and reset their devices. Most 1Password users forget that their Secret Keys are a thing, and so suddenly people would find themselves unable to get their data.
Now pair that fact with the goal of the Secret Key. The SK is designed so that if someone gets your data from our servers (or captures the SRP verifier on first signup). Your backup on Google cannot be decrypted on anything other than your device. It's e2ee-d version of a Google server does not change that.
So if we can trust that Google's backup encryption does what it says it does, then our storing the backup there does not change the risk.2 So the choice that we made on your behalf and without your knowledge was that we could alleviate very demonstrable threat to data availability by adding something that looks like a very small increased risk to data confidentiality. Leaving aside (for the moment) the issue of informed consent, I hope that you will agree that this decision was a good decision.
Uninformed non-consent
If you agree that the e2e encryption for Google app backups pretty much means that an attacker would need to comprise your phone or that it would take Google lying about their encryption (in which case they could lie about what they do with data on your phone) the the remaining issue is that we failed to inform you and we failed to gain your consent.
This was a tougher decision for us. (The decision to use the backup mechanism offered in recent versions of Android for the Secure Key was an easier decision.) First of all, there is no real gain in informing you if we don't give you the ability to choose. Informing you without seeking your consent wouldn't really do anyone much good. So the question was should we have sought your consent. As I said, our decision was not an easy one.
We have no way to know, but we suspect that the large majority of 1Password users first setting up their devices have only the sketchiest of ideas of what the Secret Key is about. And we are specifically aiming to help those people how are mostly likely to lose their Secret Keys. We can, of course, have a "learn more" link for any choice we pop up for users to make, but realistically very few people read those. And any additional step in setup leads to problems.
So quite simply we couldn't devise a way to ask for consent that did the following three things
- Would give users like you the opportunity to decline
- Not confuse most users
- Be "worth" an additional step in getting things set up on your own device.
I suspect that you may not agree with our decision. And perhaps we should have tried harder to find a way to meet those three criteria. But I hope that you will recognize the thought and reasons that went into it. And again, please keep in mind that we made this decision while we were getting multiple reports per day of users who had been permanently locked out of their data because they had wiped their phones.
Cheers
-jJeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits0 -
I understand the process behind the decision. But are there any plans to actually allow the user to choose whether he likes to store the Secret Key on Google's servers?
0 -
It's something we can consider in the future, but the best way to ensure that nothing is stored on Google's servers is to opt-out in Android Settings (where this is located varies unfortunately). Generally speaking, if we're having Google backup everything else from our Android devices, we're implicitly trusting them — not to mention as the OS, browser, and (sometimes) hardware vendor.
0 -
OK as the data is backed up on your servers anyways, I guess it's ok to disable backup for the 1Password app
0 -
Absolutely! Having the Secret Key backed up is more of a convenience feature. So long as you've got your Emergency Kit somewhere safe and/or another authorized device, you'll have it anyway. Cheers! :)
0 -
I tried to find where to disable app backup just for 1Password, but I failed. Do you have a hint where you found it (I know that you said it varies, but maybe I'm lucky :) )
0 -
Ah, sorry for not being clearer. What I meant is that depending on the device/OS the Android backup feature is in different places in Settings. Google doesn't provide granular controls over that. :(
0 -
Yes I got that :) . But I can't seem to find the setting on my device and I thought when you tell me where it is on YOUR device, maybe it's in the same place as on my device.
0 -
Hey @Manaburner. :)
As brenty mentioned, backup controls aren't granular. So while you can enable or disable backup for the device, you can't enable or disable for a specific app. That said, you can find instructions for disabling backups here:
https://support.google.com/nexus/answer/2819582?hl=enLet us know if you need anything else!
0 -
Hi @peri
Thanks for clarifying. Now I understand. I thought you could disable Android backup on a per-app level, just like on iOS. Hmm if I have to choose between having no backups at all or let Android store my key on Googles servers in encrypted form, I choose the latter.0 -
@Manaburner: Oh. Duh. I'm sorry. :blush:
Settings > Backup & Reset > Backup my data.
Again, sorry for being dense...
0 -
Nothing to be sorry about @brenty :)
0 -
:chuffed:
0 -
We did not introduce this until we were satisfied with the end-to-end encryption built into Android backups. Google does not have the capacity to decrypt what is sent there.
Could you please point me to what you are referring here? Google has intentionally avoided my at rest encryption questions and instead assured me it was stored on "secured servers". That's not the same. I remember a few years back when people freaked out over finding out that Google had access to their WiFi passwords.
I was on your side with the push for subscriptions. Even though I didn't need it I made the move and was an early tester because it's not hard to see that would be the end result at some point in time. Your design made that easier for me to swallow. That being me only having my key and password made that a bit easier.
Why the change?
One thing that we found is that a fair number of Android users wipe and reset their devices. Most 1Password users forget that their Secret Keys are a thing, and so suddenly people would find themselves unable to get their data.
Now pair that fact with the goal of the Secret Key. The SK is designed so that if someone gets your data from our servers (or captures the SRP verifier on first signup). Your backup on Google cannot be decrypted on anything other than your device. It's e2ee-d version of a Google server does not change that.
So here's my problem with this. These people are using a password manager to in theory have one master password and all other passwords be random and unique. Users forget they have a SK but somehow remember their Google account password. Which leads me to believe that it's either they had the foresight to write it down or back it up somewhere (which to me seems like it would not be the one to forget about secret keys) or they are using a weak Google password. So when a Google user's account is compromised the attacker can easily restore an Android device. If this is a 1Password user then that automatically fills in the URL and SK leaving nothing but the master password which as pointed out is nowhere near as strong as the combination of the 2.
My concern is not as much for me but the people that I recommended 1Password to. They are the users you are most likely talking about. I watched one login to his Google account a couple of weeks ago and he didn't use 1Password to do it. I asked why and the answer was his master password was more work and he logged in and out of Google Apps a lot. So he just uses it for "important passwords like banking and credit cards". I have no idea what his password is now but the first time it was hacked I found out that it was hist birthday.
Your backup on Google cannot be decrypted on anything other than your device.
How so? I'm pretty sure it's not device specific and from everything I see Google can decrypt it.
First of all, there is no real gain in informing you if we don't give you the ability to choose. Informing you without seeking your consent wouldn't really do anyone much good. So the question was should we have sought your consent. As I said, our decision was not an easy one.
Really?? Come on... If you informed me or other users we then have the choice to 1 voice our opinion on the direction a service we pay for is going but more importantly do what I did and immediately disable backups. For that matter decide if we still want to use the product. This one is really hard to swallow and makes me question the transparency I thought was there.
So quite simply we couldn't devise a way to ask for consent that did the following three things
So skip consent how about an email to all current subscribers. Something like....
Have peace of mind if you lose a device. Encrypted copies of your Secret Key are stored in your device backups and keychains to provide data loss protection. If you have iCloud Drive enabled and lose your Mac, iPhone, or iPad, you can restore from a backup and unlock 1Password with just your Master Password. It’s the same for Android backups.
For more information click here
It accomplished all three and took me 30 seconds to come up with. And I grabbed that from a page you guys wrote that looks like it was published after I brought this up.
Thanks and I wasn't really angry just frustrated. Though I find myself more frustrated now by the "no real gain" and "we couldn't devise a way to ask for consent".
0 -
Hi @tommyent, I really need to apologize. You were right and I was wrong.1
The way we are backing up the SK on Android (almost certainly)2 means that
- An attacker who learns a target's Google password can acquire the Secret Key
- An attacker (insider, subpoena, etc) who gains read access to Google's systems can acquire the Secret Key.
Continuing to support the backups.
As I look over notes of the meeting during which we decided to go ahead with this, I did approve this automatic backup despite having a correct understanding of the security at the time.3 I wasn't happy with it, but when confronted with the numbers of Android users losing their Secret Keys, there really was little choice.
Ideally, these backups would be opt-in, but we are trying to help exactly those people who would not go to the various settings and opt-in to this. All I can say is that this is one of those really tough decisions we have to make in designing such a product. I believe that we have made the right one, but we will be looking out for better ways of handing this and approving it.
Cheers,
-j–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits-
I now know where I went wrong. I had let myself misunderstand a statement about how Android restoration worked as being cryptographically enforced, and so concluding that a hardware key was involved in encrypting the data akin to iOS's
thisDeviceOnlykeychain attribute. It turns out that this was not cryptographically enforced; and so my conclusion about end-to-end encryption was just wrong. My attempts to find the documentation you were asking for is what led to the correction along with discussion with our Android team. ↩︎ -
We are reaching out to Google to get definitive answers on this. ↩︎
-
I really have to wonder whether it is wishful thinking that drew me to misremember and misunderstand in the intervening eight mounts since that meeting. ↩︎
0 -
@jpgoldberg thanks for the reply.
While I understand the logic behind not encrypting the SK with the master password before backing it up I can't help to feel it would be better than nothing which is the case here.0 -
Indeed, it's a difficult problem. We don't want to encrypt the Secret Key using the Master Password because that could make it easier for them to discover the Master Password (since both are used to encrypt the database, which we're assuming they have in this scenario as well). Thanks for your feedback and persistence on this. I'm not sure what the best way forward is, but you've raised some excellent points given us some additional things to consider.
0
