Posts

Doing the two-step until the end of time

Enigma machineIn my discussion of Dropbox’s new two-step authentication, I skimped on the cryptography. Because we had to move quickly, I wanted to focus at the time just on our recommendations, so I told a few fibs about how the way the six digit codes “get” to your phone. Now I want to explain how it really works.

Not only that, but I will sneak in a little introduction to Message Authentication Codes (MAC), which plays a major role in our newest version of the 1Password data format. This topic is also worth revisiting because our new release, 1Password4 for iOS, works well with Dropbox’s two-step verification.

Speaking of, let’s start with Dropbox’s two-step authentication system. I did try to warn readers that I was being less than forthcoming about the full truth when I suggested that a six digit code is sent from Dropbox (or Google) to your phone:

There are also some really cool things about how the protocols for two-factor authentication work, but I will bite my tongue and leave that discussion for another day. What this means, however, is that a great deal of what I say in describing the system below is a pack of lies.

Even my word “protocol” could be confusing, as it might imply some network activity. The magic of the system is that anything using this type of Time-based One Time Password (TOPT) tool will compute the same six digit code at a particular time with the initial set-up secret. Dropbox’s login system will calculate the six digit code on its own; and a tool that you use, such as Google Authenticator, will also calculate the six digit code on its own. No network connection is needed after the first time setup.  In my example below, I’ll use Google Authenticator, but it isn’t the only TOPT tool out there.

Initial set up

When you first set up something like the Google Authenticator you scan in a QR code. It might look something like this:Sample QR code for setting up authenticator

The code contains a label that will typically be “Dropbox:your-email@example.com”, and it contains a secret that is randomly generated and unique for each account. The secret might look like “MQZDKZRZGBRWMMZXMI4TCMZUMYYDKYTC”. Putting this inside of a QR code just saves you a lot of typing. If you don’t have a camera that can be used to scan the code, there is even a link for getting the information that you should type in. Scanning this in is the only time that information will be transmitted (in this case, transmitted via your phone’s camera) from Dropbox to Google Authenticator.

Google Authenticator on your phone will keep a copy of the secret, and so will the Dropbox servers. That shared secret allows both Google Authenticator and Dropbox to calculate the same six digit codes when needed.

Counting on time

When you log into Dropbox with your username and password you will then be prompted for the six digit code if you have enabled two-step verification. You will then open Google Authenticator on your phone and you will see six digits. Those six digits are computed from a combination of the the shared secret and the current time. The current time is the number of seconds since the first instant of 1970. It is rounded down to the nearest half minute. This is why the number changes every thirty seconds.

Dropbox website prompting for security codeWhen you enter the six digit code during Dropbox’s login process, Dropbox will perform the same calculation. It has a copy of the secret that was first shared, and it too knows the current time. If what you enter matches what it has calculated, you’re in.

Your phone will not need any network connection as long as its clock is reasonably accurate. Fun fact: your phone actually makes minor adjustments to its clock pretty much every time it connects to any kind of network that allows it to check a time server on the internet. Today, most networked computers and devices know the current time to within less than one 10th of a second.

Because the code depends on both the time and on the shared secret, we end up with a different code during each 30 second period. This makes it a one time password.

Beyond the end of the world (January 19, 2038)

Ancient eunuchs foretold global catastrophe on January 19, 2038, as their long count calendar comes to an end and starts a new cycle from zero

—Anonymous

Aztec sun stone (replica)

Replica of the Aztec sun stone. This has nothing to to with Unix or Mayan time keeping.

The number of seconds since the very beginning of 1970, known as Unix time, is often maintained in a single variable in the computer’s operating system. When Unix was first designed, this number was stored in 32 bit variable. That means that the number could range from 0 to 232. Zero corresponds to the midnight January 1, 1970 (UTC). So what time does 232 correspond to? That will be 3:14:07 (UTC) on January 19, 2038. Bad things will happen then to computers that still are still using 32 bit integers to store Unix time.

So will Google Authenticator stop working in 2038? No, it should be fine. Even though iOS devices – based on 32-bit ARM chips – do just use 32 bit “long” integers, Google Authentication doesn’t rely on that. It uses NSDate to get Unix time on iOS.

Indeed, the actual standard defining the TOPT states:

The implementation of this algorithm MUST support a time value T larger than a 32-bit integer when it is beyond the year 2038.

Another wrinkle in time

