Make Android "saved accounts" opt-out.
As discussed here, the convenience of Android saved accounts introduces a small but significant attack vector. There was consensus from 1Password staff that the situation was not ideal, but that the compromise was the best choice to help users who were locking themselves out of their database when resetting their phones.
It has been a year since that was brought up, and it remains an issue. I understand 1Password's position that backing it up is the best choice for most users, and that making it opt-in introduces additional complexity to the on-boarding process that could confuse some users.
Given that opt-in appears not to be an option, can we at least be given the choice to opt-out? Back it up by default, and allow advanced users to change that in the settings menu.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:Make Android Saved accounts opt-out
Comments
-
While I don’t think this request is unreasonable by itself, I think it is worth considering:
- This would mean adding yet another preference to the apps
- How many people would choose to use said preference?
- How many people would inadvertantly or misguidedly enable this preference, resulting in data loss?
I suspect that only a few dozen people would choose to opt out, which makes justifying 1) the development time to implement this across all of the apps that do it and 2) the additional “bloat” in the settings menu rather difficult. Additionally chances are likely that some customers would misunderstand the purpose of the preference, or toggle it for misguided reasons, and end up losing their Secret Key as a result. Consider that data availability is a critical part of information security that is all too often overlooked. If legitimate users are unable to access their data we’ve failed as well. If you look around this forum you’ll see that one of the most common issues is customers losing/forgetting their credentials for 1Password. If anything I think we need to do better in that regard, rather than giving folks more opportunity to do so.
In this case, while perhaps not “ideal,” I think we’ve struck the best balance possible considering all of the factors.
Ben
0 -
The single biggest selling point for me to switch to your hosted service was the white paper on the Secret Key and the genius of "two-secret key derivation".
I just re-read your white paper, and it still doesn't acknowledge the security hole: "The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s Master Password." That is a demonstrably false statement. It was pointed out a year ago, and AgileBits still has not even taken the corrective step of adding warnings about the risks device backups pose.
I am all for avoiding "bloat", and understand the balance act required when deciding where to devote development resources, but this issue speaks directly to the core mission of your company. This is more critical than those concerns, I don't accept them as valid arguments.
Your point regarding data availability, and the potential confusion of less advanced users, is more valid. Inevitably, should this feature be implemented, there will be some Lifehacker article "Turn on this feature in 1Password right now to make your passwords more secure", which users will only half read, totally miss the part about making sure they've actually printed out the emergency kit and stored it somewhere safe. I get that, and it is a problem. That just puts the onus on your design team to thoroughly communicate that to any users disabling backups.
At an absolute minimum you need to update your white paper.
0 -
The line you’ve quoted was written in the context of speaking about 1Password.com/.ca/.eu. It isn’t a general reference to all remotely hosted data. As such I believe it is only false when taken out of context. The Secret Key is a great tool in the 1Password toolbox, but it isn’t designed to protect against someone having access to your device (or a backup of your device). The primary purpose of it is to protect you against someone who has access to the encrypted 1Password data from our servers. If someone has access to your device (or a copy of it) that is an entirely different attack vector than what the Secret Key was designed to protect against.
It is definitely an interesting conversation. Some further background on the Secret Key can be found here:
https://support.1password.com/secret-key-security/
Ben
0 -
Your white paper very clearly states multiple times that the Secret Key is only ever on the device, never remotely stored. You could be forgiven for not issuing a warning about online backup services like BackBlaze, etc. But, using the Android key-value store you made a conscious choice that will cause the Secret Key to be remotely stored by default. You've known you were remotely storing this data from the inception of the feature, and that the security hole it presented was far larger than you originally thought for over a year.
That your response is to argue the semantics of the white paper, is worrisome. I'd feel a lot better if the response were "Oh crap, that omission is misleading. We need to fix that."
0 -
I have a related question. How are these users gaining access to their Google Account without 1Password?
Are they using their master password as their Google password? I guarantee you some are. Think about that horror. Now it's literally only the master password protecting your cloud stored database.
Are they using Googles password recovery? Awesome, now we've added one or more accounts / phone numbers as additional attack surfaces.
This is insane. You've got to give users the option to turn this off, regardless of what it does to your support queue,
0 -
Your white paper very clearly states multiple times that the Secret Key is only ever on the device, never remotely stored.
The important distinction is that it isn’t stored by us. But I’ll agree that perhaps more appropriate wording could be selected here to properly convey that meaning. I’ll pass that feedback along to the team that puts the white paper together. Thanks for bringing attention to it. I don’t know when the next revision to the white paper is planned, but hopefully we can improve the clarity here.
But, using the Android key-value store you made a conscious choice that will cause the Secret Key to be remotely stored by default.
Correct. We do the same thing on Apple platforms with iCloud Keychain.
You've known you were remotely storing this data from the inception of the feature, and that the security hole it presented was far larger than you originally thought for over a year.
I respectfully disagree, and would not consider this a “security hole.”
I have a related question. How are these users gaining access to their Google Account without 1Password?
I suppose you’d have to ask them that. For me personally my Google Account password is one of the few passwords I have memorized, along with my device passwords/passcodes, Apple ID password, and of course 1Password Master Password.
Are they using their master password as their Google password? I guarantee you some are. Think about that horror. Now it's literally only the master password protecting your cloud stored database.
I suspect you’re correct, though we warn against this in all kinds of places, and of course stress the goal of “secure uniquie passwords” being one of the primary reasons to use 1Password in the first place. There is only so much we can do to prevent people from shooting themselves in the foot (the topic at hand being one of the measures we’ve taken to try and do so).
A strong Master Password is sufficient to protect a 1Password keychain. Take a look at 1Password’s ability to sync with Dropbox for example. There is no Secret Key involved there. Again the purpose of the Secret Key is to help strengthen the Master Password and protect against a breach of 1Password.com, not against a breach of your device (or device backups).
This is insane. You've got to give users the option to turn this off, regardless of what it does to your support queue,
Respectfully, that’s not how this works. As I mentioned we believe we’ve made the correct choice here, and do not have plans to change it. We’re happy to discuss why we’ve made the decisions we’ve made, what impact we think those decisions may have, and what your perspective is on the situation. We’re open to feedback but we don’t take demands or orders.
Ben
0 -
Forgive me for sounding demanding. That wasn't cool. I am just trying to express my disbelief that you guys aren't really worried by this.
I understand that Local Vaults and Dropbox synced vaults don't use the Secret Key. Honestly, it would be awesome if they did (or there was an option to).
0 -
Forgiven. :) I think part of the difficulty is it seems we're still not quite on the same page regarding the purpose of the Secret Key. The primary function of it is to protect customers if 1Password.com is breached. It does this by adding additional entropy to the decryption keys so that even if someone inadvisably chooses a weak Master Password an attempt to brute force the decryption keys on a database-wide scale would prove effectively impossible (which also deters such an attack on our servers). It takes the target off 1Password.com. It wouldn't be an effective deterrent in cases like Dropbox or iCloud because those services also hold a lot of other valuable data. If someone is going to attempt to steal data in bulk from one of those services 1Password keychains synced there having additional entropy wouldn't be any deterrent. Likewise if you are specifically targeted and so someone is going to go to the lengths to steal your device or device backup the Secret Key isn't a deterrent. It wasn't designed to be.
We'd recommend increasing the length / entropy of your Master Password if you are concerned.
Ben
0 -
I think part of the difficulty is it seems we're still not quite on the same page regarding the purpose of the Secret Key.
No, you have made your position clear. I just want the option to disable it.
There is only so much we can do to prevent people from shooting themselves in the foot
I agree. This is why I don't understand an option to disable it is a non-starter. Provide people fair warning, and if they shoot themselves in the foot - well, you told them.
0 -
https://support.1password.com/sync-options-security/
Secret Key. 1Password creates a private, 128-bit Secret Key to encrypt your data. This key never leaves your devices, and it gives your account another line of defense together with your Master Password.
This is obviously flat out false.
0 -
https://support.1password.com/secret-key/
Your Secret Key is your secret. It protects your account together with your Master Password, which only you know. We don’t have a copy of your Secret Key or any way to recover or reset it for you. To find your Secret Key, you’ll need one of the following:
- the 1Password app on any device where you’re already signed in to your account
- a browser you’ve used to sign in to your account before
- your Emergency Kit
If don’t have one of those, but you belong a family or team account, ask a family organizer or team administrator to recover your account.
If you still can’t find your Secret Key, and a family organizer or team administrator isn’t able to recover your account, you’ll have to start over.
This omits than you can also restore it from a device backup.
0 -
I’ll mention these points to our documentation team. Thanks.
Ben
0 -
What about reserving this option for the administrators of Family or Team plans? They could turn off the backup for team members and themselves. This reduces UI bloat for your average user, and the account administrator is likely more sophisticated and able to understand the implications of disabling the backup.
0 -
It's certainly something we can consider. Just keep in mind that you can always opt-out of backing up to Google's servers if you are not comfortable trusting them even with encrypted data. Thanks for your feedback.
0 -
@brenty - If Google allowed granular control - I absolutely would just disable it for 1Password. Indeed, that would be the better option, because it would be solved for all apps.
0 -
I can't argue with that. :)
0
