Is the "random decryption key" ever changed?

Chris Leishman

I've read in the description of the Agile keychain that the master password is only used to encrypt a "random decryption key":



http://help.agile.ws/1Password/agile_keychain_design.html#hierarchy_of_encryption_keys



I'm curious however: if these random decryption keys are not changed when the master password changes, when are they? Are they ever?

khad

Welcome to the forums, Chris!



Your master password works in conjunction with the keys. They are regenerated when your master password is changed.



For further information, see the [url="http://en.wikipedia.org/wiki/Advanced_Encryption_Standard"]Advanced Encryption Standard[/url] article on Wikipedia or listen to Steve Gibson's excellent Security Now podcast episode "[url="http://www.grc.com/securitynow.htm#125"]Symmetric Ciphers[/url]."



I hope that helps. Cheers! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />

Chris Leishman

[quote name='khad' timestamp='1291930551' post='17265']

They are regenerated when your master password is changed.

[/quote]



Hi Khad,



The documentation clearly states that changing the master password does not re-encrypt the keychain, thus the keys cannot be regenerated when the password is changed:



[quote]

In order to allow you to change your password without needing to decrypt and re-encrypt the entire Agile keychain, an encryption key hierarchy was created. Instead of encrypting data with the password directly, a random password of 1024 bytes is used.

-- http://help.agile.ws/1Password/agile_keychain_design.html#hierarchy_of_encryption_keys

[/quote]



So the question remains: when, if ever, are they changed?

jpgoldberg

[quote name='Chris Leishman' timestamp='1291973897' post='17296']

The documentation clearly states that changing the master password does not re-encrypt the keychain, thus the keys cannot be regenerated when the password is changed[/quote]



You are exactly correct, Chris. That was extremely well spotted. It is a great observation and a great question. I'll have to drag Khad round behind to woodshed for a walloping that'll properly learn 'im the protocols.



Because the key is never, ever stored unencrypted, the encrypted version of it gets changed when you change your master password. That is probably what Khad was referring to.



[quote]

So the question remains: when, if ever, are they changed?

[/quote]



Under normal operation they are never changed. Though, of course, the encrypted key does get changed when you change your master password.



If you would like to force them to be changed, you should export your data to a 1pif ([i]File > Export All > 1Password Interchange File ...[/i])



After that you should ditch your old data and create a new 1Password data base. We describe how to start over with a new keychain here:



http://help.agile.ws/1Password3/create_new_keychain.html



Then you can import your data from the 1pif you created earlier.



One very important note is that your data is the 1pif file is completely [i]unencrypted[/i]; so you need to be very careful about where that is stored and that you remove it securely.



Let me also address what may be your next question. "What is the security benefit of changing your master password?"



The answer to this is that there is little benefit to changing a master password unless you have used that same master password elsewhere or it is weak. A 1Password master password should be strong and unique from the beginning and then never needs changing.



This same sort of thing applies to other highly secured keys that are used in other high security systems. For example, if you use PGP/GPG for email or SSH public key authentication, your password for those is protecting a private key that never changes. When you change your passwords, you are only changing how your non-changing key can be accessed.



I hope this helps answer the question.



Cheers,



-j

Chris Leishman

Thanks jp.



You correctly guessed where I was going with this. In this case, changing your master password only protects against the situation where the key has been compromised but nobody had access to your encrypted keychain data.



My concern here is that this situation is a lot less likely that the situation where both are obtained. Unfortunately I think it would be a little too easy for someone to believe that the correct mitigation in this case is to do the following:



1. Change the master password

2. Change the password for all the logins / accounts, as their passwords may now be known.



The problem with this is that if the attacker still has access to the encrypted keychain, they can still obtain all the updated passwords (and new logins/accounts) simply by dropping in the old version of encryptionKeys.js (or whatever it is). This would essentially reset the master password back to the compromised one, as it would still yield the correct generated keys.



It might be helpful if this was made clear and an option to reset all the keys was provided. Maybe a "I think my keychain was compromised" wizard or something.



cheers,

chris

Chris Leishman

PS. As an alternative, if you are willing to update the keychain format, then this scenario can be protected against by having a separate generated key for every keychain item, which is changed whenever the item is updated. You still get the desired performance benefit when changing the master password, whilst also preventing the stated attack.

dteare

[quote name='Chris Leishman' timestamp='1292428539' post='17647']The problem with this is that if the attacker still has access to the encrypted keychain, they can still obtain all the updated passwords (and new logins/accounts) simply by dropping in the old version of encryptionKeys.js (or whatever it is).