Unix Time really is the number of seconds since the very beginning of 1970, but that number ignores leap seconds. Twisted clockLeap seconds are added (or subtracted) on occasion to account for the fact that the speed of the Earth’s rotation can change slightly due to earthquakes, other seismic activity, and even tidal activity (not only do I get to talk about a calendar system reaching its end and resetting, I get to talk about earthquakes and tidal waves in the same post!). A leap second was added at the end of June 2012, so noon (leap second adjusted) on July 1 was actually only 86399 seconds later (by Unix time) than June 30 instead of 86400 seconds later as you would normally get between two days.

The TOPT standard requires the use of Unix time, which is defined to ignore leap seconds. This way, everyone who follows the standard will be using the same clock and calendar. Also, keep in mind that Unix time isn’t just for Unix-based operating system like OS X, iOS, and Android. Windows has a similarly defined FILETIME, which differs in its start time and that it counts in nanoseconds instead of seconds, but it can be converted to Unix time easily enough for use in the TOPT protocol.

Time to meet MAC

Earlier, I said that the code, or one time password, is computed from the secret key and the time, but not just any old computation will do. For the system to work securely, we need the computation to meet some requirements which include:

  1. It must be easy to calculate the code from the key and the time, but it must be completely unfeasible to calculate the key from the code and the time.
  2. It must be unfeasible to predict without knowledge of the key what the code will be at some particular time even if you have observed what the code is at many other times.
  3. The calculation will always give the same result if given the same key and time (it is a function).

These look similar to some of the requirements we wanted for a good cryptographic hash function. And a cryptographic hash function will play a central role in how this is all done.

This also looks as if we are using a shared secret key to create a digital signature on the time. Digital signatures also involve hash functions. But “digital signature” isn’t really the right term here because those are based off of public/private key systems. With TOTP, we have a shared secret.

In place of a digital signature, we have a Message Authentication Code (MAC). This is not to be confused with “MAC” of “MAC address” that you see as hardware addresses for networking equipment, and certainly not to be confused with “Mac” (Apple’s family of computers) or “mac” (the mackintosh raincoat). Maybe this will help keep things clear:

A lowercase mac, for when you need wet wear
And an all-caps MAC is made by software
You’d be just as cool as the great Ry Cooder
If  you never confound these with a Mac computer

One of the ways to use a cryptographic hash to create a MAC is the HMAC. You will hear more about HMAC in the not-so-distant future.

Keeping time, time, time

One consequence of this sort of system is that it makes the computers’ knowledge of the time part of the security system. This isn’t anything new; this requirement has been part of the Kerberos system for decades. Indeed, one of my first roles in system administration was keeping clocks in sync with each other, specifically for Kerberos.

TARDIS

Unfortunately, this means that if someone can tamper with the time signals a computer receives from outside, then they can do damage to other aspects of security. We need systems to verify that the messages they get about the time are authentic, but the less-than-ideal state of secure time synchronization could be the subject for a new series of rant posts. Fortunately, I’ll spare you.

It is also not clear at this point what forms of time travel this or other security protocols can resist. I believe that there is a research paper in this question somewhere for an adventurous student and a flexible professor.

Six digits from 160 bits

Let’s now put all of these pieces together. Dropbox and Google Authenticator each have the shared secret from when you set up your two-step verification. And each know the correct time at the moment. So when each calculate the HMAC of the current time, using the shared secret as a key, they will calculate the same number. If they use SHA-1 for the hash function (as they do in the current system) the number that they calculate will 160 bits long, or roughly 48 digits. The final step is to compute a 6 digit number from that 160 bit number. But let’s save time and skip those final details.

Time for closing remarks

Dropbox’s two-step authentication is a great thing, and 1Password for iOS now works more smoothly with it. But it does the most good for people who are using weak or re-used passwords to log into Dropbox. Thankfully, 1Password users don’t really need to worry about that problem.

1Password users should wait a bit before trying Dropbox’s two-step verification

1Password in DropboxDropbox has just released a new, optional, two-step authentication process. 1Password 3 (Mac and iOS) and 1Password for Windows use Dropbox for synchronizing your 1Password data across systems and platforms. So anything that has to do with Dropbox security is of interest to us and to 1Password users.

The bottom line is that I recommend 1Password users not be early adopters of this. Early adopters should:

  • understand the data security gains and risks thoroughly (discussed below)
  • take steps to reduce those risks (have great backups), and
  • be very comfortable using pre-release systems

