Multifactor Authentication

michaelbehan

1password is an excellent tool and yet its biggest flaw is the master password. All it takes is a simple key logger to gain access to my password kingdom. Is AgileBits planning to implement an optional, additional form of authentication such as SMS or a phone call? I'd even pay extra to ditch my own master password and use an RSA soft token or the like. Sure, seed files can be pilfered although this still seems a lot more secure to me.

RichardPayne

On Windows, use the secure desktop option. I have no idea if a similar thing exists on the Mac.

michaelbehan

This is a Mac. Secure Desktop can and has been defeated via several forms of client-side exploitation. There are also hardware key loggers. Regardless, if your machine is owned and the evil guy gets system/admin/root/etc privileges then these features can be disabled. Windows DEP is a joke.
If my machine were to be hacked... how could 1password protect from pilfering? The easiest solution I can think of is a 2nd form of authentication that is completely separate from the master password.

RichardPayne

If your machine was hacked to the degree that you're worrying about then the attacker could simply extract the master keys from memory. Your master password would be irrelevant.

michaelbehan

All an attacker has to do is learn the basics of Metasploit or OpenVAS. They do not need to know how to search memory or even how an exploit it works. (Also - why and how long would 1Password keep the master password in memory? That buffer should be shredded (0-1-0-1) multiple times and deallocated as soon as it is supplied which would make finding it in memory nearly impossible). I appreciate your responses. However, we are digressing from my original post which is "Will AgileBits offer an opt-in, secondary authentication feature?".

michaelbehan

Also - anyone who got a D or higher on their GPEN would be able to hack a machine to the degree that I spoke of (not worried about).

RichardPayne

This was the first result on Google for GPEN so not sure what that is ;)
http://www.grencoscience.com/

All an attacker has to do is learn the basics of Metasploit or OpenVAS.

I'm not sure how penetration testing tools would allow you to breaching a secure desktop, unless there's a known vulnerability that I'm unaware of.