[/quote]



This is a good point Chris. If you think your 1Password data file has been stolen, the Master Password cracked on the original encryption keys, and you believe that the thief still has access to all your newly created files, then changing the Master Password would not offer any security advantages.



With that said, why does this thief still have access to your files? I guess you could be considering some undetected malware, but in this hypothetical scenario, one could easily imagine the malware could have a keylogger that grabs your Master Password when you type it.

jpgoldberg

[quote name='Chris Leishman' timestamp='1292428539' post='17647']

The problem with this is that if the attacker still has access to the encrypted keychain, they can still obtain all the updated passwords (and new logins/accounts) simply by dropping in the old version of encryptionKeys.js (or whatever it is). This would essentially reset the master password back to the compromised one, as it would still yield the correct generated keys.[/quote]



This is very well spotted, Chris. This is a known risk with everything that uses a password encrypted key mechanism. SSH public key authentication, S/MIME certificates, PGP/GPG public key cryptography all share this problem of "once broken, always broken". For example, SSH private key components never change, but people keep them encrypted with a password. Once someone gets at the actual private key, then changing the password that is used to encrypt it does little good, and as the public key portion gets used in more place, that expands what the attacker can get into.



[quote]

It might be helpful if this was made clear and an option to reset all the keys was provided. Maybe a "I think my keychain was compromised" wizard or something.[/quote]



I think that is a very good idea. The issue here is a user education one. As you've learned from reading our documents, the metaphor of a locking and unlocking all of your data doesn't actually reflect the subtlety of what is actually happening. Likewise, changing your master password in 1Password is a very different thing that changing a password on a particular site.



I've been musing about how to approach this issue for a while. Indeed, from even before I started working for Agile Web Solutions. It's bothered me about SSH, PGP/GPG and other tools for a while. The image for most users of how things work differs greatly from how things actually work. These differences actually improve security over what a non-expert might think is going on. In most cases there is little problem with the discrepancy. But in some edge cases, as in the scenario you constructed, the simplified view that is presented to the user can promote the less secure behavior.



Here are some things I've been thinking about. I'm not happy with any of them for a variety of reasons.



[list]



[*] One of the things I've been meaning to do is write up a Knowledge Base article on "When to (not) change your master password." But we can't rely on everyone digging into the knowledge base before changing the master password.



[*] We could complicate the change password user interface in the application so that it pops up a long warning that nobody will want to read.



[*] We could complicate the actual change master password mechanism so that a new random key is generated and everything gets decrypted and then re-encrypted with the new key. This would make changing a master password a very slow operation.



[/list]



Each of these have to be evaluated along many dimensions. Our core goal with 1Password is to make it [i]simple[/i] for users to do the right thing. We want to be open about our design and protocols for the curious (and for the expert community), but we don't want to require that all of our users understand the subtleties of encryption protocols.



Cheers,



-j

Chris Leishman

[quote name='dteare' timestamp='1292431167' post='17657']

With that said, why does this thief still have access to your files? I guess you could be considering some undetected malware, but in this hypothetical scenario, one could easily imagine the malware could have a keylogger that grabs your Master Password when you type it.

[/quote]



Honestly, I don't think this attack vector I'm describing is very likely.



Regarding data compromise, I can only think of these scenarios:



(i) Loss of physical medium (entire machine or a backup)

(ii) Access by attacker to the physical machine where loss has not occurred

(iii) Access to the remote storage containing the data files (e.g. NAS, dropbox, etc)

(iv) Ongoing access to backup devices or storage medium



The most common will obviously be (i), and this situation is adequately protected against by strong encryption. In this scenario, concurrent compromise of the passphrase is unlikely: there is no way to obtain the passphrase directly and brute forcing a strong passphrase is infeasible. If compromise does occur, damage is limited to only the current set of content.



The next most probable is (ii) which, arguably, cannot be protected against at all given the attacker has the opportunity to install keylogging software, or similar, to obtain the passphrase in addition to the data files.



The last two, (iii) and (iv), are less probable and are protected against by strong encryption. Again concurrent compromise of the passphrase is highly unlikely, however in this case it would result in ongoing damage unless the keychain is rebuilt as described. This is the vector I was interested in.



So I agree, it's a highly unlikely scenario. It's just an interesting scenario to consider.

dteare

[quote name='Chris Leishman' timestamp='1292501219' post='17701']

So I agree, it's a highly unlikely scenario. It's just an interesting scenario to consider.