My recommendation does not reflect any criticism of Dropbox’s experimental system. It looks (from my brief exploration) like it is done extremely well. But for the large majority of 1Password users, it’s just a little early to start using their two-step authentication system.

If you would like to know more about the two-step authentication system Dropbox has just rolled out and why I am recommending a “wait-and-see” approach at this point, read on.

Stop trying to scare us away from it. What does it do?

I will return to scaring 1Password users away from jumping on Dropbox’s beta two-step authentication system later in this article. But it will be easier to do so after I’ve outlined how it works. There are also some really cool things about how the protocols for two-factor authentication work, but I will bite my tongue and leave that discussion for another day. What this means, however, is that a great deal of what I say in describing the system below is a pack of lies. I will be describing how things may superficially appear to users, not how it really works.

Dropbox calls their system “two-step verification”, and that is an excellent name for communicating what it does. I will continue to use the term “two-step authentication” because I will need to make use of the more technical term, “authentication”, further on.

Logging in

Google Authenticator

Once you have set up two-step authentication with Dropbox, then every time you log
into Dropbox with a web browser or authorize a new computer or service to use Dropbox, you will be prompted to enter a special six digit code. It will be a different six digit code each time, and the code that you need to enter will be sent to your phone. So in addition needing your Dropbox username and password to connect to Dropbox, you will also need access to your phone.

There are a number of ways that Dropbox can send the six digit code to your phone. I have been testing with Google Authenticator, and so far (I’ve only been playing with this for a few hours), it works as advertised and is easy to use.

Already authorized devices

When you first set up Dropbox on your computer or set up 1Password on your iPhone to sync with Dropbox you do not need to authenticate those again. The ability to connect remains until you take specific steps break that link. Enabling two-step authentication doesn’t break those existing links. So if you already have 1Password on your iPhone syncing with Dropbox, you will not need to enter in a six digit code into 1Password to allow that syncing.

Linking new devices

Dropbox has just released a new version of their desktop software which is capable of dealing with their two-step authentication directly.  This is great for the desktops, but you might find that you need to download the latest version from Dropbox’s download page.  It looks like version 1.4.17 is the first non-beta version that natively supports two-step authentication.

As I mentioned, if you have already set up Dropbox syncing for 1Password on your mobile device it will continue to sync after you turn on Dropbox two-step authentication. If you do need to setup Dropbox syncing from 1Password after you have enabled two-step authentication, there are some additional steps you need to take. I talk about those in a separate section.

What happens when you lose your phone?

The people at Dropbox know full well that people lose access to their phones. It would be terrible if having your phone lost, stolen, or drenched meant that you could no longer get to your Dropbox data. So when you first set up two-step authentication, you will be given a “backup code”. This is a long, random, sixteen character, and impossible-to-remember code. You need to keep this someplace secure because you will need it to reset two-step authentication if you lose your phone.

The obvious place to keep such an important and hard to remember backup code is in 1Password. I set up a Generic Account under Accounts for this and added it as a Note to my Login for Dropbox in 1Password.

Now, suppose you are traveling and your phone gets stolen or damaged. If you don’t have access to a computer or device that is already linked to your Dropbox account, you won’t be able to reset two-step authentication. You won’t be able to access your 1Password data, which in turn means that you won’t be able to access many of the accounts and services you need. At least, you won’t be able to until you either get to the piece of paper where you wrote down your backup code or get to a computer or device that is already linked to your Dropbox account.

Data availability is part of data security

Dropbox’s two-step authentication eliminates one particular risk—someone breaking into your Dropbox account because they’ve discovered your Dropbox password. But it would not, for example, protect against a general Dropbox breach. Also, your 1Password data is already designed to withstand sophisticated attacks if someone does get a copy of it. Thus, the actual security gain for your 1Password data that Dropbox’s two-step authentication adds is minimal. It is of most use to people who have poor password practices and have secret, but unencrypted, data stored on Dropbox.

Data availability is just as much a part of data security as data secrecy. It is the ability to get and use your own data when you need it. For a dramatic case of what it means when people lose access to their own data, consider what happened to Mat Honan. If he had not found a way to get back into his Dropbox account after all of his personal devices and computers were wiped clean, he would have lost all access to his 1Password data.

