How to handle exposure of master password?
Somehow (and I wish I knew how!), as I was typing my master password into the Safari extension, my keyboard focus changed and my master password got transmitted to a website. Doh!
So my master password is sitting both in someone’s HTTP access logs and an NSA server. Undoubtedly in the same AWS datacenter that my 1Password database sits on in Dropbox. :)
I’ve since reset my master password and was going to reset the passwords I’m the most paranoid about being exposed, but being a software engineer who has some experience with these sorts of systems, I figured this might not be the end of the story. From what I’ve read about the way 1Password works, the master password is used to generate a key to encrypt the master key, which is actually what is used to encrypt the database. This is good and makes sense, however it also appears that changing the master password does not also cause a new master key to be generated and the database to be re-encrypted. That means an attacker with my exposed master password and a copy of my master key encrypted with that exposed master password, can continue to decrypt even new things I put into 1Password.
What’s the best way to handle this situation? Is there some way to get 1Password to regenerate the master key? I’m currently on 3.8.21 on my Macs and version 4.5 on my iOS devices. (I intend to upgrade to version 4—apparently I somehow missed the announcement for the Mac version!)
Thanks!
-Eric
Comments
-
Hi @limulus,
The only way to re-encrypt your data using a new master key is to start over with a brand new vault. You'd need to export your data to a 1PIF file, start over with a new database/vault, then re-import your data from the 1PIF file.
If you need any help with this, or have any questions, please let us know!
0 -
This will do the trick! Thanks very much!
-Eric
0 -
You're welcome, Eric! Please let us know if you have any other questions. We're always here to help! :)
0 -
Interesting, you've just exposed a security loophole in 1Password:
- I steal someone's 1Password database and they have the password "hello", so I easily crack it.
- They figure out that the password was stolen, so they change their password, thinking they will be safe after that.
- Nope! All I have to do is use the old database with the "hello" password to decrypt the master key, and then use that same master key on their new database too. There are python reimplementations of 1Password's decryption process and they could easily be modified to do exactly this: "crack.py newDB oldDB oldPassword"
I'm not personally concerned since my password is over 26 characters of all character sets. But damn this is a pretty sweet vulnerability. :P
0 -
@JasperP - How should users who want to re-encrypt their data handle syncing to iOS versions? Just turn off syncing until the reset is complete on the Mac, and then turn syncing back on? My recollection is that master password changes now sync to iOS devices. Will the newly encrypted data also find its way there?
0 -
Never mind. I did start over according to the directions. I did disable syncing first. Everything worked fine, although I ended up with a handful of conflict entries. Those might be caused because I neglected to let my iPad finish catching up before I started up syncing on my iPhone. Not sure, but I was interested that at least some records with conflicts were records that had them before.
0 -
Hi guys,
At that moment, the first goal for customers to do is to kill that ingress to their data. Even if they re-encrypt the entire database with new encryption keys, you can steal it again and begin the brute-force to find the new password. Once they kill the access, then they should definitely focus on how to recover from this. I'll tag in @jpgoldberg as he's the awesome guy who loves talking about this. :)
@hawkmoth: Generally, we'd recommend to erase the data (after doing a backup) in the iOS app [Settings > Advanced > Erase Data] and then sync again from your Mac.
0 -
@MikeT Yeah, and it would be a rare attack which relies on a perfect storm of circumstances where you have an already-cracked database, and one with a new password.
Whatever the original reason for this master key re-use, why not change it to re-encrypt all data, @jpgoldberg? If I change my password due to a security leak, wouldn't it be nice to have the peace of mind that changing the password actually changes the master key, since that's the true password for the data. If the master key isn't changed, all new data is still accessible to anyone who already cracked my old database...
0 -
Generally, we'd recommend erase the data (after doing a backup) in the iOS app [Settings > Advanced > Erase Data] and then sync again from your Mac
I had not been aware of that! bit now that I think about it, it makes sense. And once I did that, the conflicts all disappeared. :D
0 -
Hi hawkmoth,
And once I did that, the conflicts all disappeared.
I'm glad to hear that.
Whatever the original reason for this master key re-use, why not change it to re-encrypt all data, @jpgoldberg?
My understanding is at the time we made this decision, this was due to performance reasons not only on the devices but also for the sync. We probably do have plans to change this in the near future but I'm not sure. Jeff would be the best person to know.
0 -
Whatever the original reason for this master key re-use, why not change it to re-encrypt all data, @jpgoldberg?
As @MikeT pointed out, there are performance reasons that apply now as well as to when the system was designed, but the real sticking point is how this would work with synching. The potential for substantial data corruption is enormous.
My primary vault is 21 megabytes. Re-encrypting that would be more than simply re-encrypting a single 21MB file. This is because we have things set up (for other reasons) so that each item is encrypted separately (there are good security reasons for that.) So each item would need to be re-encrypted separately to re-encrypt things. That, of course could be done and made reasonably robust with making a copy before starting the process, so that if something goes wrong half way through (power outages, etc) there would be something to roll back to.)
Re-encrypted everything means re-syncing everything
The first thing to think about when it comes to synching is that if my entire 21MB (I don't really use that many attachments, as I use Knox for that sort of stuff) is to be re-encrypted that all of that 21MB must re-sync. Sure, I've got an unlimited data plan for most of my devices, but not everyone does. (This, by the way, is why we limit attachment sizes.)
Sync conflict could lead to serious data loss.
For this discussion it is important to note that in the sync process for 1Password the operation has two major steps. I will call these "translation" and "transfer" until we settle on good names for these.
Translation
Your data is stored in a database that is optimized for your local platform. This is the "local format". This is what 1Password actually is using when you are interacting with it. 1Password will keep that local data "in sync" with a "sync format". The sync format is either an opvault or an agilekeychain. 1Password needs to decrypt and encrypt items to get the local format to match the sync format. You can kind of think of Translation is exporting and importing data to and from a sync format. It does involve intelligent merging.
Transfer
The other half of the operation is fetching and pushing the sync format files to and from the sync service. For this, 1Password is almost not involved at all. It's up to Dropbox and iCloud (or whatever sync system you might be using with, for example, Folder Sync). As this is just sending and retrieving encrypted data this part of the operation doesn't require 1Password to be open. There is also some conflict resolution that can happen at this stage, which is why we don't encrypt last modify times for items.
A conflict scenario
Suppose you create an item, say it is "Secure note with my Swiss bank account numbers", on device A. 1Password will be able to immediately translate this to the sync format, say Agile Keychain, that you are using. So on device A, your .agilekeychain will have this item in it. It can do this even if you have no network connection at the time.
Suppose also that device A isn't connected to the network at the time (or for some other reason isn't able to do the transfer). So it cannot transfer the changes to, say, Dropbox. That is normally fine.
Now suppose that on device B you change your Master Password with a full re-encryption. 1Password on B will do the translation, and so there will be megabytes of replaced data in ones Dropbox folder. Unlike A, B has a nice connection to the net and so can transfer these megabytes of data to Dropbox.
Now let A get reconnected to the network. It has a lot of data that it needs to fetch from Dropbox and it has this one new item that it needs to add. It goes and does that. B also gets that new item from Dropbox and transfers it it.
That new item is in the Agile Keychain but it is encrypted with a key that is no longer available. It is not encrypted with the same key as all of the other items.
Counter measures
There are, of course, counter-measures that would protect against data loss in this specific case. The new item is still available in local data on device A. So when A does its transfer with the re-encrypted data it has fetched with Dropbox it might be able to detect what happened and handle it as it will have to know both the old and new Master Password to handle that first merge after the change on device B.
But those sorts of counter-measures wouldn't work in the general case (of a variety of changes from multiple sources). The risk of ending up with items in your vault that can't be decrypted is really substantial.
Another conflict scenario
Take the above situation, but now imagine where after B does the password change and translation, the transfer to Dropbox stops part way through. Some items will be encrypted with the old key and some with the new ones.
Again, we can imagine counter measures. They involve using a special data format for just these cases that would be an "atomic" transfer. That is, instead of sending to Dropbox a 1Password.agilekeychain, we would send a 1Password.agilekeychain.zip. This then leads to other enormous complications as the Transfer process has to figure out what to do when it finds both a 1Password.agilekeychain and a 1Password.agilekeychain.zip. Furthermore, given various sandboxing requirements, it may not be able to detect the presence of the .zip file.
tl;dr
We would have to either pretty much abandon efficient, secure synching in general or allow for a strong potential for substantial data corruption if we were to allow for re-encryption of everything in a vault.
But things are improving
The advice that we've hitherto given about how to re-encrypt everything has been to export data to 1PIF, ditch your local date, create a new (empty) vault, and then import into that from 1PIF. With things like Folder Sync, we can replace the (unencrypted) 1PIF with an Agile Keychain (or OPVault, when that becomes available). You would still be starting over with a new vault, and it would be treated as a new vault on the devices you sync with, but a number of the steps needed to do this are easier in 1Password, now that with Folder Sync you can create a "sync format" keychain anywhere on your machine.
0 -
@jpgoldberg - that is a very informative post, but it made me start thinking again.
I recently did export my data and re-encrypt it, as described in that last paragraph. I did so because, although I can no longer remember exactly, I think I first began using 1Password with what would be regarded as a weaker master password than the Diceware one I adopted later. I assumed that because my data were not re-encrypted when I changed my master password that they were more vulnerable to attack than they would be if they were encrypted with the stronger master password. I know that I've done no harm by doing this, but now I'm curious to know if I did any good for myself. Does the strength of the master password translate directly into stronger security through stronger encryption? I know that attackers aren't likely to be trying to guess my exact password, but rather will go after the encryption key itself. So it seems like what I did was a step in the direction of better security than if I has just changed the password and done nothing more.
0 -
Thanks @jpgoldberg for your detailed response!
Ultimately, I think the issue at hand—I’m hesitant to call it a vulnerability—is that most users’ mental model of what the “change master password” functionality does does not match the implementation of the software. When password exposure happens I suspect that most users, even highly technical users, do not think to go and create a new vault, they simply change their master password and the passwords in their vault and think they have fully protected themselves from future attacks.
Truth be told, when I changed my master password I was expecting to see the Dropbox status icon spinning for a good while as it synced the re-encrypted database. The fact that it only took a second was the clue to me that 1Password didn’t re-encrypt.
Since it sounds like getting the software’s implementation to match the user’s mental model isn’t a viable option, perhaps the next best thing is to make sure the user’s mental model matches the software’s implementation? An obvious—if not very UX-friendly—approach would be a warning dialog that informs the user that if they are changing their master password because they have reason to believe another party has access to it, then they ought to be creating a new vault with a new password and deleting the old vault. Perhaps a more friendly option might be to have another button along the lines of “Help! My Password Was Leaked!” that steps the user through that process. Anyway, you all are much better at UI design than me, so I’ll stop thinking aloud. :)
Thanks again!
Eric
0 -
Haha, I’ve been using “limulus” as an online handle for a long while now. Result of having parents really into Marine Biology. :D
0 -
And same for me with hawkmoth, although it's closer for me than my parents. (Me) But Lepidoptera for me.
0 -
@limulus got to the heart of the problem with:
I’m hesitant to call it a vulnerability—is that most users’ mental model of what the “change master password” functionality does does not match the implementation of the software.
Yes. There are indeed spectacular cases (not with 1Password) where this kind of thing has caused problems. Neither Wikileaks nor the Guardian wanted the "cablegate" documents to be released un-redacted. But it happened. And it happened because of a break between mental model and reality that is, in essence, the same difficulty we are facing here.
My explanation of the reasons why full re-encryption would be difficult doesn't mean that we are going to ignore this problem. It was just an explanation of why the "obvious" solution wasn't something that could easily be done. I've submitted a talk proposal to PasswordsCon on this. I don't know whether it will be accepted for the conference or not, but one way or another you will be hearing a lot more from me on this topic over the coming months.
0 -
@jpgoldberg, glad to hear this and impressed! I hope your talk gets accepted. I hadn’t heard of PasswordsCon before and now I’m tempted to go. Already going to WWDC and NodeConf, perhaps I might as well make the first year I start going to tech conferences a trifecta…
0 -
PasswordsCon has a history of being fantastic. And it is small enough that everyone really does get to spend time with everybody.
I will be at WWDC (first time), but I have no idea of what my schedule should be like. I expect that I'll be "advertising" my location and available on Twitter, jpgoldberg.
0 -
Cool! If I see you, I'll be sure to say hello.
0 -
Another quality thread!!
Since you mention Dropbox, @limulus, I thought I might toss in the thought that, if one's master password has been compromised, one must consider the threat presented by backups and old versions of the keychain. In your specific case, the primary threat may be old files and versions of files recoverable online at Dropbox.com. In other circumstances, one might be more inclined to worry about old files on the various and sundry devices that your Dropbox account syncs to, and in backup files for those devices.
And so on.
0 -
The issue of backups potentially being used against me is why I have disabled them when possible (in older versions it's supported to do so), or blocked them (by folder tricks, mostly) from being generated on all but a select set of computers. I really don't need my Mac server, various laptops, Windows box and VMs, etc. all making backups on their own.
I wish that 1Password 4 provided a way to disable backups on a given computer for the same reason. I understand completely why having backups somewhere is crucial to all users but not on every computer and device. At least not in my own environment.
With a "basic" Dropbox account I think the retention period is 30 days so that's not terribly long for older revisions of any backups you may have placed there to be flushed after deleting them. Yet it's too bad they don't have a "purge my deleted items now, please" option available — or at least I couldn't find one.
0 -
Thanks for sharing your thoughts here, guys!
0 -
Could we just go back to a comment made by hawkmoth:
Does the strength of the master password translate directly into stronger security through stronger encryption? I know that attackers aren't likely to be trying to guess my exact password, but rather will go after the encryption key itself.
Its clear in this thread that changing the master password does not automatically re-encrypt the existing data.
jpgoldberg addressed the problems associated with automatically re-encrypting the data.
To re-encrypt the data as jasperP says:
The only way to re-encrypt your data using a new master key is to start over with a brand new vault. You'd need to export your data to a 1PIF file, start over with a new database/vault, then re-import your data from the 1PIF file.
So thats OK.
So, "casual" attackers could guess or determine a weak master password more easily and hence gain access to the un-encrypted data... so strong master passwords are important....OK...
But, if "serious attackers" aren't likely to be trying to guess my exact password, but rather will go after the encryption key itself then, against "serious attackers", it implies that strong master password entropy doesn't matter all that much. Is this right? Or does the strength of the master password translate directly into stronger security through stronger encryption?
Finally, (assuming it is correct that serious attackers will go after the encryption key itself) then I guess that this is very hard to do and is the entire point of the architecture used by 1Password - is this right?
(As an aside, I guess series attackers are going to try both attacks - via the master password and via the derived encryption key - so you must have a strong master password regardless)
0 -
Hi @toasted,
No, that's not correct. Any attacker will attempt to brute force your Master Password, and won't be attacking the encryption itself. Your 1Password Master Password is extremely important. Although we take steps to thwart automated password crackers, you still need to use a strong (but memorable) Master Password.
Given the strength of the encryption we use, your Master Password is almost certainly the weakest link in your 1Password security.
Your data is encrypted with a randomly chosen 256-bit encryption key when you first set up your 1Password vault for the first time - this is your "master key". Your master key is used to encrypt your data, and the master key is what gets encrypted with your Master Password. Given how strong this is, it would be practically impossible to use and remember a Master Password that is actually stronger than 1Password’s encryption. Humans can't reliably use and remember a password with 256-bits of strength. Even if you're still using our old Agile Keychain format, which is still needed for Dropbox or Folder sync, the AES-128 encryption used is still most likely stronger than any Master Password. Most people also can't reliably remember and use a password with 128-bits of strength.
The chances of someone successfully brute forcing even AES-128 encryption is as close to zero as we could possibly want. With AES-256 encryption, the chance of a successful brute force attack is another number as close to zero as we could possibly want. The difference between the two, for all meaningful purposes, is zero. If you're interested in more details about this, please see this blog post. Basically, brute forcing the AES encryption we use would take an extremely long time (nearly impossible in a human lifetime).
Instead, an attacker will most likely attempt a brute force attack to guess your Master Password. But with tools like PBKDF2 combined with password schemes like Diceware, we can create passwords that remain very resistant to cracking (PBKDF2 requires that there be lots of computations to go from an entered Master Password to actually decrypting your 1Password data). Our measures to slow down automated guessing helps a great deal, but they are no substitute for a great Master Password. You need to pick a strong Master Password, and there are some great blog posts on how to do that, here and here.
Please let us know if you have any other questions. :)
0 -
Thanks for taking the trouble to describe that for me and to correct my understanding (or lack of it)
That makes sense to me now. Most appreciated. Cheers !
0
![[Deleted User]](https://wa.vanillicon.com/v2/aa551b5e3bb9d35655a15cf30ed1e3f1.svg)