Also - why and how long would 1Password keep the master password in memory? That buffer should be shredded (0-1-0-1

It doesn't. As I understand it, it does keep the master keys in memory while it is unlocked which in terms of accessing the keychain is just good for an attacker. This is inevitable, otherwise you'd have enter your master password every time you wanted to retrieve a login.

However, we are digressing from my original post which is "Will AgileBits offer an opt-in, secondary authentication feature?".

I doubt it:
http://blog.agilebits.com/2011/09/23/two-factor-or-not-two-factor/

khad

Multistep authentication has clear and obvious security benefits. So it is more than natural for people to ask why 1Password doesn’t employ it. We're planning to write a more detailed explanation of our developing thoughts on it, but let's discuss the difference between authentication and decryption.

When you connect to some service, like Dropbox, you or your system has to prove that it really has the rights to log in as you. That process is called “authentication”. It is the process of proving to the Dropbox servers in this case that you are really you. You can do this through a username and password; you can do this through a username, password, and code sent to your phone; you can do this by having a particular “token” stored on your computer. Authentication always involves (at least) two parties talking to each other. One party (the client) is under your control; the other (the server) is under someone else’s control.

1Password, however, involves the 1Password application (under your control) talking to your 1Password data (under your control) on your local disk (again, under your control). This is not an authentication process. So 1Password doesn’t even do one-step authentication. It does no authentication at all. 1Password doesn’t gain its security through an authentication process. Instead the security is through encryption. Your data on your disk is encrypted. To decrypt it you need your 1Password master password.

There are great advantages to this design: Your data and your decryption of it doesn’t require our participation in any way once you have 1Password. Your data is yours. Even if AgileBits were to get abducted by aliens tomorrow, you would still have access to your data since we never store it on our servers.

However, one disadvantage of this design is that the kinds of techniques used for multi-step authentication are entirely inapplicable to 1Password. Those techniques are designed to add requirements to an authentication process, but unlocking your 1Password data is not an authentication process at all. Because there is no 1Password "server", there are no (additional) steps we can insist on as part of a (non-existent) login process.

1Password is decrypting data stored locally on your system, it is not authenticating against some service. So in truth, we don't even have 1 factor authentication, as there is no authentication in the first place. So typical approaches to MFA won’t work.

However that doesn't mean that it is impossible for us to do something that looks like MFA. There are roughly two approaches (each simpler than PKI). One of them is key splitting. That is the result of processing your Master Password doesn't actually get you a working key to decrypt further, instead that result would need to be XORed with another 128-bit key. So it is simply a case of storing that other "half" of the key on some other device. 1Password would need to be able to read that device, which may be tricky on iOS, but it isn't insoluble.

The other approach would be to move the keyfile. 1Password (on the desktop) has a file called encryptionKey.js. That file contains an encrypted key, which is what gets decrypted by the key derived from your master password. That file (and some backups of it) are part of your 1Password.agilekeychian (which is actually a folder bundle, which looks like a single file on the Mac). It would be possible for us to allow that file (and its backups) to reside on some device or location. Both that file and the Master Password are required to get any further.

We are more inclined to do key splitting rather than having a movable keyfile.

The real technical difficulty is getting this to work on every platform. Again, because this is all about data decryption and not authentication, we can't just implement this on one platform (if it were to be anything other than just for show). So while this isn't insurmountable it means that even the "simple" approaches that I described would be tricky.

But the real reasons that we haven't put in substantial effort in that direction is because for every case where someone reports that their computer or device has been stolen, we get probably a hundred more of "I forgot my Master Password" or "I damaged my data and didn't have usable backups". My fear is that key splitting or keyfile moving wouldn't just double the rate of people getting locked out, but would increase it much more. The threat of data lose becomes very substantial.

Again, because we aren't running a system that people authenticate against, there is nothing we can do the help people recover their data if they damage a key or forget their Master Passwords.

Now of course we could make it an advanced option with lots of warnings, but we know that people will always dial up security settings to 11 whether it is in their interest or not. Remember that 1Password is a mass market product. It's great that security geeks use and respect it, but we don't want to give our users rope to hang themselves with.

I'm just spelling out why, to date, we have resisted calls for MFA. It's harder to get right for a decryption system than for an authentication system, and we think that it might do more harm than good.

None of this is written in stone. The threat landscape, patterns of usage, and device capabilities change. So while there are no immediate plans add this, we are leaving the door open in the design of our new data format.

michaelbehan

Thank you for this writeup. You are correct. I was using "authentication" imprecisely.
After reading this article - voice biometrics comes to mind.

khad

Voice biometrics would be an authentication process. Again, 1Password performs no authentication.

michaelbehan

Would biometrics (whether touch or voice or w/e) necessitate an authentication server though? I guess I'm wondering why authentication is not being considered. I also do not feel that storing a split key and XOR'ing it with another key is a secure approach. It is more like a false sense of security at least in the way I interpreted your implementation.

michaelbehan

The more I brainstorm the more I go back to the chicken and the egg scenario.

jpgoldberg

There are ways in which biometrics could be used for encryption, though it involves a special kind of authentication first. TouchID on the iPhone does this. There is a secure module within the iPhone 5s that can only be opened with the right fingerprint (authentication) and it contains, more or less, a copy of your iPhone's unlock code. (The unlock code is used to derive in encryption key.) But this works only because the thing that you authenticate against is built into hardware. So it is a "service" that is deeply wired into the hardware itself.

I should also note that biometrics are not very good authentication systems. Even Hollywood scriptwriters know what is wrong with them. They are vulnerable to replay attacks. Someone lifts a finger print (not nearly as easy as it is in the movies, but it can be done), records an overheard voice command, takes a high quality photo of someone's eye, etc.

Also, unlike passwords, you can't change your fingerprint if you discover that someone has made a copy. So outside of very limited circumstances, biometrics are more gimmick than actual security. (I do think that TouchID in the iPhone is a good thing for what it is designed to do, but it wouldn't be a good thing for other applications.

michaelbehan

There is no doubt that if someone is specifically targeting you there isn't much you can do except shut everything off. I still feel that a second layer of security would make people (or least me) more comfortable. Passwords by their very nature are bad because they don't prove who you are and most people use poorly formed, synchronized passwords. I don't see why someone would use only a password to protect other passwords. I really like this product. At the same time the competition is catching on to this "passwords are bad" paradigm that has been preached for many years. I wish 1password would consider using something else like toopher, biometrics or something entirely different.

khad

As I mentioned above, to get what looks like 2FA with 1Password is a very different thing than how it is usually done. And this is exactly because there isn't an authentication process.

It is sometimes (though not always) a mistake to think that an extra layer adds meaningful security. For example, double encryption does far far less than simply improving ones password by a single character. That is one 42 bit password is stronger than layering two 40 bit passwords. I'm not saying that adding an additional layer though key splitting wouldn't be adding meaningful security, but unless it is done right, it may be more security theater than actual security.

Our existing blog post is useful for understanding the current state of multifactor authentication in 1Password, but it doesn't really address the other very important aspect I touched on above. I'd like to again 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 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 and hashcat do, and 1Password protects your data in ways which are appropriate to its design (i.e. PBKDF2 key strengthening).

Let me reiterate what I said above:

There are great advantages to this design: Your data and your decryption of it doesn’t require our participation in any way once you have 1Password. Your data is yours. Even if AgileBits were to get abducted by aliens tomorrow, you would still have access to your data since we never store it on our servers.

However, one disadvantage of this design is that the kinds of techniques used for multi-step authentication are entirely inapplicable to 1Password. Those techniques are designed to add requirements to an authentication process, but unlocking your 1Password data is not an authentication process at all. Because there is no 1Password "server", there are no (additional) steps we can insist on as part of a (non-existent) login process.

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.

The ability to get data via sneakernet to iOS and Android devices is easier than ever. So that changes the situation from "not practical" to "not implausible". The fact of the matter is that we don't know in detail what difficulties we face until we try. And on that, the "hold up" is priorities.

The biggest case for key splitting is that in 1Password, as in any well designed crypto system, the weakest point is people's Master Password. And so building up defenses there is what makes the most sense, and key splitting is one approach. But we need to make it reliable and easy enough so that it will work for the people who need it most. If it takes some expertise to set it up and manage it, then it will be used correctly only by those people who already know to use a strong Master Password.

Anyway, as you see, I am arguing both sides here. And let me add, that from a cryptographic point of view, key splitting is very attractive. The cryptography is simple, elegant, and powerful. It's the key management that gets messy.

michaelbehan

I understand your points and they are valid as implementing what I am suggesting goes against the current design of the app.

I feel like I have exhausted this post. Thank you all for your feedback. As for me I am going to check out other avenues.

khad

Only you can make the security decisions that are right for you. We tend to think that ceding control of authentication of your data to a third party has some downsides that we thus far haven't been interested in pursuing. This is not likely to change in the future, but key splitting is one way to achieve something similar without ceding that control to a third party.

Thank you for giving us an opportunity to explain things, and an extra special thanks for taking the time to let us know you would like to see something like key splitting added as an option. It's certainly something we have considered. We just want to make sure to get it right if/when we implement it, but we've (almost) always refrained from discussing future plans because we really dislike the idea of disappointing folks if there are reasons — however valid they may be — we need to abandon a plan.

It is great that you are thinking about these things. :)