Because phones can be easily lost, stolen, or damaged, using Dropbox’s two-step authentication increases the risk to data availability. In opting to enable two-step authentication, you are balancing one risk against another. Indeed, most security trade-offs involve balancing one kind of security with another. In this case we are considering a very small gain in protecting data secrecy against a potentially larger, but hard to estimate, risk of losing data availability.

If you insist

If you insist on trying Dropbox’s new two-step authentication process, here are a few recommendations.

1. Be obsessive about data backups

You should have backups of your 1Password data that will:

  1. be recoverable before you have access to your 1Password data. For example, if your backup is encrypted, you will need a way to get to that password before you have restored your 1Password data
  2. be recoverable if your house burns down
  3. be recoverable if your computers and devices are subject to the kind of “remote wipe” attack that Mat Honan experienced

Another way of looking at this is, if you enable two-step authentication, you should not think of Dropbox as a backup system (you shouldn’t anyway for other reasons). I know that I’ve gotten lazier about personal backups since using Dropbox (despite the fact that I shouldn’t). Any such laziness needs to be reversed if you enable tw0-step authentication.

One option is to make a copy of your 1Password data and burn it to a CD. Your 1Password data should include your Dropbox credentials, including the backup code. You may wish to keep a copy of that CD in your car or some location away from your other backups.

2. Write down your Dropbox backup code

Keep copies of the Dropbox rescue or backup code in a variety of places, including on paper. You need this if you lose your phone. And if you lose your phone and have serious loss of access to data on your computers, you will need to reset two-step authentication without having access to what is on Dropbox.

Setting up and using Dropbox’s two-factor authentication with 1Password

To enable Dropbox’s two-step verification, check out this document in their help center. Dropbox wants everyone who uses two-step verification to participate in their discussion forums. You should join that discussion to see instructions for enabling two-factor authentication in the first place. That is where help, updates, and important changes are discussed.

Once you have set things up and Dropbox is working correctly on your desktops, there is nothing that you need to do with 1Password on your Desktop. 1Password on the desktop doesn’t actually talk to Dropbox; it just makes use of what is in your Dropbox folder.

As I’ve mentioned before, if 1Password on your phones or iPads is already configured to do Dropbox syncing, then again, you are all set to go. Nothing changes. Dropbox has already given a token to the 1Password app which it can use for logging in. It is only if you need to set up Dropbox syncing that you need to take a few extra steps:

Step 1: Follow the normal instructions for setting up Dropbox syncing in 1Password on your device. Note that after you enter your Dropbox username and password, the login attempt will fail.

Step 2: Check your email (the email address that is your Dropbox username). You should get some email from Dropbox that looks like thisDropbox 2-step email

Step 3: When you follow the link in that email you will (once you’ve logged onto Dropbox in your web browser) get to a page that looks like thisDropbox one-time password page

Use the one time password presented on that page as a temporary Dropbox password back in 1Password on your mobile device.

Why am I such a downer?

I am delighted that Dropbox is rolling out a two-step authentication system. This is a good thing for Dropbox to be doing. It is particularly beneficial to those Dropbox users who use the same password for Dropbox as they do at other sites though, naturally, I hope few 1Password users are among them.

It is also early days for this feature. As development and experiences progresses, we will come to better understand the risks of data loss and so be able to provide advice better tuned to the actual risks. But until that time, I have to take the most pessimistic view. I wouldn’t be surprised if weeks from now I’d be encouraging pretty much everyone to sign up.

A note on multi-step authentication and 1Password

Multistep authentication has clear and obvious security benefits. So it is more than natural for people to ask why 1Password doesn’t employ it. I’m planning to write a more detailed explanation of our developing thoughts on that, but I would like to take this opportunity to 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. But one disadvantage 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.

There are approaches that we could take which would approximate the effect of multi-step authentication for what is actually a decryption process. But I will save discussion of those for another day.

Updated on 8/27 to:

  1. Reflect that Dropbox has fully released two-factor verification. When I was writing this article, it was in “beta”. But at about the same time that this article was first published, Dropbox had released released version 1.4.17.
  2. Tell fewer lies about how the second step authentication works. It still pretend that data is transmitted to your phone, but I’ve at least toned down that implication.
  3. In conjunction with Dropbox moving this out of beta and the experience of lots of 1Password users switching over to two-step authentication, I’ve become much more optimistic about when we will feel more comfortable recommending this to 1Password users. I changed my guess of “months” to “weeks”

Two Factor or not Two Factor

