This is a staging forum for AgileBits, not an official support forum. Visit http://discussions.agilebits.com instead.

Security: Master Password Change and Dropbox History

Hello,



I have a security question regarding changing the master password with a 1password keychain that is synced via dropbox as follows:



Imagine that I had the impression my master password could be compromised, for example I suspect someone did look over my shoulder when I typed it. Or I just want to rotate the password anyway to secure my keychain better. So I change the master password.



Now what happens with the keychain items stored in the dropbox? These will be updated, of course. But AFAIK [b]dropbox keeps a history of changes[/b]. Which means that the items encrypted with the possibly compromised old password could still survive as a "previous version", and could be decrypted using the old password [b]long after the master password was changed in 1password[/b].



I haven't found a clue in the docs and the forum if 1password does something to prevent dropbox keeping a history for the agilekeychain items. From reading in the dropbox forum I suspect that dropbox does not offer a way to do that, neither in the web interface (e.g.: http://forums.dropbox.com/topic.php?id=22106) nor in the API. Which would essentially mean that there's no way to reliably get rid of old-password encrypted keychain items once 1password is connected to dropbox.



Fortunately, I'm not in the situation I describe, but it's something I think should be considered before.



Anyone who can shed some more light on that?

Comments

  • jpgoldberg
    jpgoldberg Agile Customer Care
    edited June 2011
    Hi luz,



    Welcome to the forums!



    You are absolutely correct, and while this has been discussed in the forums a number of times, I haven't had the chance to add this to our documentation yet.



    1Password is like PGP/GPG or SSH in this regard. Your master password protects a secret key that never actually changes. Thus [i]old[/i] copies of your key files (1password.keys, .1password.keys and encryptionKeys.js ) will remain protected only by your [i]old[/i] master password. Because your more recent data are encrypted with the same decryption key, then even those can be gotten at by cracking an old master password.



    The over all solution that we recommend is that people pick a good master password to begin with and then never change it. But of course there are many cases - you point out a few - where people do need to change their master passwords.



    If you are in a position where you need to be concerned about old copies, there are a couple of things you can do. One of these was mentioned recently.



    To delete files from Dropbox backups, see their guide on this here:



    https://www.dropbox.com/help/40



    That process will remove the file and all of the previous versions from Drobpox. Also be aware that 1Password makes backups of your data on your computer. See Preferences > Backups in the 1Password application to see where those are kept.



    If you want to force everything to be re-encrypted with a new key, here is a way of doing this.



    In 1Password on the Mac you can export all your 1Password data to a 1Password Interchange File (1pif). Note that the 1pif is [b]not[/b] encrypted; so treat it very carefully. Then move your old data aside and create a fresh 1Password data file (which 1Password will prompt about if it doesn't find a data file where it expects one). That new, empty, data file will have a new random key encrypted with your (new) master password. Then import from the 1pif file. All the data will now be encrypted with the new random key.



    Note that import from 1pif in 1Password for Windows is not fully complete yet. Also be sure that your import works and that you have everything you need before wiping your old 1Password data. On the Mac you can securely erase the 1pif using Secure Empty Trash or srm from the command line.



    I hope that this helps. The bits and pieces of all of this are scattered about our docs and in the forums, but I will try to gather this all together for a proper document.



    Cheers,



    -j
  • Hi Jeffrey,



    thanks a lot for the detailed and open explanation (which I saw not before today, unfortunately the forum notification email was eaten by my spam filter).



    Understanding that a cracked old master password also means all future modifications and additions are compromised is important, but it's something extremely counter-intuitive for average users to expect and realize special measures need to be taken against it.



    I'd therefore suggest that "change master password" should do a complete re-encryption of all current items with a new random key, even if it means touching all files. Of course, the entire past of the keychain (copied and backed up versions) will inevitably be vulnerable, but nothing added or changed beyond the point in time when the master password is changed.



    The question and your answer might have gained some importance for people with weak passwords on their agilekeychain due to yesterday's dropbox security incident <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_sadsmile.png' class='bbc_emoticon' alt=':-(' />



    Lukas
  • khad
    khad Social Choreographer
    Lukas,



    Thank you for following up on this. (Sorry that the forum notification was captured by robots!)



    [quote]I'd therefore suggest that "change master password" should do a complete re-encryption of all current items with a new random key, even if it means touching all files.[/quote]

    This is definitely on our radar. I can't offer any more details on this at the moment, but I think it is a great idea.



    [quote]Of course, the entire past of the keychain (copied and backed up versions) will inevitably be vulnerable, but nothing added or changed beyond the point in time when the master password is changed.[/quote]

    This is true, and I am not sure that we can do anything about this. Since the cases in which this becomes important are so rare, it is best to allow users to handle this on their own. There is not a way for 1Password to access their backup files stored on external drives or who-knows-where-else anyway. We would never want to. Your data is your data. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



    [quote]The question and your answer might have gained some importance for people with weak passwords on their agilekeychain due to yesterday's dropbox security incident[/quote]

    Unless someone accessed your Dropbox account [b]and[/b] cracked your 1Password master password ([url="http://forum.agile.ws/index.php?/topic/3605-feature-request-keyfile-support/page__view__findpost__p__29371"]very, very, [i]very[/i] unlikely[/url]) there is no need to change anything. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />



    You can read more about [i]that[/i] topic in the [url="http://forum.agile.ws/index.php?/topic/5199-security-cloud-syncing/"]cloud syncing security[/url] thread, if you are interested.



    It is always good to be thinking about these things.
  • amgems
    amgems Junior Member
    I just did the export/re-import.

    Only problem (so far) is the modification time of all items has been reset to the current day/time.



    It also offered to put everything into a folder, and it is not obvious that you can ignore that and it will restore the prior folders.



    I had been using the same password since 2008, and it is not good practice to recommend 'choose a good password and never change it'.



    I suggest making this easier, without the export/import, and preserving my data info.



    won't worry about it for a while, though.
  • jpgoldberg
    jpgoldberg Agile Customer Care
    Hi



    [quote name='amgems' timestamp='1312013477' post='35108']

    I just did the export/re-import.

    Only problem (so far) is the modification time of all items has been reset to the current day/time.[/quote]

    Ah. Sorry I didn't warn you about that. Yes the modify time actually comes from the modify time on the file itself instead of from information within the file.



    [quote]

    I had been using the same password since 2008, and it is not good practice to recommend 'choose a good password and never change it'.[/quote]

    Indeed. What seemed like a good master password in 2008 may not pass muster today.



    [quote]

    I suggest making this easier, without the export/import, and preserving my data info.



    won't worry about it for a while, though.

    [/quote]

    Hopefully the next time you need to change your master password we will have a smoother process. Though neither SSH or PGP/GnuPG seem to have come up with anything better when faced with an analogous problem. I'm not sure how all of this will play out with our upcoming changes to our data format.



    Again, keep in mind that the simple process of changing the master password (while keeping the original encryption key) may be sufficient. You can remove all previous versions of files on Dropbox.



    Cheers,



    -j
  • The new Cloud Keychain solves this?

  • khad
    khad Social Choreographer

    I don't think there is anything to "solve" since it is an intentional part of the design of the data format, so I don't believe the Cloud Keychain changes anything in this regard (just like a new version of GPG won't change the fundamental model it is based on). However, I'll double-check with Jeff to confirm.

  • jpgoldberg
    jpgoldberg Agile Customer Care

    Hi all,

    The new Cloud Keychain Format has the same properties as the Agile Keychain Format in this respect. So the answer is "no". We did not come up with a way to re-encrypt all the data with fresh keys during a Master Password change.

    I hope you will forgive me for repeating that our design "solves" a number of security problems that might not be obvious. Here are a few:

    1. There is a limited amount of data that should be encrypted under the same key.

      Now 1Password databases aren't getting that big (yet), when you have a structure that allows people to add an unlimited amount of data, you need to use multiple keys.

    2. To get the full strength of 128 bit (or 256 bit) keys, those keys should be generated completely at random.

    3. To have a system where only the minimum amount of data necessary is decrypted at any single time requires separate keys for each item.

    4. Changing the Master Password should not be a process that takes many minutes during which a power failure or computer crash might leave data unusable.

    But this does leave the problem that a Master Password change does not have the effect that it might seem.

    For me the real problem is how to do have something that is simple and straightforward to use, without people needing to study the details, that works in a way so that it makes it easy for people to behave securely and hard to behave insecurely. This really is the overriding goal of what we do here. As a consequence, 1Password presents itself to people as much much simpler than it really is. In 99.44% of that cases that is a very good thing. But there are still those small number of cases where what is presented to people by 1Password can be misleading in an way that can lead them astray.

    And there is another problem. The problem is that sometimes we do have to make tradeoffs of defending against one kind of threat versus another. Although I acknowledge the downside of the choice that we've made here, it was not a tough decision. The security benefits of our design choice are overwhelming.

    I'd love to have a system that did everything, including conforming to intuitions about changing Master Passwords. We'll keep exploring ideas, but we require that any such system do more good than harm.

    Cheers,

    -j

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