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

leesweet

I've read all (I think) the blog posts, and even tested my password on the site that Joe Kissell mentioned in his book (http://dl.dropbox.com/u/209/zxcvbn/test/index.html ). (See the blog post about the book, I'm about a third the way through, and it's definitely worth $8!: http://blog.agilebits.com/2013/03/14/joe-kissell-wants-to-help-you-take-control-of-your-passwords/ ) and.... It says my Master Password can be cracked in 54 years. Well, if I add one more character to it, it jumps to 'centuries'. Cool! [Yes, I know these are estimates, etc. Still, it's useful to show the entropy and crackability of your MP.]

Here's my point: We've seen that several blog posts have said it's not as easy as just changing your MP. There appear to be some places that the old keys hang around. So, for those of us that may want to change their MP one time or so, can we get the actually perfect agilebits-blessed procedure for doing it the right way and being sure that nothing is left of the old MP and its attributes? :)

Thanks!

jpgoldberg

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

leesweet

Jeffrey, thanks much! I was wondering how 'safe' testing it there was. And what the assumptions were. For others, the output of that tool tell you what 'kind' of attack is/would be used to break each/that part of your password and how long that part would take to break. So, you could easily duplicate your password in pieces and not use the identical one. Or make another one, as he says, and use that, when he tells us how exactly to change it and get all the pieces correct. :)

Looking forward to part 2 about how to actually change the MP completely and correctly!

jpgoldberg

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

leesweet

Not a problem... we know you have real work to do! :)

frikfrak

I too would like to know the right way to change my MP completely and correctly, as I foolishly shared it with someone and now wish I hadn't.

frikfrak

Jeffrey, will the following work?

[1] Export my entire database to a 1Password Interchange file
[2] Create a new keychain file, with a new password
[3] Import the file created in #1 into new database created in #2
[4] Securely delete the 1P Interchange file as well as previous backups/copies of original keychain file

(I'm on the MAS version.)

pomme4moi

I also am looking forward to the response to this question - to change the master password and eliminate all copies of the old Agilekeychain wherever it might reside: PC, Mac, Dropbox, iCloud, iTunes, iOS, etc ...

frikfrak

Bump

frikfrak

Does anyone know the answer?

khad

@frikfrak, the method you outline above should do the trick. My apologies for the extremely delayed reply. I thought Jeff was responding to posts in this thread, so I had left it to him. I'm happy to help if you have any other questions. :)

frikfrak

Thanks Khad!

leesweet

So, is that the best answer? I thought Jeff was going to give a complete answer along with some reasons for the steps. I was originally wondering exactly why just changing the password isn't sufficient and what was left behind. I'm leery of exporting hundreds of items and starting over.... :)

khad

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.

leesweet

Well, lol, as I said, I'd like to know (which is why I started this thread weeks ago...) why exactly we can't just change our MP. What is left behind and how bad is it to do that. So far we've gotten some blog posts saying some stuff is there but no documentation. I think it would be a priority for AB to tell us the preferred method to change the MP in a correct complete manner.

Documentation of a lot of things seems to be something that needs to be more of a priority for AB, as many links go to either the previous version or (as in this case) there is no doc. Is this on the list of things for the company to address?

leesweet

And, I have to add, if you are super busy, don't promise to do things you can't do. Under promise, over deliver, not the other way around! :)

jpgoldberg

Yeah. I over-promised here. Partially it's because I plan to write up a full and proper article on the subject, and partially because the actual answer to your question isn't a good answer.

We really don't have a nice way to handle this kind of password change with the security properties you (very reasonably) want. It's because I don't like recommending to people that they remove backups.

So here goes with a less than perfect answer.

1. Change your Master Password.
2. Make sure that you really know your new Master Password and will not forget it.
3. Wait a week or so to really make sure that you know your new Master Password and that everything is working correctly.
4. Remove the following files from backups from prior to your change of your Master Password. encryptionKeys.js, 1password.keys, and .1password.keys from 1Password.agilekeychain/data/default. Do not remove the current versions of those file. (Note that you might not have all three of those files).
5. Places to remove those older versions from include Time Machine and Dropbox. Again. Do not remove current versions.
6. Check to see that 1Password is still working and that you haven't removed the current key files.
7. Those files will also exist in the backups that 1Password makes. You can delete those pre-password change backups (or move them to some more secure location such as a DVD).