“Why doesn’t 1Password offer two factor authentication?” That is a question we face regularly, and one we often ask of ourselves. Ultimately, the question boils down to two kinds of data security risk: threats to confidentiality versus threats to availability.

What is Multifactor Authentication?

Before we descend into the buzzwords that this topic requires, let me first say that “authentication” means proving who you are to some system. When you log into our forums with your username and password, knowing your password proves that you are the same person who set up the account. Your knowledge of your password is an authentication factor.

Of course, 1Password users probably don’t know their passwords for most sites. I naturally use 1Password’s Strong Password Generator to create most of my passwords, which means I not only don’t know those passwords, I haven’t even seen most of them. So to be more precise when talking about logging into a site, I really should have said: “your ability to correctly enter your site password based on some knowledge in your head (your 1Password Master Password)” is an authentication factor, instead of “knowing your password” for the site. But for the sake of simplicity, I’m going to stick with just “knowing your password”.

Something you know: PIN When you use a bank cash card at an automated teller machine (ATM) you must provide the machine with both your physical card (something you have) and with your PIN (something you know). Each of these, the card and the PIN, are authentication factors. So even if you’ve never heard the term “two factor authentication” you have almost certainly been using it for a while. Another example of two factor authentication is with a safe deposit box in a bank. You need ID and signature, as well as a physical key, to gain access.

Because bank ATM authentication requires the card, the PIN can be a weak password; and because the PIN is required, theft or duplication of the card isn’t a disaster (of course, in these cases, access will be completely and necessarily shut down after a small number of failed authentication attempts). Something you have: ATM card The point of this example is to show that two factor authentication allows for each factor to be fairly weak on its own, while still providing an authentication system strong enough that banks and their customers are willing to trust it.

Many Internet services have recently added two (or multi-) factor authentication systems. One way that these work is that when you begin your traditional web login on a new device, the system will send a text message to your phone with a random, one time code. In addition to your username and password, you will need to enter that code to demonstrate you have possession of your phone, which has become a separate factor in this case from knowing your password.

Google AuthenticatorOther two factor systems involve knowledge of the contents of some piece of paper. That is, you may be prompted for the second letter of the third word on the fifth row of your credit card. You would be expected to carry this card with you while keeping your password in your head.

Still other mechanisms involve a higher level of gadgetry. One variant involves a USB device that you would need to plug into your computer. In other cases, a gadget would generate a seemingly random one time code that you would use as one factor along with your knowledge of your password as the other.

How do you solve a problem like passwords?

What you may have noticed from the examples above is that two factor authentication systems are designed, in part, to address the password problem. The password problem is that because most people reuse passwords from one site to another and their passwords are weak, passwords are easily compromised. With what we know about how most people use passwords, those passwords don’t provide very reliable authentication.

1Password is designed to solve the password problem by making it easy for people to have strong, unique passwords. So what we have is a different way of solving the same fundamental problem. If you use 1Password and our Strong Password Generator, then there is little added security gain by using two factor authentication.

There are other proposed solutions to the password problem, but this is already a digression from the big question of using multifactor authentication to get at your 1Password data.

One and a Half Factors?

Currently 1Password uses less than two factors to gain access to all of your passwords, but in a sense it also uses more than one factor.

Let’s look at what it takes for someone to gain access to, say, someone’s Gmail account. What is needed is an Internet connection, the victim’s Gmail address, and the user’s Gmail password. Two of those are easy to obtain, especially since most people’s email addresses aren’t secret. So there is only one factor that matters here: the victim’s password. Once that password is obtained, the Gmail account is completely compromised.

Now let’s consider this case with 1Password. If someone gets hold of your Master Password, do they instantly have access to all of your data? No, they need to actually get hold of your encrypted 1Password data. This can be done either through the theft of a computer on which the data is stored or through a breach at Dropbox. That is, getting your 1Password master password isn’t the only thing that is needed.

I know that computers do get stolen and a compromise of a syncing service remains a non-negligible possibility. That is why I am not calling what we currently have “two factor authentication”. But 1Password does require access to both data and the master password, so it is fair to consider it as involving more than one factor, even though it isn’t two factor.

Your Master Password: A very strong factor