Cheers!

michaelbehan

I totally agree about not using a 3rd party service. What I was suggesting is something that runs natively on the platform.
And I totally get your point about not wanting to disappoint people.

Thanks for all of your feedback and clarification.

Take care
Michael

khad

I totally agree about not using a 3rd party service. What I was suggesting is something that runs natively on the platform.

What form of MFA do you see working like that that doesn't rely on a third party? Key splitting "runs natively" (although it doesn't really run), but any authentication must be validated be a third party or it isn't really authentication. It sounds like key splitting is exactly what you're looking for, but please let me know if I've missed something.

michaelbehan

By third party service I meant something that establishes an internet connection and shares information. I was not ruling out third party libraries or frameworks.

khad

Right. The examples you gave in your original post would all require a third party to authenticate (either via the Internet or some other communication channel). They cannot be useful without a third party:

• SMS or a phone call
• RSA soft token or the like

If you are sending yourself an SMS that sort of defeats the purpose. And the input from the RSA token requires validation. I suppose it may not have to be done via an Internet connection, but it does require a communication channel of some sort.

michaelbehan

I suppose I stumbled off my own beaten path. :)

jpgoldberg

Hi @michaelbehan‌!

I do understand that having some second factor would, as you say, "make you feel more comfortable." The difficulty we face is whether we should go ahead with something that makes people feel more comfortable even if it doesn't actually improve security (and might even weaken it).

As @khad pointed out, the security architecture of 1Password is different than those which store your data in their services. Those face different threats, and should not, as you correctly point out, be protected merely by a password. 1Password does not share that security architecture, and so both the needs and the means available are different.

