Multifactor Authentication

michaelbehan

So - I just did a test-run of LastPass which features multi-factor authentication. The good? It supports multi-factor authentication. The bad? It hosts all of your information on its "secure" servers. So - if they get breached (ref. www.haveibeenpwned.com) then you're pretty much screwed. 1password is still the best in its league. Just wish it had a magical way of bypassing keylogging while entering your master password.

khad

This is definitely something that is on our minds. I don't want to promise anything, but I do hope you know how much we're thinking about this.

@jpgoldberg's been working on a post about key loggers. I almost linked to it here but realized it hadn't been published yet. It's still a draft (but already an excellent read). In the meantime, you may be interested to read more of his thoughts regarding the enc/auth distinction in his two posts here:

https://github.com/jdavis/twofactorauth/issues/585#issuecomment-46257372

I especially appreciate the table in his second post as I think it makes it easier to understand the distinction. I know you are already aware of it. I was as well but still found it an enjoyable read. :)

michaelbehan

Thank you, @khad‌! If there is anything I can do to help, please, let me know.

[Deleted User]

This is a great discussion… a few comments if I may:

I agree with michaelbehan who indicated that LastPass hosts its information on its servers (Lastpass will argue that its all encrypted before it get to their servers - but I still think that makes their servers a pretty attractive honey pot target - so I am happier having my data synced via iCloud or Dropbox)

I am very attracted to the concept of key splitting…. when jpgoldberg ( this thread at p2 item 46 ) says “Key splitting, would be something that would add real security to data captured from the cloud, as it would defeat password cracking attempts”….. then it certainly gets my vote!

I appreciate that, as suggested earlier in this discussion by jpgoldberg that key splitting probably should be an “opt in” option for users and perhaps some sort of clear understanding needs to be demonstrated by the user to allow the option to be enabled…. that would be fine by me.

In relation to Keyloggers there is comment by khad in another old thread that might provide some assurance (?) for Mac users https://discussions.agilebits.com/discussion/3333/security-keyloggers-secure-input-virtual-keyboards-etc that indicates:

Another great feature that Mac OS X has is called Secure Input. Any application can enable Secure Input (and 1Password for Mac does). 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.

I really appreciate the detailed responses that the Agile folk are happy to provide in these forums and the obvious thought that is being applied to the product and to its development. I have been a long time user of 1Password and can vouch for the fact that the application just gets better and better. It will be great when some of the concepts discussed here go into development.

---

DMeans

I have to disagree that 1Password doesn't perform authentication. Authentication enables an entity the right to perform an action (it enables authorization). Anyone with the password to the database is immediately authenticated (recognized as a valid user) and subsequently authorized to perform administrative actions on the database. What 1Password doesn't perform is identification.

Key splitting makes sense in some applications. In example, if you have a device application that needs to access to enterprise information on an AD fileserver, then splitting the secure password hash (key) between the device and the authentication services makes a lot of sense: the hash can't be used anywhere else, it's only half of the secure token and credentials aren't stored on the device - thus my username/password can't be stolen and used else where.

But that's not multi-factor authentication. It's single factor with a flavor of separation of duties thrown in. IMO, it qualifies for defense in-depth.

Multifactor authentication simply means applying an algorithm that requires at least two of the following: something your are, something you have, something you know.

We've already got the something you know vector (a password) and the something you are vector on some iPhones (finger print). I've not checked if there's a way to combine those two things though.

Applying multifactor on desktop application is an interesting nut to crack. There are several things to consider, such as brute force attacks and data exfiltration through failed attempts and the likely user annoyance with always providing the something you have bit - such as a USB stick, a file, or a CPU ID.

khad

Thanks for following up on this, @DMeans!

You are right that key-splitting is not multi-factor authentication. That is a point I think @jpgoldberg‌ has been making all along. :)

If you haven't yet read his great explanation of authentication vs. encryption passwords that I linked to above, I encourage you to do so. I think it is very helpful. Here's the link again:

https://github.com/jdavis/twofactorauth/issues/585#issuecomment-46257372

That link goes to an excellent comment, but there is a second comment further down as well. It's the one with the authentication/encryption table. For convenience, I'm going to reproduce the table and some of what he wrote.

You are perfectly correct that there is a level of abstraction at which encryption and authentication are doing the same thing. They both are designed to allow only certain parties to do certain things with data. I am not trying to deny that. What I am saying instead is that when it comes to discussions of multi-factor authentication, that level of abstraction is not appropriate. The distinction is a consequence of the technology.

Encryption is about transforming data, authentication is about "letting someone in to something". Authentication systems typically involve encryption in how they do their jobs, but it is the "letting in" versus "data transformation" that makes the difference in these discussions.

(There are important security advantages of an encryption-based system, but those aren't relevant to the adoption of 2FA or key-splitting; so I'm not listing them.)

Those are consequences of the technical differences between passwords used for authentication and passwords used for encryption. Many authentication systems are actually hybrids, and involve encryption. But the authentication portion of those hybrid systems are not the same as the data transformation systems that encryption is.

As outlined in the link above, these differences entail different threats and different responses to those threats.

From another post of @jpgoldberg‌'s in a different thread here on our own forum:

Here are a couple of illustrations of the differences between authentication and encryption. One is about Penelope proving to Victor who she is and Victor letting her in.

>

The other is about having a secret that is able to transform data from a not so usable form to a usable one.

>

We do want something. But because 1Password does not use authentication, we can't (and don't really need to) do it the way that authentication-based systems do. (Fortunately, we don't face the same threats as those systems do, so the need isn't as urgent.)

As always, we don't discuss future plans, but it is safe to say this continues to be on our minds.