Master Password / USB Sync / Two Factor

Three questions pls:

  1. I read in the 1Password User Guide that master passwords should rarely, if ever, be changed. This is contrary to general password advice, which suggests that passwords should be changed periodically. I do not understand why the 1Password master password should not be changed periodically. Can someone elaborate? Does it create a problem if a user changes his/her master password periodically?

  2. I also read about USB Sync on the 1Password website. I understand USB Sync is still in beta, but I am not sure I understand what it is. Does the user connect their iOS device via USB cable to their Mac, then somehow sync / update to the 1Password.agilekeychain file on the Mac?

  3. I also read the rationale on the 1Password website for not introducing full two-factor authentication in 1Password. I understand the rationale, but I would still suggest that two-factor authentication is a feature that many customers would welcome, both for practical and peace-of-mind benefits. Incorporating a standard second-factor tool, such as Google Authenticator, into 1Password would be great.

Thanks

Comments

  • khad
    khad
    1Password Alumni

    Good questions, @pomme4moi!

    1. Advice to change passwords regularly presupposes two things: (1) that you are reusing passwords and (2) that the password being changed is an authentication password. Your master password for 1Password should never be used anywhere else, and it is an encryption password not an authentication password. I'd encourage you to read Jeff's post about this in a previous thread.

    2. You have correctly stated the exact purpose of the USB sync tool. It allows people who cannot or will not use Dropbox to sync their 1Password data between their Mac and iOS device.

    3. Our existing blog post is useful for understanding the current state of multifactor authentication in 1Password, but it doesn't really address another very important aspect.

    I'd like to highlight the distinction between an authentication password and a decryption password. This ties in with the first answer as well.

    Let me give a simple examples. Suppose you have a file encryption program called FileEncryptionProgram.app. It encrypts a file for you and stores the encrypted file as my-secret-diary.asc.

    Now the developers of FileEncryptionProgram could implement a form of multifactor authentication before the application would even begin to think about decrypting my-secret-diary.asc. That wouldn't be hard to do on the Mac.

    But now imagine what happens if Mallory (an attacker) gets ahold of my-secret-diary.asc. Mallory can take that file off to his secret lair and try to attack the encryption on it. Mallory does not need to launch FileEncryptionProgram at all. Indeed, Mallory would be wise to use his own password guessing program that is built for speed and designed for the format of my-secret-diary.asc.

    Mallory is trying the decrypt the data. Mallory does not need to authenticate with some particular program or service. This is the case with 1Password data as well. Anyone can write a program that decrypts the data if they can get the master password. The data is protected by the encryption and the design of our data format. An attacker doesn't need to (and typically wouldn't) go through the 1Password application itself. In fact, this is exactly what John the Ripper does, and 1Password protects your data in ways which are appropriate to its design (i.e. PBKDF2 key strengthening).

    Classical approaches to MFA won't work for us because unlocking your 1Password data is not about authenticating to some service. So sure we could add an authenticator for using 1Password.app itself, but it wouldn't actually provide any real additional security. It would be just for show.

    Instead we would need a key splitting approach, and it would need to work across platforms. We do have ideas of how we could do this, but it would add complexity everywhere, and to every platform. It couldn't just be an option that you use on one platform but not another. (If it were, it would mean that the data could be decrypted without the second factor.)

    Again, I'm not saying that we can't do it. (We have some good ideas about how we could.) But I am saying that at the moment we are disinclined to do it for the reasons outlined above and in our blog post. Even if it is made an option, we know that there are people who will sign up to every "more secure" option available to them, even if it is the wrong choice. We've joked about presenting people with a quiz about data security before allowing them to enable such an option, and still with a flashing red sign saying "This is a bad idea. Don't enable this."

    Using a second factor in the way that we would have to doesn't just double the chance of getting locked out of your data, it increases those chances dramatically. This is because your 1Password data is backed up in a variety of different ways, with robust checks that it isn't damaged. But your second factor couldn't be backed up and stored with your 1Password data. And indeed, it would typically be stored on some other device (an encrypted USB drive or smartcard). Damage to that would be unrecoverable.

    We should do a blog post on the distinction between authentication and encryption passwords sometime. As mentioned near the beginning of this post, the distinction is relevant to more than just MFA, it is also why you should only change your Master Password if it is weak. A good Master Password should be for life. :)

  • pomme4moi
    pomme4moi
    Community Member

    Thank you for your response. Very clear. Re two-factor authentication, in a future blog perhaps you can comment on how users can best protect themselves from keystroke loggers when typing in their master passwords. Thx

  • khad
    khad
    1Password Alumni

    Thanks for asking this important and, frankly, difficult question.

    Secure Input is available to us in OS X to offer protection against keylogging. Our friends at Smile (makers of TextExpander) have a great explanation of Secure Input:

    Any application can enable Secure Input. With Secure Input enabled, all typing is passed directly to the active application — no other applications can observe your typing. Secure Input is used for entering passwords and other sensitive information. This means that if malicious key-logging software or “spy-ware” somehow gets on your system, it cannot record your passwords. Secure Input is generally enabled when you type into a password field. Some applications also enable Secure Input at other times.

    First, let me clarify that the type of keylogging 1Password protects you from is the type that reads what you are typing into web forms in your web browser, not the type that has control of your entire computer. If you're concerned that someone has access to your computer, keep reading.

    The bad news is that we have to recognize that if someone has control of the computer you are using they can - in principle - get at everything that happens on that computer. Because of this fact, the best thing is to avoid using machines that may be compromised. Since 1Password is available for iPhone, iPod Touch, iPad and Android devices, and it also runs wonderfully on Windows Netbooks and on Macbook Airs, there is a large range of portable devices you can use for accessing your 1Password data.

    However, if you must enter your 1Password master password on a machine that you don't trust — perhaps when using 1PasswordAnywhere — there are things you can do to reduce the chances that it is captured. One trick that I've used is to copy and paste fragments of my master password out of sequence. For example, if my master password were "1nce up-on a midDay Leary", I would try to first find, say, the sequence "ear" on my screen and copy/paste that in first. Then I might type a "y" after it and an "L" before it. Then, maybe from a word like "fence" I would find the "ence" string that I need and then type in the "1" and the space. I would continue this process of copying and pasting fragments and typing some other ones.

    Obviously this is a painful and error prone process. I could do it with just a few fragments and more typing. But mixing it up a bit (particularly putting things in out of sequence) should defeat key stroke loggers that seem to be out there today. Of course, things may change later.

    Another thing to keep in mind is that since some existing keyloggers also take periodic screen shots, you should keep your passwords concealed as much as possible.

    Because of the nature of a compromised machine, even the most sophisticated systems to defeat such loggers would only be stop gap measure. The best defense is to use your own hardware. As long as you are using your own computer and you log into sites using SSL (URLs that begin with https:// as opposed to http://), you will remain safe, even if you are on a network that you can't trust.

    I hope that helps. It is great that you are thinking about these things. Please keep the questions coming. :)

This discussion has been closed.