Changing your Master Password: What's the complete process?

That is a great (and somewhat tricky) question, @leesweet.

It looks like I'm going to have to break up my response into two parts.

First I really have to advise that you never enter your Master Password into anything that isn't 1Password. The zxcvbn project at Dropbox is a cool project (and I should blog about it at some point), so you are probably OK here if you really did enter in your real Master Password. But still, never, ever do that. Just test with a password that was created with the same system that you used to create your real one.

My tentative title for a post on that project would be "all password strength meters suck (including ours)", and then talk about how zxcvbn is working to really make a good one by explicitly addressing what makes all current ones fail.

Anyway, their time calculation is based on the assumption of throwing 100 processors each cracking at a rate of 10 per second. This is generous to the attacker (assuming PBKDF2), and dramatically ungenerous (to the attacker) if something like PBKDF2 isn't used. My own calculations in the John the Ripper article were likewise very very generous to the attacker.

So those attack times are very pessimistic (from the defender's point of view) as they include the most conservative assumptions. You may not need to change your Master Password at all.

But if you do ... you'll have to wait until I write part 2 of this response.

Cheers,

-j

–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com

Sorry it's been taking so long to get to part 2. I'm going to have to ask for some continued patience there.

Cheers,

-j

–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com

Jeff is super busy, and this is on his long list, but he can't be everywhere at once. I've been pinging him now and again to see if he could follow up. Hopefully sometime in the not to distant future. Please let me know if you have any specific questions, though. I'd be happy to answer them.

I guess the next question is: Should there be an easy way to change the MP and it fixes all this stuff?

You really like asking hard questions, don't you?

Changing your master password really should have all of the intuitive security properties people expect. There shouldn't be surprises. This is called the "Principle of Least Astonishment" (POLA). And in this case, we fail to deliver on this.

One thing that I've said many times, and I'll continue to say is that security trade-offs are often trade-offs between one type of security and another. Our breaking of POLA is a consequence of our security design. Having a security design that corresponds to people's intuitions, however, can be bad for security for other reasons. So we had to make a choice. I think we've made the right design choice, but I have to acknowledge that it means that the effects of a password change can be surprising.

Your individual items are encrypted with a random key that is selected when you first create your 1Password keychain. That key is a 128 bit number. (Actually, I'm taking a bit of a shortcut here.) Your data is encrypted with that key. It is that key which is encrypted with your Master Password. So when you change your Master Password, the actual key doesn't change. The only thing that changes is how that key is encrypted.

Actually generating a new key and then re-encrypting everything with that new key would not only take a long time; it would be a fragile process. It would have a substantial potential of leaving people with corrupt data. We are in very good company with this design. High security systems like PGP/GPG and SSH have this structure. But it makes the actual relationship between Master Password and the data encryption different than the the way most people using 1Password will imagine.

Anyway, your encrypted key lives in the file encryptionKeys.js within your 1Password.agilekeychain (which is actually a folder and not a single file). The other files I mentioned, 1password.keys and .1password.keys, were used by earlier versions of the Agile Keychain Format. So when you change your Master Password, only those files change. (In the format coming with 1Password 4, the relevant file is called profile.js.)

We make all of this information available to people (our data formats are documented), but instead of trying to explain this all when someone opts to change their Master Password, we simply advise people that they should pick a good, unique, Master Password and keep it for life.

In 1P5? 1P6?

If we could find a way (and we keep looking) that will

1. Be a full change.
2. Happen quickly enough to be feasible
3. Won't lose data if some other syncing operation takes place during the (long) change.
4. Won't lose data if something crashes during the (long) change.
5. Won't leave people without usable backups

then we will implement it.

What's the downside of just changing it, which was more my original question, since we were told not to 'just' change it.

Suppose that Molly creates her 1Password data on January 1, 2009 with password "abc". On June 30, 2009 she changes it to "xyz". Now suppose that she continues to use it to the present day. Now suppose that Patty has managed to get a copy of Molly's data from the first half of 2009. Patty also gets a copy of Molly's data from today.

Patty now has two ways (instead of just one) to get at the key that all of Molly's current data is encrypted with. Patty can try to crack the encryptionKeys.js file from 2009, and she can try to crack the encryptionKeys.js file from 2013. Once she has broken either one, she then can get a key (this is the random 128 bit number) that can actually be used to decrypt all of today's data.

So each password change, assuming that the attacker has access to historical data, gives an additional opportunity to crack things. This is why, other things being equal, the fewer password changes the better.

One comment: Did you mean that the deletions should occur only on the one device where you made the MP password and (I assume?) we only need to change the MP in one place/on one device (using current software (3.9 on OS X and Windows, and 4 on iOS)?

Correct. We are only trying to get rid of the old backups of encryptionKeys.js (and copies of that data in 1password.keys). You should only remove the backups. Dropbox keeps backups (which you can remove), Time Machine (if you use it as you should) keeps backups.

That is, the threat that I'm considering is where someone gains full read access to your computer or to your Dropbox account. That access would include the ability to get steal the backups as well as steal the current versions.

I keep seeing these threads about the 'old one still works'. It's a bit confusing.

That is a different issue. It has to do with how password changes are propegated. 1Password on iOS does not use the 1Password.agilekeychain data directly. Instead, it translates it into a form that is more efficient to use on the iOS devices. So there are actually two copies of your data on our phone (or three copies). There is the 1Password.agilekeychain that it gets from Dropbox. There is the SQLite database that it translates to for actually using locally. And if you are using iCloud syncing to sync with other iOS devices there is the 1Password 4 Cloud Keychain Format (we really need a better name for that) which will eventually replace the Agile Keychain Format.

The details of propagating a password change around all of these systems are tricky (and are also subject to change). But without the SQLite file on iOS is an encrypted copy of the key used for the Agile Keychain format. This means that when you enter your Master Password on your iPhone, 1Password can also decrypt the data in the 1Password.agilekeychain so that it can synchronize changes with it. So this allows (at the moment) a situation where you can have a different MP on your iPhone than you do on your Desktop if you change your Master Password on your desk top your "old" Master Password on your phone will continue to work on your phone until you use the new one.

But that isn't a behavior we want people to rely on. It is a side-effect of the password change and data synchronization mechanism.

When you use the "new" Master Password on your phone, 1Password will not be able to decrypt the local SQLite data with it. When that decryption fails, it will try to decrypt the 1Password.agilekeychain data from Dropbox with the password you entered. That will succeed in this case. So it decrypts the key from there. It still has the new Master Password that you entered along with an actual decryption key (it's still a bit more indirect then I'm describing it) and so now does the password change on the SQLite file.

This, by the way, is another reason for the indirect relationship between Master Password and your data encryption. If we did it in the "least astonishing" way, a Master Password change on one system would mean that all of the data would need to changed is retransmitted. My 1Password data is 15 Megabytes. That is a lot of data to transfer just because I change my Master Password. Under our system, only the encryptionKeys.js file needs to be modified and transfered with a Master Password change.

So there you go. We really do have good reasons for advising people to pick a good Master Password and keep it for life. Understanding why requires a long look at the internals of how things work (end even then I actually skipped some steps and took plenty of shortcuts).

Don't feel obliged to digest this all. This has been extremely useful for me to write up, even if you aren't interested in quite the level of detail that I've provided.

Cheers,

-j

–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com

I love that you are interested in this stuff, @leesweet. I love this stuff, too.

But we do try to make 1Password work for people who don't want to study how things work under-the-hood. That is, if people need to be security experts to use a security product, then the people in most need to help are missing out.

Cheers,

-j

–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com

Great questions, @mrwally.

Answer: It depends.

One of the big differences between an authentication password and an encryption password is that when you change an authentication password you can no longer get in with the old password. When you change an encryption password, however, old copies of the data can still be gotten at with old versions of the password. There is no fundamental difference between the Cloud Keychain Format and the Agile Keychain Format in this respect, so the situation is just as messy.

Using encryption instead of authentication has some tremendous security benefits. But the possibly counter-intuitive consequences of changing a password is not one of them. So we are left with just trying to get people to pick good Master Passwords, treat it well, and stick with it for life. It's a rule of thumb, with plenty of exceptions and special cases. But at least readers of this discussion now know why just have some vague mumblings encouraging the write behavior. The details turn out to have lots of twists and turns when you look at things.

Cheers,

-j

–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com

Hi Kevin,

Just to be clear, the only way the old keys can still decrypt the 1Password data if you enter the old master password first but yes, you are correct on both counts assuming that you're talking about removing the encryption key files and not the backups itself directly. You don't have to remove the whole zip file, just the keys inside the backup zip file.

As for backup locations, yes, that's the only location we would ever use for the backups for the Mac App Store version of 1Password. The 3.8.x version from our website would by default use ~Library/Application Support/1Password/Backups. I said by default because users can change that via 1Password's Preferences.

I may have missed it, but somehow I think we have neglected to mention our blog post "Toward Better Master Passwords" in this thread. Be sure to give it a read. Don't miss the additional links at the end of the post. I have a feeling you will find them interesting as well. :)