MFA Decision Making Part 2

Last time I wrote about how to decide which of the many many options for multi-factor authentication to use. While this involved a fairly complex spreadsheet of various options, they all pretty much came down to three things:

1. If U2F/FIDO2 is an option, use that

2. If not, use TOTP, or smartcards if you are in an enterprise

3. If neither is possible any MFA provides more protection than no MFA

To be honest, that’s pretty universal advice when it comes to MFA. If you want to just walk away with that, you can stop reading now. Everything else I have written in other articles, as well as this one,  is largely just justification and technical details leading to that summary. 

States of Authentication

Most of the time we think of authentication as a binary state; you are either authenticated or you are not. However, we can make our system more flexible if we are willing to accept a certain amount of complication. 

First, consider the case where you have at some point authenticated. If you are familiar with how cookies work on websites you know that the website sets one or more cookies when you authenticate. One of those could be a long-lived cookie that can be used to identify you next time you visit. Your browser will automatically present it to the site when you return allowing the site to recognize you. When you are recognized the site can present you different authentication requirements. A lot of sites allow you to choose to “remember me on this browser”. What that does is instruct the site to recognize you based on old authentication cookies. The site can now re-authenticate you using different requirements from those used when you are unrecognized. 

While re-authentication is very common on the web, there are other scenarios where it is used as well. For instance, after typing your password once you can authenticate to your Mac for while using just your Apple Watch. At some point you do have to type your password again to continue using the feature. In other words, Apple has implemented a re-authentication time-out, which is another possibility. Although, in my opinion, this particular one is of limited value. It would be better if the computer detected that it was being moved to a new location and triggered a full authentication based on that. Supporting MFA login using your Apple ID would be awful cool too. 

Using lower requirements for re-authentication swaps one factor - such as the second factor - for another - such as a pre-existing HTTP cookie. Some argue this reduces security. Whether it does really depends on your point of view. From my point of view it enhances security because it contributes to adoption of MFA, which enhances security. 

On that note, if your computer is recognized using a cookie that contains a cryptographic secret, and presuming that cookie was stored somewhat securely, and you present a password and a hardware authenticator, is this really two-factor authentication any longer? Some people at Google refer to three-factor authentication (3FA) and it is an apt metaphor. It means that factors that I judged did not provide assurance under 2FA may do so if there is some assurance provided by the known computer.

Step-Up Authentication

One way to tweak authentication that indubitably enhances security is step-up authentication. Step-up authentication involves requesting additional factors to perform an action that is particularly sensitive. 

For instance, my credit union, First Tech Federal Credit Union, has a mobile phone app, as do most financial institutions. When you first install the app it requests that you authenticate. After that it will show your balances just by opening the app. It relies on you unlocking your phone to provide sufficient assurance to show you balances. If I wish to transfer money between my accounts I can log in using facial recognition or touchID, or a password if I choose to. My account, of course, also requires 2FA. If I wish to pay bills to an existing payee I can do that now, but if I wish to set up a new payee I have to present my second factor (only the second factor, not the password) again to approve this. 

This is an example of step-up authentication. Seeing balances is relatively less sensitive and they’re letting me do that while only being recognized. Transferring money between accounts could cause bill payments to fail, but as long as I am only transferring between my own accounts the money is still mine. This merits a slightly higher level of assurance, stepping up the authentication requirements. Setting up a new payee allows you to transfer all the money out and would be a really straightforward way for criminals to rob you. Therefore they require you to authenticate again, using a fairly strong second factor - step-up authentication. This is well thought out and I imagine they went through some analysis getting this right. 

Decision Making Framework

This brings us to the picture. It is similar to the one from the last article, but with re-authentication a lot more factor types suddenly become reasonable. 

Figure 1 - Known Device/User Re-Auth

As before, these judgments are mine! You may have a completely different opinion about what provides an appropriate level of assurance. You get to make those decisions. If you ask me in a couple of weeks my opinion may have changed too. That’s fine. In case you would like to make your own decisions using this framework the spreadsheet is available read-only for you to use or copy. 

Note: if you need a high-contrast version of the spreadsheet, please contact me.

In addition to new options, we also have whole blocks that are not viable options. For instance, SMS-based 2FA is not really an option for logging into a PC. We also have a lot more green. This makes sense, especially in a remote authentication scenario. If we consider the known computer to be a factor in the assurance level new possibilities open up. 

Local User Authentication

When you unlock your mobile phone, you are effectively re-authenticating. You created an account when you first configured the phone. Now, ~80 times per day, you unlock the phone to use the services in that account, including unlocking any credentials for remote services protected by that account. This is a user re-authentication scenario as well. The device knows you from before and just need you to show you know the same secrets you knew when you set up the account. 