Introduction to key splitting

What might be appropriate for 1Password would be "key splitting". This might appear to people as multi-factor authentication although the underlying mechanism has nothing to do with authentication. In a key splitting mechanism, your Master Password would need to be combined with a separate (random) key which could be stored on some device of your choosing in order to derive the actual encryption keys for your data.

Because 1Password isn't authenticating against some separate system, this "second factor" would have to work on all platforms one might synchronize data to, which is why this sort of thing is difficult to implement in a usable way, although it is something we are looking at over the longer term.

As you may or may not know, your Master Password gets processed with something called PBKDF2 to derive a "key encryption key" or "derived key". That derived key is then used to decrypt your master key. Let's call the derived key, k_d and the master key, k_m. With key splitting there is a second key, let's call it k₂, that is a stored someplace that does not sync with your 1Password data and is not derived from your Master Password. Suppose for our example that k₂ is stored on an encrypted USB device.

Currently the master key is encrypted with the derived key. (This is actually a bit of a simplification.). But with key splitting, the master key would be encrypted with the combination of the derived key and the second key, k_d ⊕ k₂.

In this way both the derived key (from the Master Password) and the second key would be useless on their own for decrypting your data. Both would be required.

What it would take

Because there would be no way to decrypt your data without both of these, then this has to work across all platforms. If you sync your data among Mac, Windows, iOS and Android, then there has to be a way for each of those to read in your second key. The second key cannot by synchronized with your 1Password data as that would defeat the entire security purpose of it.

So cryptographically, this is simple. Getting it to work for people is hard. Furthermore, it must be made clear that losing or damaging your second key would be like forgetting your Master Password. There is no recovery mechanism.

khad

Upward and onward. :)

michaelbehan

@jpgoldberg‌

I really appreciate your explanation. I read Applied Cryptography years ago and got lost about 1/4th of the way through. Thank you for simplifying it for me. :)

jpgoldberg

You are very welcome.

I remember reading Applied Cryptography 2nd edition when it first came out. I even had a peculiar "argument" with Bruce Schneier about an "error". In the introduction he states that he will send a copy of the sample code on a floppy to those who spot errors in the text. I was living in the UK at the time, and he couldn't have sent me the floppy without violating US export laws at the time. So I claimed that his statement about sending the floppies was therefore an error that merited him sending me a floppy.

There is actually a lot that is wrong and outdated in that book, and unfortunately its popularity has led to some poor practices today. So it is useful for historical purposes, but it should not be considered a crypto textbook.

If you do want to give things another go, I recommend the Stanford/Coursera cryptography course. It can be tough going, but it is thoroughly modern and really does teach the core concepts systematically.

michaelbehan

Awesome. Thank you! I am adding that to my list. Right now I am neck-deep in GXPEN material. You guys seem like a pretty cool team and very sharp.

HalfBekend

As touch id has been addressed in this thread, I would like to comment here.
On the iOS device, it is very cumbersome to enter the Master Password that I also use on the Mac and Windows versions. So, in practice I either don't use the 1Password app on the iOS devices. Using another (simpler) Master Password to gain access on the iOS device does not seem to be a good option: iOS devices are used in situations where other people are most likely to see you typing them in, iOS devices has the highest chances of getting stolen, lost etc.
So, in that view, I do see a point in using the touch id service (or another well implemented fingerprint-system) to get access to data in 1Password (if not to all data, at least to some most frequently used data such as pin-numbers or "wallet"-items thereby avoiding having to enter my complete 1Password.

The one reason from me to switch from an iPhone 4S to iPhone 5S was to pass the entry screen without having to enter a simple code. In my view the security that that gives is not reliable: it is used so often that anyone who wants it, can learn that code from looking at what another types in. I know this is so, because my whole family knew my password and I never told them...
So I hope, fingerprint recognition will makes its way into 1Password for iOS real soon :)

jpgoldberg

You are absolutely correct, @HalfBekend‌, that for many people the limiting factor on the strength of their Master Passwords is the difficulty of using it on an iPhone.

I can't promise anything, but we are acutely aware of this issue.

royofsf

Does 1Password ofer two step authentication?

Is it thinking about this?

Jasper

Hi @royofsf,

I've merged your post with an existing discussion. Please see above for details, especially Khad's post #8.

Please let us know if you have any other questions!