The Case For Multi-Factor Authenticators
Michael Hoffmann
Hi,
So, we've now merrily been using 1Password across just about every device in the household - Windows, Mac, iWhatevers, you name it.
The wife is now heading to the US, but she's not taking any device along, so she'll rely on public computers - libraries, etc - to login to her various accounts. (she must not and will not take her work laptop along for confidentiality reasons)
That's where it occurred to me that this is a pretty big security hole: while you have all your passwords nice and tidily protected by 1P and store them in Dropbox, at one point you must enter actually master passwords through a keyboard. On a computer you don't know and may be infected up one side and down the other with keyloggers and what-not.
The sequence goes something like:
- sit down at public PC to, say, check your email (login and PW for which is in 1P/DB)
- to get to login information you have to first login to Dropbox (which is already a bit backwards if you keep your DB info in 1P as well, but aaaanyway)
- open browser and go to Dropbox website
- type in login info for Dropbox - first attack vector for keylogger
- navigate into your Agile chain directory and select the 1P HTML file
- be greeted by the nice 1Password master password screen
- which has to be entered via keyboard as well - second attack vector for keylogger
Note that there's not a single point where I could have avoided entering my password via the keyboard and do a cut&paste instead!
Any keylogger here would have the keys to the kingdom! Once they get into my 1P and DB they have everything else inside. The whole point of using 1Password just became somewhat useless.
That's where multi-factor would be really, really nice and useful!
I've been trying to figure out a work-around for this conundrum myself before she leaves but it always comes down to the basic problem: unless you have access to a device that has the 1P application or the web extender installed - and which you know and are confident is not keylogger infected, you're a bit stuck!
Any ideas? Or can this scenario convince you to integrate MF authentication? :)
Mike
Comments are currently closed for this discussion. You can start a new one.
2 Posted by Ben Woodruff on 02 May, 2012 01:20 PM
Hi Mike,
Thanks for taking the time to write to us.
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 observations:
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?
Additionally have you see our blog post (written by Jeff) on his subject? If not it is a great read and can be found here:
http://blog.agilebits.com/2011/09/23/two-factor-or-not-two-factor/
Thanks!
--
Ben Woodruff
Positive Experience Architect, AgileBits
3 Posted by jeff on 02 May, 2012 05:15 PM
Hi Mike,
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.
Cheers,
-j
Chief Defender Against the Dark Arts
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.
5 Posted by jeff on 03 May, 2012 12:51 AM
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.)
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com
6 Posted by Michael Hoffmann on 03 May, 2012 01:59 AM
Somehow apropos that this was on a blog today:
http://benlog.com/articles/2012/04/30/encryption-is-not-gravy/
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 of inconvenience.
Ah well, getting philosophical here. OK, how about an API (didn't somebody else just post that request?), then I can code it myself? ;)
7 Posted by jeff on 03 May, 2012 02:38 AM
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.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com
8 Posted by Michael Hoffmann on 03 May, 2012 03:04 AM
Thanks for the clarification!
As for security vs convenience, I think we're actually arguing the same thing but from different directions.
I think in the end it's about options - but I understand that there's only so many resources you guys have and you have to prioritise.
You guys make an awesome product that should almost be mandatory to use! So just keep my request on the wishlist and surprise me one of these days. ;)
Support Staff 9 Posted by Khad Young on 03 May, 2012 03:15 AM
Thanks again for the valuable feedback (and for directing more of Jeff's verbosity outward and away from the rest of the team). :)
Seriously, though, we are glad to have him here. I know I would be clueless without many of his excellent explanations of complicated topics.
We will definitely take your request under advisement. If we can be of further assistance in the meantime, please let us know. We are always here to help!
Khad Young
Forum Choreographer, AgileBits
http://agilebits.com/support
10 Posted by steve on 03 May, 2012 09:57 PM
Does 1Password support for PAM module?
Just use Google's open source 2factor module:
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 one more thought, LastPass supports it... http://helpdesk.lastpass.com/security-options/google-authenticator/
and 1Password is SOOO MUCH BETTER. Looking forward to the 2nd factor update.
11 Posted by steve on 03 May, 2012 10:18 PM
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 more.
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.
Final note:
You can get a rough idea of 2factor with an ssh daemon like I set up on my Mac laptop with the google-authenticator PAM module.
https://plus.google.com/101575696342138480148/posts/Gk8d5vbYsm4
12 Posted by jeff on 03 May, 2012 10:26 PM
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 decade.)
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com
13 Posted by steve on 03 May, 2012 10:44 PM
For instance, I enabled 2factor on my Mac's SSH daemon with the google-authenticator PAM module:
https://plus.google.com/101575696342138480148/posts/Gk8d5vbYsm4
14 Posted by jeff on 04 May, 2012 06:15 PM
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.)
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com
System closed this discussion on 15 Jun, 2012 06:20 PM.