Personal Use

For personal use, your choices really come down to whether you should feel comfortable checking the “remember me” button. In my opinion, it depends on the site. If the site has some sensitive data and simply bypasses login entirely if I do then I will not use the remember me feature. Cookies can still be stolen, and I would like that extra level of assurance in this scenario. I generally do use the remember me option for lower-assurance services as well as medium assurance ones where I know the site will not let me perform any sensitive actions without re-authenticating. Some sites only bypass 2FA for re-authentication. This seems backwards to me, so I don’t always use this. Your judgment may vary. These decisions are ones we each need to make for ourselves. 

As you can see I also tend to use possession factors, such as an Apple Watch, to unlock my computer. However, in my job role I have to use Windows, Linux, and Mac at various times, often all in the same day. Typically, I run Windows and Linux either in virtualization locally or on a server somewhere. This means I can’t benefit from logging in using possession proofs. It pains me in some ways to admit this, but because I have to type my password 20+ times per day into interfaces that are not integrated with a password manager I optimize for easily typed and easily remembered passwords that may be slightly less secure than I would use if I had to type them once a week or even once a day. My research into password behaviors indicate I’m far from the only one who behaves this way. The implications are clear: if you require people to type passwords frequently and change them often they will pick weaker passwords. Enabling modern, simpler, authentication methods can result in stronger passwords and higher security levels.

One final note, in Figure 1 I say that a four digit pin is enough for a low assurance local scenario. Before people give me lots of grief about this, let me point out the low in “low assurance” once again. This means there is no sensitive data exposed. No email. No bank accounts. This is not the phone you use for 2FA. Personally, I am not sure this is a very common scenario, but when it is I think four digits is OK. The primary use case I can think of for this are demo devices used at conferences and for training. 

Enterprise Authentication

For enterprises the green in Figure 1 is getting slightly more prevalent than in bootstrapping scenarios as well. For the same reasons I stated above, I think enterprises should allow for use of possession proofs for local login but with very short time-outs. Even for enabling use of low-assurance services this may be OK. For higher assurance scenarios, a re-auth requirement of 18 hours (or so) should be imposed, however. 

Why 18 hours? Why not 8 (a standard workday) or 24? Very simple. Think back to last week. What time did you start working? For me it was 07:00, 07:30, 07:00, 08:00, and 07:15. When did I stop? Usually between 16:00 and 17:00. If the time-out were 8 hours I would have to authenticate twice a day, and often once more if I checked in before bed. If it were 24 hours I would have had to authenticate when I got in on Tuesday, but half an hour after I got in on Wednesday. By making the time-out 18 hours I have to re-authenticate first thing every morning and I stay logged in for the entire work day. This provides a very consistent experience. For more sensitive scenarios use a shorter interval or per session authentication. For extremely sensitive use cases require per-transaction or per-record step-up authentication. 

Also notice the green flood on “Strong Local Biometric Unlocking HW Crypto”. I really believe Microsoft  did a great job on the security of Windows Hello. If Apple allowed you to require a second factor, such as a PIN code alongside TouchID, it would provide the same level of assurance. That would make it suitable for higher assurance scenarios. Both are excellent options for simple and easy-to-use step-up authentication for high-assurance scenarios.

Public-facing service

If you are building a public-facing service you should take advantage of the assurance offered in recognized device scenarios. You should also leverage these in your fraud algorithms. Leveraging strong biometrics options with hardware secret storage is a great option for supporting both mobile platforms as well as many other low and medium assurance scenarios. Step-up authentication also offers significant benefits and most services can come up with scenarios where step-up auth, inline authentication, or short time-outs can provide significant security value.

Finally, there is an interesting security knob that is hardly ever used. When we spoke about the FIDO protocols we talked about how each authentication has a unique monotonically increasing transaction identifier to identify cloned authenticators. This can also be used in authentication cookies. If a site knows that the latest cookie it issued was issued at 19:37:45 on 14 April 2020, it may not want to accept a cookie issued on 18 March 2020. That would shorten the time interval in which stolen cookies could be used. There is a significant downside to this, which may be why it is so rarely used. If a customer uses two devices or two browsers, the re-authentication cookies would be rejected every time they switched browsers, negating the feature. However, for higher assurance scenarios this could be acceptable, especially if the downside is a simple FIDO2 second factor challenge. 

This is the last of my planned MFA articles. If you have liked these and/or would like me to write about something else, drop me a line on LinkedIn. I plan to write more articles, but now I have to think of some new topics.