Automatic Dansk

MFA

Lets say you have a setup where your users authenticate with username and password. You also see growing problems with leaked passwords and users being tricked into false logins. So you want to up the game. What to do?

What about two passwords instead of one? Objectively the security will be better, but pretty much only the way that just requiring a longer password will be. What is worse is, that the extra password has the same issues that the first password has. Adding it is not a good step up.

To be effective, you need to be careful about what to add. To help with this, and to define a language around it, the concept of authentication factors became a thing.

Authentication factors

There are three well-established categories of authentication factors.

category slogan examples beware
Knowledge
Knowledge
Something you know. Password, your-favorite-color-questions... Well-known problems. It can be leaked, it can be reused, it can be guessed.
Ownership
Ownership
Something you own. Security token, ID card, OTP list... A physical thing, that most users loathe bringing along. Some of these can be copied or reverse engineered.
Inherence
Inherence
Something you are. Fingerprint, face, iris... Many sensors can be tricked. Not super reliable, so has to have fall-back methods.

Some people argue that a fourth category should be used. But this is not universally agreed upon.

category slogan examples beware
Location
Location
Somewhere you are. Office, GPS... Coarse-grained. Can sometimes be faked.

The national ID solution in Denmark is called MitID. It has the unusual requirement that users have a "secret" username. What that really means, is not very clear to anyone. Many websites that need you to authenticate with MitID, automatically fills out your secret username anyway. Clearly demonstrating that it is not a meaningful authentication factor.

Secret usernames can be okay for a temporary solution in some OT corner case, but for a national ID solution they are a disgrace.

MitID is going to be replaced by an eIDAS 2.0 compatible solution within a few years.

MFA

Our example with username and password is using a single factor, which is knowledge. To improve this setup you add another factor, giving MFA (Multi Factor Authentication). If the user fails login with one of the factors, then their MFA login fails.

When you choose the second factor you need to follow a rule that says there cannot be more than one factor from a category. So adding another password wont do (it is knowledge again). But adding a security token will (it is ownership).

Apart from that there are many flavors. The exact details on which factors can be used under which circumstances, varies from organization to organization.

The push for MFA

These days most online services that require authentication, is pushing users for adopting MFA. I see it at every login to services where I havent set it up.

With MFA your account will be better protected, and that is a good thing. It sounds like an easy decision, but there is more to it in my opinion.

First ask yourself what it will mean to be compromised. Will it be a real problem for you? Or will it be a minor nuissance? Second consider what the new factor will be. In some cases it is quite involved, like installing an app. To adopt MFA, the proportionality between risk and second factor, should be reasonable. Furthermore have in mind, that it is not all that unusual for companies to take advantage of your second factor. That could be through sending you unsolicited sales material, or by tracking the GPS coordinates of your phone.

If you are one of those designing solutions, then do not repress your user perspective. Avoid solutions that require MFA when it is not reasonable. Users will not have much patience for unnecessary authentication. The best and most comprehensive way to get the most out of the authentication that the users actually do, is by having a single authentication solution that is used by all services that the company provides or consumes.

Stepping up beyond

MFA used correctly, is a good security design, but it is important to understand that it sits squarely in an authentication paradigm that is likely to be surpassed in the near future. If you really want to up your game, start looking at the new paradigm instead. It is called SSI (Self-Sovereign Identity).

Your setup might not be ready for it, the infrastructure might not be ready, but do yourself the favor to familiarize yourself with SSI, so you can take the right steps now, and be ready to hop on the SSI train when the opportunity is there.

Related:
Authentication for generations

Made by a human Licenses RSS feed