Your 1Password master password is better secured than typical website passwords. For one thing, it is never transmitted over the network. I hope that it is also unique; it is not a password that you use anywhere else. Some ways to steal a password (listed from easiest to hardest) are:

  1. Ask for it: Phishing attacks use this method. People give their webmail passwords to, say, a carefully crafted website that they shouldn’t be giving it to. No phishing scam is likely to trick anyone into providing their 1Password Master Password into anything that isn’t 1Password.
  2. Sniffing it from network traffic: It is frighteningly easy to sit in a coffee shop with free Wi-Fi and collect usernames and passwords or cookies that also enable authentication. I’m preparing a separate blog post on that topic. Again, your 1Password master password is never transmitted over the network, so it can’t be captured this way.
  3. Password reuse: Using the same password in multiple places dramatically increases the opportunity for that password to be captured. Here I have to trust that our users are taking some of our advice to heart about selecting strong and, more importantly, unique Master Passwords.
  4. Password crackers: I’ve already written about what we do to hinder password crackers as well as what you can do.

All of this means that the factor which does most of the work—your Master Password—is very strong indeed. It is not vulnerable in the ways that typical login passwords are. This, coupled with the fact that our design requires separate access to your encrypted data, has led me to believe that adding two factor authentication to 1Password would be an exercise mostly in “security theater” than actual security.

First, Do No Harm

As two factor authentication can be, I’ve listed why it really wouldn’t add much practical security to 1Password. But those reasons, on their own, don’t fully answer the question of why we don’t make it available as an option to those who would like it. Let me start with the biggest reason.

Data availability

For every one report of “someone stole my computer, is my data safe?” query that we get, we get 100 “I’ve forgotten my master password” queries. (That’s an exceedingly rough estimate. We don’t keep a tally of these, but that 1 to 100 ratio seems about right to me.) We know that people lose access to their 1Password data, while we know of no case of someone breaking into someone’s data.

I’ve written earlier about how “data availability” is a part of “data security”, which people often overlook. The concept is indeed far less glamorous than “data confidentiality”. Data availability means that the legitimate user of the data can access it when they need to. I have many hundreds of unique passwords stored in 1Password. If I lost access to those, I would be sad.

Restore menu There are many ways 1Password works behind the scenes to do help reduce the risk of data loss, but for this discussion I want to describe the backups that 1Password for Mac and 1Password for Windows automatically make. Every backup can be opened with the Master Password from the time the backup was created. This is particularly useful for people who change their Master Password and then forget their new one.

Two factor authentication dramatically increases the ways that a legitimate user can lose access to their 1Password data. Loss or damage to the second factor will leave someone locked out of their data forever. If two factor authentication is to really require the second factor, then we can’t back up the information that is in that second factor. Nothing we could do will help protect users against the loss of the second factor. The layers of defense we have for data availability are stripped away with requiring a second factor.

Other drawbacks

There are a few additional things to consider as potential reasons to not include multifactor authentication. Adding complexity in both our system and in what users deal with should be limited to cases where that complexity provides a clear benefit.

We would also need to get any second factor working on all of the platforms we support: Mac, Windows, iPhone, iPad, and Android. (This rules out the often suggested use of something that depends on a physical dongle to be plugged into the computer.) Adding the feature isn’t an insurmountable problem, but it is something that can be easily overlooked by those who only use 1Password on their desktop computers.

For a second factor to provide any security, it must be able to unlock your data even if your data is accessed outside of the 1Password application. We have to assume that the bad guys who get hold of your data can attack the data directly without going through our software. This means that your data is useless to an attacker without the second factor, even if the attacker knows your master password. (This is the whole point of multifactor authentication). The second factor must be required no matter where your data appears, whether it is on your desktop computer or on your iPad.

Now that the foundation of our new browser extensions is settling, we can continue building some great new things along these lines that we believe 1Password users will love. We’re delighted to start shifting our development focus to these new advancements.

Never a Final Word

I’ve tried to show why the need for multifactor authentication in 1Password is not as strong as it might initially appear. Master Passwords are not vulnerable to the kinds of threats which target passwords that are used online. Plus, the 1Password data file represent a bit of a factor itself.

I’ve also tried to explain that there is a downside to adding complexity, both in the code and for users, and the biggest drawback is the dramatically increased risk of legitimate users losing the ability to decrypt their data. Does this mean that our final word on multifactor authentication is “no”? Of course not. We don’t issue final words. “Agile” is part of our name for a reason.

We’ve had great discussions in our forums about two factor authentication previously, and I would like direct discussion of this topic there. Let’s hear your concerns and desires. I’ve created a new forum topic specifically for discussing this post. See you there.