[/quote]



Indeed it is very interesting! I really enjoyed reading this thread and thinking things through with you.



What else should we discuss? Threads like these always get Jeff and I in a good mood <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' /> If you haven't already, you should listen to Jeff's recent discussion on [url=http://yourmaclifeshow.com/inthenews/2010/12/15/yml-interview-1password]Your Mac Life[/url] about the Gawker security breech. You can hear in Jeff's voice how much he loves this stuff <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/biggrin.gif' class='bbc_emoticon' alt=':D' />

jpgoldberg

[quote name='dteare' timestamp='1292533388' post='17739']

What else should we discuss? Threads like these always get Jeff and I in a good mood <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

[/quote]



How true! We think about these things all of the time. We want 1Password to "just work" for everyone whether they dig in to its operations or not, but we love to get to talk about the kinds of more subtle, under-the-hood, design choices.



What's important to understand in this case is that any trade off was between security and security. Our design allows us to use the password strengthening techniques I love to boast about. This is what really protects you if your data are stolen. It also allows us to keep the minimum amount of material decrypted at any one time, which is important in a number of ways.



[quote]

If you haven't already, you should listen to Jeff's recent discussion on [url=http://yourmaclifeshow.com/inthenews/2010/12/15/yml-interview-1password]Your Mac Life[/url] about the Gawker security breech. You can hear in Jeff's voice how much he loves this stuff <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/biggrin.gif' class='bbc_emoticon' alt=':D' />

[/quote]



Thanks, Dave. And you have given me an opportunity to repeat a point that makes 1Password different from the kind of encrypted data that was stolen in the Gawker breach. Gawker's data file (standard Unix shadow password file) was not designed to withstand concerted attack if it fell into the wrong hands. (That's not entirely true, it was designed to withstand the kinds of attacks possible 30 years ago.) Instead it was in a highly protected part of the system. This is why once the data were released it was possible crack thousands of those password per hour with software you can download and run on your desktop.



1Password's data format was designed from the beginning to withstand such attack. What is crucial is not so much the algorithms (DES vs AES) but the protocols. I.e. how the encryption is used to get from entered password to encrypted password.



Cheers,



-j

DebCC

[quote]With that said, why does this thief still have access to your files? I guess you could be considering some undetected malware, but in this hypothetical scenario, one could easily imagine the malware could have a keylogger that grabs your Master Password when you type it.

[/quote]





Just playing the devil's advocate here, but how about when it isn't technically a thief at all, but a former spouse, partner or the like? Where you once shared everything, including financial data and money, and suddenly there is now animosity and distrust? That is when I could see wanting to have my master password changed and to have someone who had former access to my info absolutely locked out.



I'm thinking there should be a quick way to change the master password and probably the individual financial sites passwords, as well, and have them be immediately secure from anyone who had former access. Yes, it is locking the hen house door after letting the fox in, but people do it all the time.



Edited to add, I am in love with 1Password and am turning all my friends and family onto it!

khad

Thanks for the kind words, DebCC, and welcome to the forums! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



I completely understand your point, and I think it may be a very common real-world example of when you would want to change the random decryption keys, or perhaps Jeff can set me straight. Maybe I am missing something, but I don't think most people would mind if a master password change took a long time if it meant regenerating random encryption keys and re-encrypting all your data. How often do we change our master passwords anyway? Other than situations similar to what you describe, there really isn't any reason to [i]ever[/i] change your master password. If you are the only person who knows it and it is a unique and strong, you can use the same password forever.



My vote is for a full re-encryption in the event of a master password change. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />

Harry Warrior

[quote name='jpgoldberg' timestamp='1292484366' post='17694']

We could complicate the actual change master password mechanism so that a new random key is generated and everything gets decrypted and then re-encrypted with the new key. This would make changing a master password a very slow operation.

[/quote]



With the multi-core machines that people use these days, I would assume this 'slow' is something like 10 seconds. I personally don't mind waiting 10 minutes for something I would do once in a year. My 2 cents.

RobYoder

[size="2"][quote name='Harry Warrior' timestamp='1293492726' post='18164']With the multi-core machines that people use these days, I would assume this 'slow' is something like 10 seconds. I personally don't mind waiting 10 minutes for something I would do once in a year. My 2 cents.[/quote] [/size]



[size="2"]Good point, Harry. I'll see what the developers say.[/size]



[size="2"]Edit: Actually, if this is a once-a-year thing for you, the best idea is to follow Jeff's advice above:[/size]