The location of the backups that 1Password makes depends on which version of 1Password you are using. For 1Password 3.9 it is

~/Library/Containers/com.agilebits.onepassword-osx-helper/Data/Library/Application Support/1Password/Backups

For 1Password 3.8, it is ~/Library/Application Support/1Password/Backups and I'll have to double check for Windows.

I would recommend that before you try deleting the specific files (encryptionKeys.js, etc) from Dropbox backups or Time Machine that you make local copies of your new ones (with your new master password) someplace so that you won't lose those files if something goes wrong when you try to remove the backups. It seems very possible that attempting to remove all of the old backups could inadvertently lead to removing the current files.

As you can see from the actual procedures I listed, why I don't actually want to "recommend" this. It's onerous and there are places where things can go wrong.

So unless you really think that your previous password was poor and that someone might get at the old files, I'm asking you to think twice (or more) before doing this.

There is another approach as well, which involves exporting to unecrypted 1PIF, removing your 1Password.agilekeychain, starting off with a new one, and then importing from the 1PIF. (And then of course, securely delete the 1PIF).

One of the reasons I've not been particularly eager to answer this question is that I still don't know which approach I dislike the least.

So there you have it. We really don't have a good way of doing this (yet), and so advice on how to do it is going to be messy. But I hope that it gives you the information you need. If there are parts that are unclear, please do ask. I'll really try to be better about responding.

Cheers,

-j

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

leesweet

Jeff, thanks. And wow. Maybe I'll leave well enough alone with 54 years (from the test mentioned in post 1) of strength. Lol.

I guess the next question is: Should there be an easy way to change the MP and it fixes all this stuff? In 1P5? 1P6? :) I can't see the average person doing this. I can see them just changing it, since it's on the menu. And then what are they in for? Vulnerabilities or what? What's the downside of just changing it, which was more my original question, since we were told not to 'just' change it.

I appreciate the step-by-step for people that set things up with a really bad MP, though!

leesweet

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)? That was one of the items I was waiting to see you spell out, since it changed with the 1P4 introduction. I assume that 'now' the one (new) MP is synced everywhere to all devices, but I keep seeing these threads about the 'old one still works'. It's a bit confusing. :)

jpgoldberg

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

leesweet

Jeff, I'm extremely interesting in the level of detail (since I deal with users' security issues all the time, and people's security theater idiocy (like enforcing numbers/symbols, etc.). As we know, that's not too useful. But I did want to see where the 'leftovers' were the issue so we couldn't 'just' change the MP, so we can clean up if we want to have the current MP be the one with the only traces around.

Thanks much for the extreme detail, and I do appreciate your taking the time out of your schedule to do it!

jpgoldberg

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

mrwally

Great thread (like many others on this forum ;)...

My question is - Does any of this conversation apply to those of us who only use 1password4 for iOS? I have 1password4 loaded on my iPhone and iPad and use iCloud to sync. If I want to change my master password and make sure there aren't any "remnants" remaining of the old master password, what's the process for that?
Does this conversation quickly spiral into "it depends" on if/how I've been backing up my 1Password data? What about old "versions" of the data sitting on iCloud?

jpgoldberg

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

netnothing

Really interesting conversation here. So is the bottom line on Master Password changes:

1) All the in-use encryption keys are updated correctly
2) We need to remove all the backups because they contain the old keys because those old keys can still decrypt all 1Password data

So are backups only stored in the ~/Library/Containers/com.agilebits.onepassword-osx-helper/Data/Library/Application Support/1Password/Backups path? Or are there other files in the Containers folders for 1Password?

-Kevin

MikeT

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.

misterdna

Thanks for all these details, they are very helpful.

BTW, to anyone who thinks they're using a very strong (such as: 54 years to crack) password, note that many sites that evaluate password strength are probably not factoring in that hackers have figured out a lot of tricks beyond brute force attacks. ArsTechnica has a new article that made me nervous about the strength of some of my passwords.

http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

khad

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. :)