I've flagged this thread for review by our Chief Defender
Against the Dark Arts, Jeff. He'll be able to give you a more
thorough answer, but please allow me to begin by making a couple of
Note that there's not a single point where I could have avoided
entering my password via the keyboard and do a cut&paste
If keylogging is the major concern, could she not save the MP on
a flash drive (that may be protected with encryption a la Knox) and
copy and paste it from there?
You spell out the case for Multi-factor Authentication very well. Though what is really needed in the case you describe is for the second factor to be a one-time key (or something to that effect behind the scenes). I travel a great deal, and my wife travels even more, so the situation you face is not only something we've thought about, but something that I have direct experience with.
I see that Ben has given you a link to explain why we are reluctant to introduce MFA. Basically we are left in a situation where there is a good case for MFA and a good case against it as well.
I'm sure you have good reasons for her not taking a device of her own, and so the advice of "don't do important stuff on untrusted computers" is not particularly helpful.
One completely unsupported and only superficially tested approach would be to use a SurfEasy device. It isn't free, but it tunnels through untrusted networks, and, more importantly it contains its own version of Firefox on the USB device. It is possible to install the 1Password Firefox extension into the SurfEasy browser. If you first do this on a machine with 1Password running your data will sync (slowly) to the browser extension. It will then be available to you (without syncing) on the SurfEasy USB device.
As I said, this isn't actually supported, and there are a couple of odd steps needed to enable the extension in SurfEasy on Windows. (Disable, but don't remove, extension; restart browser; enable extension; restart browser again). I know that SurfEasy has been planning to introduce a virtual keyboard, but I don't know the current state of things.)
Again this is unsupported. I can't promise it will work for you, but I thought you might like to know about some things that I've been looking at.
4 Posted by Michael Hoffmann on 03 May, 2012 12:24 AM
Thanks for the reply guys.
First, as Jeff is CDADA, he trumps Ben, right?! ;) So, MFA is
coming soon, yay! Right? RIGHT?!
OK, I'll pull out the last trump card: does it, so why can't
you? I'd actually read Ben's pro'n'con post sometime ago when I was
evaluating 1P vs . It didn't really convince me then, but then I
work in the rarefied "you're not paranoid enough" areas of IT
security where I may no longer think like a normal human being.
Yes, using a USB with the keys may be the only way for now,
though you may find this to be a tricky one to explain to a
non-techie person. It's not like I don't have these things lying
around like candy in this house...
Using a USB wIth a secured browser is fine unless the OS itself
has gotten the loggers installed in which case the snooping is
happening right at the KAC level (keyboard and chair).
Second, you didn't address X.509 certs!
If I have to use a USB stick anyway then arguably the safest way
would be to have it hold a X.509 for authentication. Though that
would mean not just 1Password should support it but Dropbox as
well., I guess.
I wouldn't say I trump Ben. (We are all on an equal footing, with the exception of Dave T and Roustem, who, although they walk among us, are gods.)
But what's even worse is the "we aren't going that way" post that he linked to was written by me.
I didn't mean by my comment earlier today that it's coming. I meant that I was exploring ways to integrate 1Password with SurfEasy. I don't know whether it will be something we will officially endorse, or can be made to work reliably enough to even consider. It's just something I've been playing with.
I have a lot of respect for the way that <competitor> does things. I should note that they have your data stored on their systems. And so the master password provides both access to the data and the ability to decrypt it. Because our data is all local, an attacker needs to get hold of both your data and your master password. I described this as "1 and a half factor authentication". So the differences in the underlying designs between us lead to different sorts of security concerns.
Do not get me started on X.509. Back in the 90s, I thought that if I could just educate people about PKI then all our troubles would be over. I put a huge amount of effort into explaining these concepts to people so that they would use PGP (or later S/MIME). Let's just say that I've become a fan of the thinking around here. Keep things straightforward for people, so that they will actually be able to actually do things that make them more secure. People can use 1Password without understanding how it works.
For us, the distinction between trusting the that the owner of a key is who they say they are versus trusting the owner of a key as a reliable source of saying who other people are is something that seems clear to people in the business. It can be made clear to everyone else if "everyone else" is willing to bother with understanding distinctions like that. (And this is just one of the many examples.)
Anyway, I'm rambling. You might wish to take a look at the related blog post on convenience and security.
So sure, you can create a symbolic link from where the keys are supposed to be to some other location. But you will have to maintain that (and tinker with it when you move from Mac to Windows). But that is completely unsupported. I won't even document doing that, because I want to make it clear that if you try something like that you are on your own. (Note that there may be a copy of the keys file with a . at the beginning of the file name. It's one of our efforts to ensure that these things don't get lost.)
Chief Defender Against the Dark Arts @ AgileBits
Not sure where the symlink thing came from, Jeff, I had to read
the paragraph several times and still went "does he mean what I
think he means, why would you DO that?" ;)
As the blog I linked points out quite correctly, yeah, there's
no panacea. Security and convenience seem forever on a collision
course. I certainly have no solution. All I see is that it's
getting harder, because the baddies are getting smarter and that
means your average non-pro has to do more to protect their data,
yet lack the knowledge to do so as "doing it right" puts up walls
Ah well, getting philosophical here. OK, how about an API
(didn't somebody else just post that request?), then I can code it
Ah. Ignore the symlink stuff. I had misunderstood something that you had said when you talked about putting the keys on a thumb drive. I thought you were thinking of putting the files that contain the 1Password keys onto a thumb drive and making a symbolic link from 1Password.agilekeychain/data/default/encryptionKeys.js (also 1password.keys and .1password.keys) to a the real files stored elsewhere on an external device.
I would never, ever, recommend that anyone tinker with such a thing. And if someone were so foolish as to go against this categorical advice, it would be extremely important that they make very good backups of all of their data beforehand. (Symbolic links like that may not sync reliably over Dropbox, so they may need to be recreated by some script. Also the backups that 1Password makes would no longer include the contents of those key files. (It is the data in those files that are encrypted with your master password).
As I tried to argue that in many places convenience _is_ security. If people don't use a system or they use it badly because it is a PIA to use, then they weaken their security.
Chief Defender Against the Dark Arts @ AgileBits
The PAM module can add a two-factor authentication step to any
PAM-enabled application. It supports:
Per-user secret and status file stored in user's home directory
Support for 30-second TOTP codes
Support for emergency scratch codes
Protection against replay attacks
Key provisioning via display of QR code
Manual key entry of RFC 3548 base32 key strings
...Just a thought. My life is in 1Password. 1Password feels
incredibly insecure without a 2nd factor of authentication. I feel
incredibly insecure without a 2nd factor of authentication.
Oh, and in regards to the article 'Two Factor or not Two
Factor': How about, can you please make 2Factor a toggle-able
option in the settings?
This way, if you'd like accessibility you can choose to leave
two factor disabled (the 'default' setting, since you seem to want
to make it easy for people to get every password for every website
you've got stored, every single bank account, credit card, other
personal information and "secure notes")
-- OR --
If you'd prefer security, peace-of-mind, and overall general
happiness from a product you REALLY REALLY don't mind paying for,
you can enable the 2Factor setting and love 1Password even
The way I see if, if you add a toggle-able 2factor option you're
in a win-win situation. People who want accessibility win and
people who want security win.
Moreover, you win because your customers win because
they are happy!
All I'm saying is the customer is ALWAYS right, especially
an already paying customer.
I hope this is seriously considered, I do enjoy 1Password.
Thanks for the reminder about PAM (Pluggable Authentication
Modules, for those following at home.) To be honest, I haven't
looked at PAM in many many years.
Off the to of my head, I'm skeptical of its use for us. PAM is
about authentication, but your Master Password is actually
used to decrypt a key. The distinction between passwords
for authentication and for decryption is subtle. Normally that
distinction doesn't matter for users, and so these are often
blurred. But I think it may matter here.
As I said, there are no promises about MFA. I can even say that
there are no immediate plans. But it is always useful to keep an
eye on different ways to do it, if we do go down that road. And, of
course, it is great to hear from people about their needs and
wishes for 1Password.
Your voices are being heard, and these suggestions are valuable.
(Now I need to see how libpam has developed in the past
Thanks for that reference, Steve, but it only serves to highlight the distinction between an authentication password and a decryption password.
Let me give a simple example. Suppose you have a file encryption program called "FileEncryptionProgram.app". It encrypts a file for you and stores the encrypted file a my-secret-diary.asc.
Now the developers of FileEncryptionProgram could PAMify their program so that it would use Google Authenticator before it 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 (our bad guy) gets hold 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 build 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.app itself.
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 elsewhere. 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. I'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.
Anyway, thanks for this. I've wanted to write about the distinction between authentication and encryption passwords. I didn't really do a very good job of it in this comment, but maybe it will get developed into a better article at some point. (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.)
Chief Defender Against the Dark Arts @ AgileBits