[size="2"][quote name='Jeff'][/size][color="#1C2837"][size="2"]If you would like to force them to be changed, you should export your data to a 1pif (File > Export All > 1Password Interchange File ...)

[/size] [/color]

[color="#1C2837"][size="2"]After that you should ditch your old data and create a new 1Password data base. We describe how to start over with a new keychain here:[/size]



[url="http://help.agile.ws/1Password3/create_new_keychain.html"]http://help.agile.ws...w_keychain.html[/url]



[size="2"]Then you can import your data from the 1pif you created earlier.[/quote][/size][/color]

DebCC

[quote]Maybe I am missing something, but I don't think most people would mind if a master password change took a long time if it meant regenerating random encryption keys and re-encrypting all your data. How often do we change our master passwords anyway? Other than situations similar to what you describe, there really isn't any reason to [i]ever[/i] change your master password. If you are the only person who knows it and it is a unique and strong, you can use the same password forever.



My vote is for a full re-encryption in the event of a master password change. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />

[/quote]



It's not the time, it's the ease that concerns me, as well as the security. Most of us in the real world are not computer savvy. Heck, I'm finding myself struggling with the steps to change the master password and have it re-encrypted myself, right now.



Yes, I agree, a full re-encryption when changing the master password is needed. And it needs to be simple to do.



Thanks for responding!

khad

DebCC, I am really pushing for this (for what it's worth). I would love to see this in a future release. Thanks for letting us know it would be useful to you as well!

brenty

[quote name='khad' timestamp='1293143204' post='18033']

I completely understand your point, and I think it may be a very common real-world example of when you would want to change the random decryption keys, or perhaps Jeff can set me straight. Maybe I am missing something, but I don't think most people would mind if a master password change took a long time if it meant regenerating random encryption keys and re-encrypting all your data. How often do we change our master passwords anyway? Other than situations similar to what you describe, there really isn't any reason to [i]ever[/i] change your master password. If you are the only person who knows it and it is a unique and strong, you can use the same password forever.



My vote is for a full re-encryption in the event of a master password change. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />

[/quote]



I second that! I think even a simple dialogue box that briefly explains this process: "Changing your Master Password will result in the contents of the Keychain being fully re-encrypted. This may take a few minutes or longer depending on your machine's performance." Perhaps a checkbox could be available to opt out of the full re-keying, but I wonder how many people are really so desperately pressed for time that they would choose to forego the more secure option.



While I'd love to see this, one concern would be a crash or power failure before this process is complete. Keychain backup will likely mitigate the risk (and I know you guys are on top of these things,) but it's something to consider.





[quote name='jpgoldberg' timestamp='1292608800' post='17783']

How true! We think about these things all of the time. We want 1Password to "just work" for everyone whether they dig in to its operations or not, but we love to get to talk about the kinds of more subtle, under-the-hood, design choices.

[/quote]



While it must feel great to be solving those sorts of problems behind the scenes, I'm sure it feels even better to get to discuss some of the things that go unheralded in most cases. But the fact that these things are mostly invisible to the enduser is a credit to the hard work of everyone at Agile. Why not include a small (i)nfo button in certain parts of the UI with links to relevant documentation for those of us who have an appetite for knowledge? And every time you click, Jeff gets a cookie! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/laugh.gif' class='bbc_emoticon' alt=':lol:' />

jpgoldberg

[quote name='brenty' timestamp='1293590531' post='18220']

While it must feel great to be solving those sorts of problems behind the scenes, I'm sure it feels even better to get to discuss some of the things that go unheralded in most cases.[/quote]

You betcha! I love it.



[quote]

But the fact that these things are mostly invisible to the enduser is a credit to the hard work of everyone at Agile.[/quote]

Thanks so much for recognizing that. We want 1Password to be secure password management for everybody. This includes people who might actually be put off by too much technical discussion.



[quote]Why not include a small (i)nfo button in certain parts of the UI with links to relevant documentation for those of us who have an appetite for knowledge? And every time you click, Jeff gets a cookie! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/laugh.gif' class='bbc_emoticon' alt=':lol:' />

[/quote]

I love cookies!



But are very careful about not cluttering the user interface. You will see a "?" help button on a number of the preference panes. Still those are designed to take people to the help that most people need at the moment with understanding the options on the particular preference pane. So although I really do love cookies, I think that we probably have made the right choice in letting the curious ask on these forums, write into support, or explore the knowledge base in our documentation on their own.



(Still, I think I'm going to grab some cookies now.)



Cheers,



-j