Some disturbing things cloud skeptics should know about 1Password 7
I have long been sceptical about the advisability of storing passwords in the cloud. I previously stored my 1Password vault on a USB drive with an additional layer of third-party encryption. I felt safe enough with a relatively week master password (i.e. one I stand a chance of committing to memory) because an attacker would have to physically get hold of the USB drive in addition to cracking the password. Plus I was not completely reliant on AgileBits closed-source security implementation. When I heard that 1Password 7 now supports local vaults in addition to cloud storage I immediately bought a licence. However in the course of setting up synchronisation with my Android phone I discovered some very disturbing facts about the storage implementation. In light of these, I have decided to migrate away from 1Password and request a refund of my 1Password 7 licence.
Basically, 1Password copies all your data from all your vaults (local and cloud) into a unified local database in a defined, un-changable, location on the local hard disk of the machine (easily discoverable by automated hacking tools). Even if you physically remove the local vault and lock it up in a safe, 1Password can still access the data with only the protection of the master password (I am assuming the data is still encrypted in this cache). On the other hand, if you accidentally disable the sync option on a vault (easily done as I found since the UI is opaque to put it charitably) there is no indication that the vault is no longer being updated. 1Password will happily carry on as normal, editing, creating and deleting entries as the vault gets more and more out of date. Down the line, you re-install 1Password, replace a failed hard disk or migrate to a new computer only to find that the passwords you thought were safely preserved in the vault are months out of date! Finally, all the vaults are accessed through the same master password, so (AFAIK) you cannot even use one local vault with a very strong password for your bank access codes, and one with a simpler everyday password and maybe cloud storage for accounts that are less critical.
Sorry guys, you are very nice people, but this implementation miss-step combined with the constant subtle pressure to move to the cloud/subscription model against my better judgement, has lost you at least one long-time loyal customer.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
No disrespect @JohnHind but most of your criticism is meaningless:
- If you can't trust 1Password then you should never use the product under any circumstances (cloud or otherwise)
- If "automated hacking tools" are present on your system then it's too late - consider everything compromised
- The cached data is encrypted with your master password. If that's a concern why not separately encrypt the folder?
- If you disable sync accidentally it won't affect you as long as you're backing up correctly (which you should be for local vaults!)
- Having multiple passwords for "less critical" accounts. #recipefordisaster (You can now use Windows Hello to simplify login)
Unless you can offer rebuttals to my feedback above I'm not convinced that there's anything wrong with what AgileBits are doing.
0 -
I believe Iran’s centrifuge program management might challenge the overreliance of USB thumb drive safety.
0 -
@MRC: This is a USB drive I personally formatted from new and keep with me (or physically secured) at all times. I never plug in random drives I find or are sent to me. That would be foolish. Also I make sure my BIOS prevents booting from a USB drive.
@gazu:
Your first two bullet points are information security heresy. Security in depth is the modern thinking - multiple layers from different vendors. Trust is not binary - I trust my next door neighbour with my front door key, but not with my savings account.
Third and fourth points might be valid if 1Password was open about the existence of the local database and ideally allowed control over where it is stored. I did not even know it existed until I started trying to sort out synchronisation with Android! How many other copies does it sneekily make without telling me? Maybe it sends a copy to the cloud even if I do not have an account? It is a typical example of 'cloudy thinking' - store your data 'in the cloud' and you have to make compromises like this for usability. IMHO they only do this for local vaults because it is easier for them to use the same scheme. There is no good reason to cache local vault data.
Your final point again is binary thinking - I trust myself to remember a master password strong enough to secure access to facebook and twitter (and this forum), not one strong enough to secure access to my bank accounts. Windows Hello may help as an additional security layer (if my computer had suitable biometric hardware) but again I'd not want to trust it alone.0 -
@JohnHind: It's definitely an interesting discussion. A few clarifications:
I was not completely reliant on AgileBits closed-source security implementation.
Our security model has always been very open:
AgileKeychain Design
OPVault Design
To the point where many users (and competitors) have created their own tools to read and write 1Password vaults. And while 1Password.com is different in the sense that there isn't a file format associated with it, we've published a white paper that describes how it works in detail:
1Password.com Security
I felt safe enough with a relatively week master password (i.e. one I stand a chance of committing to memory) because an attacker would have to physically get hold of the USB drive in addition to cracking the password.
You may be comfortable with that, but "security through obscurity" is not something we recommend or will design around. 1Password needs to stand up to attack even if someone gets the encrypted database. And it's also best to use a long, strong, unique Master Password:
How to choose a good Master Password
After all, it will be easier for someone to get your USB drive or devices than it will be for someone to break into a server that is being monitored around the clock and has the benefit of being hardened to attack already to thwart others — both white hat and black hat alike.
Again, not saying it would be easy for them to get to you, just that it would be easi_er_ than the alternative.
However in the course of setting up synchronisation with my Android phone I discovered some very disturbing facts about the storage implementation. In light of these, I have decided to migrate away from 1Password and request a refund of my 1Password 7 licence. Basically, 1Password copies all your data from all your vaults (local and cloud) into a unified local database in a defined, un-changable, location on the local hard disk of the machine (easily discoverable by automated hacking tools). Even if you physically remove the local vault and lock it up in a safe, 1Password can still access the data with only the protection of the master password (I am assuming the data is still encrypted in this cache).
Unless I'm misunderstanding you, your data is inaccessible to you until you enter your Master Password. That's because it's encrypted using a Master Password that you chose, which (presumably) only you know. I'm not sure I understand your expectations, but that's very much by design, and what most people expect.
On the other hand, if you accidentally disable the sync option on a vault (easily done as I found since the UI is opaque to put it charitably) there is no indication that the vault is no longer being updated. 1Password will happily carry on as normal, editing, creating and deleting entries as the vault gets more and more out of date. Down the line, you re-install 1Password, replace a failed hard disk or migrate to a new computer only to find that the passwords you thought were safely preserved in the vault are months out of date!
If you disable sync, either intentionally or accidentally, or make the location to told 1Password to sync to inaccessible to 1Password, the data cannot sync. I'm not sure how you think there would be a way around that. And this also seems to be in direct conflict with your expectation that 1Password not have an internal database. If it didn't have one, you've have even more trouble in this area. And you can verify your sync settings at any time, especially if you've made changes that might impact your setup.
Finally, all the vaults are accessed through the same master password, so (AFAIK) you cannot even use one local vault with a very strong password for your bank access codes, and one with a simpler everyday password and maybe cloud storage for accounts that are less critical.
Correct. That's why its called "1Password": we recommend using one long, strong, unique Master Password to encrypt your data. When there are multiple vaults present, their encryption keys are stored in the internal database, encrypted using the Master Password of the first vault/account you have setup in the app. We have not and never will recommend using a "simpler everyday password", as that's not very secure at all. And using multiple Master Passwords can cause a lot of confusion, make it even harder to remember, and also encourage using weaker passwords — "i.e. one I stand a chance of committing to memory"; there's a much higher burden of cognition having to remember more than one, especially since a single, longer password will be easier to remember out of sheer repetition, using it to unlock the app each time.
Sorry guys, you are very nice people, but this implementation miss-step combined with the constant subtle pressure to move to the cloud/subscription model against my better judgement, has lost you at least one long-time loyal customer.
To be clear, this has nothing to do with "the cloud/subscription model". More on that later.
0 -
Your first two bullet points are information security heresy.
@JohnHind: I'm not sure that statements like that serve any purpose other than provocation. We want to keep things friendly on the forums, so please consider that going forward:
Forum guidelines
This is a really interesting discussion, and it can be continued without incendiary language.
Security in depth is the modern thinking - multiple layers from different vendors. Trust is not binary - I trust my next door neighbour with my front door key, but not with my savings account.
You're not wrong, but I don't think that's really a good parallel with what's being discussed here.
Third and fourth points might be valid if 1Password was open about the existence of the local database and ideally allowed control over where it is stored. I did not even know it existed until I started trying to sort out synchronisation with Android!
This isn't a secret. And, most importantly, it's encrypted with a Master Password of your choosing, which no one else has. I'm sorry for the confusion that's caused you, but it sounds like you'd be okay if you just used a better Master Password.
How many other copies does it sneekily make without telling me?
1Password only stores data where you tell it to:
- Locally in the app — after all, we installed it and set it up; of course it has data stored in it. If you're using 1Password, it's reasonable to expect that it stores our data. That's pretty much how any app works.
- (Optionally) syncing with something else — 1Password.com, Dropbox, iCloud, a specific folder, etc.
Maybe it sends a copy to the cloud even if I do not have an account?
Nope. It isn't free for us to run the 1Password.com service, so it isn't something we can offer for free to you. And frankly we don't want the additional complexity of syncing with 3rd party services or other devices unless the user asks for it. It's much less work for 1Password — and for us — if you don't sync at all.
It is a typical example of 'cloudy thinking' - store your data 'in the cloud' and you have to make compromises like this for usability.
What's the compromise?
IMHO they only do this for local vaults because it is easier for them to use the same scheme. There is no good reason to cache local vault data.
To clarify, all of the 1Password apps have an internal database, whether you're using a 1Password.com account, local vaults, or both. Some benefits:
- Performance — database schema is much more efficient than file-based access; you can see this firsthand if you try an OPVault with an old 1Password that did not work this way (e.g. version 4 on Windows) to the same OPVault in the current version: night and day.
- Availability — also an important part of security, most people expect to be able to use 1Password even if their offline, or the local drive they're syncing to is disconnected. Most people sync data to a server, so not having internet (or having it be slow) would make for an awful 1Password experience without an internal database; and others who sync locally would literally have to keep the drive connected at all times in order to use the app. Also, WLAN syncing would not work at all if neither device had an internal database.
- Reliability — in conjunction with all the above, it would just make 1Password inconsistent and often unresponsive to not have an internal database that is always accessible, especially when trying to use 1Password in the browser.
Your final point again is binary thinking - I trust myself to remember a master password strong enough to secure access to facebook and twitter (and this forum), not one strong enough to secure access to my bank accounts. Windows Hello may help as an additional security layer (if my computer had suitable biometric hardware) but again I'd not want to trust it alone.
Inappropriate comments about the viability of others' thought processes aside, you're absolutely entitled to make yourself jump through hoops to secure your data if you want to. But, again, the purpose of 1Password is, as the name suggests, to allow people to secure their data behind a single, strong Master Password so that they don't have to remember anything else. You can have security and convenience too, but it's your choice. We're going to continue to design 1Password so that it's resilient to direct attack, not hope that no one can ever get someone's encrypted data, as there are enough 1Password users out there that even a small percentage getting their vaults stolen needs to be able to count on 1Password to protect it even then, not hide behind convoluted strategies to secure it. That would be unacceptable to most people. And it's unacceptable to us that someone's important data would be compromised because we built 1Password on the assumption that no one ever finds the vault itself, so it's our job to ensure that 1Password is up to that challenge.
0 -
Re forum guidelines - I take the criticism but ask you to note the confrontational tone of the @gazu posting I was replying to.
In practical terms, I wanted to preserve the "have something and know something" approach I previously used. Currently the security posture depends not solely on trusting 1Password but also trusting my own ability to select a strong enough master password (and not get so irritated when I have to type it every time I just want to log into the AgileBits forum)! This was subverted by the 7 design (it may have been subverted earlier and I just failed to notice, I guess it was on the Android app).
I want to be in control of where my data is stored both so I can ensure it is protected and so I can ensure it is backed up. I would be reasonably happy with the current design if it allowed me to set where the cache database is stored (so I could put it on the USB drive). Or there could be the option to additionally encrypt the cache database with an automatically generated strong password stored in the vault. That way the cache data would be inaccessible unless the vault was accessible. (Some might not want this, but it could be an option). There is an asymmetry here: everything I am likely to store in 1Password is recoverable if lost (it would be painful, but possible) but it would be life-altering if some of that data was exposed to the wrong people.
Part of this is expectation: you transitioned from a position of the 'vault' being the primary data store, to that of the entity with the same name being a (potentially off-line) backup of the data. Keeping the same metaphor, but changing what it means behind the scenes is unsettling!
0 -
Re forum guidelines - I take the criticism but ask you to note the confrontational tone of the @gazu posting I was replying to.
@JohnHind: I didn't see that as a personal attack/insult, but you're right, that wasn't a very friendly thing to say either. Thanks for pointing it out. I don't want to discourage you from having this discussion with us; I just want to make sure we can all do so civilly. Thanks for understanding. :blush:
In practical terms, I wanted to preserve the "have something and know something" approach I previously used. Currently the security posture depends not solely on trusting 1Password but also trusting my own ability to select a strong enough master password (and not get so irritated when I have to type it every time I just want to log into the AgileBits forum)! This was subverted by the 7 design (it may have been subverted earlier and I just failed to notice, I guess it was on the Android app).
I get where you're coming from, but 1Password has never had a "have something, know something" security model. As I said before, our assumption is always that a competent attacker can get the encrypted database if they really want to, so with that off the table, we design accordingly. 1Password still needs to be able to protect our data in that scenario. So we're then down to "something we know": a secret which is stored only in our brains used to secure the data. Where we failed to communicate that in the past though, I apologize.
I want to be in control of where my data is stored both so I can ensure it is protected and so I can ensure it is backed up. I would be reasonably happy with the current design if it allowed me to set where the cache database is stored (so I could put it on the USB drive).
That probably isn't something we're going to do since, as I outlined earlier, that can cause real usability problems. It can also result in data loss when reads and writes fail. So even if we do this, we'd still need an internal cache to compensate for that, and therefore you'd be in the same boat again.
Or there could be the option to additionally encrypt the cache database with an automatically generated strong password stored in the vault. That way the cache data would be inaccessible unless the vault was accessible. (Some might not want this, but it could be an option). There is an asymmetry here: everything I am likely to store in 1Password is recoverable if lost (it would be painful, but possible) but it would be life-altering if some of that data was exposed to the wrong people.
Ultimately we're in agreement on the principles here: this data needs to be protected by a strong password, and we also need to protect against data loss. But we're already doing that: the Master Password is used encrypt all of the data, whether in the internal cache or sync'd copy of the vault (or backups of it); and we have failsafes in place (caching, backups, etc.) to avoid problems with data availability or damage. But it seems like you want 1Password to generate a strong password for you and remember it for you, and use that to encrypt the data. The problem is that this does solve a problem; it just pushes it further out. If you're still using a Master Password that you're not comfortable relying on to secure your data at some point abstracted out further (so that it decrypts something else, which in turn decrypts something else, and so on), it's still a weakness. And, in fact, that would also mean ceding some control over your data, if you have 1Password effectively choose a "master password" for you. Food for thought. Ultimately the security of using 1Password or any password manager where the user has direct control over their security by dint of choosing their master password is going to rely on the strength of that master password. There's just no way around that, and we don't want to give anyone the false impression to the contrary. There are any number of strategies you can employ to ensure that you yourself don't get locked out. Some folks share this information with a trusted friend or family member. Others save it in a safe deposit box, or entrust it to an attorney. It's really a personal decision.
Part of this is expectation: you transitioned from a position of the 'vault' being the primary data store, to that of the entity with the same name being a (potentially off-line) backup of the data. Keeping the same metaphor, but changing what it means behind the scenes is unsettling!
That's fair. We have changed some things over the years, though not with 1Password's security model. I'm sorry this caught you off guard. And, frankly, it's caught me a bit off guard as well, since this is how most of our apps have worked for years already, and we just haven't had anyone else react to it this way — customers, security professionals, companies. And I think that's because, while structurally different in some ways, the fundamental principle is unchanged: the user chooses a Master Password that is used to encrypt their data. Again, I'm sorry that it came as an unpleasant surprise to you that the security of your 1Password data truly rests on the Master Password you choose, but it's important to us that everyone has this control. "With great power comes great responsibility", as they say. Thanks for taking the time to give us feedback on this, as it's something we'll have to keep in mind as we continue to work to communicate to users how 1Password safeguards their important data.
0 -
No disrespect @JohnHind but most of your criticism is meaningless:
@gazu: I don't want to discourage you from participating in discussions like this here either, but please review the terms of service:
Forum guidelines
This is definitely an important topic, and one we're all clearly passionate about. Let's just keep it friendly, even when we're in disagreement. :blush:
0
