Does the new Danish authentication solution for online contact with municipality etc. genuinely use 2FA?

Question

In Denmark, the current digital identification/authentication solution for pretty much any online contact with the municipality, state, etc. is being switched over to a setup consisting of the following steps:

1. You enter your username on the site where you want to log in.
2. You open the authenticator app (one specific, purpose-made app) on your phone with a six-digit code or touch/face ID.
3. You approve the login in the app.

The username is treated essentially like a password in terms of "should not be known by anyone" (as expected, there have been problems with the site helpfully informing you that your username already was taken), but not starred out on any of the sites it's used. The developers maintain that the remaining combination of an authenticator app and a six-digit code to unlock it constitutes two-factor authentication.
Does this actually hold up? If not, does the username/password/userword/passname constitute another factor? (The best English-language description of the setup I can find is here.)

EDIT: I've now found a more detailed description in Danish and had time to translate it. To respond to comments etc.:

• The app can only be used when activated, and an activated app is personal. Activation is done either with the old authentication setup right now if you already have that or at a municipal service desk if you're registering from scratch. Registration involves an activation code shown on the screen and an 8-digit temporary PIN sent by SMS to a mobile number that either is already validated or is validated during registration by sending an SMS with another 6-digit validation code to that number
• the passcode is centrally validated (by "[zero knowledge password proof] technology combined with other technologies", however informative that may be about their implementation) though as I mentioned one can use biometrics to give it instead and they in fact suggest to do so for ease of use
• you do get locked out after a certain number of unsuccessful tries
• you can have up to three copies of the app attached to you, so if you have one on your tablet and one on your phone and lose either device you can use the remaining one to activate the app on your new phone/tablet; otherwise you have to do the registration process over again

Answer 1

Usernames are not meant to be a secret, and as you show, they can be enumerated. In MFA, you are authenticating as that user. So, the username can't be a factor.

By dropping the password and relying on a 2FA app, the 2FA code becomes a single factor. So, they are using 2FA tools to implement a single factor. The secret to open the app (i.e. "the code to open it") does not authenticate the user, it unlocks the app. It would be similar to the PIN for the phone itself. So, no, the app password is not in the same scope for user authentication in the remote system.

This is what happens when developers/designers work with the acronyms of things and forget what the acronyms mean.

"Have we implemented 2FA?"
Checks design and sees a 2FA app
"Yep!"

Unless the app is somehow restricted, a 2FA authenticator app is simply a TOTP calculator. It stores a secret and the code is proof that the device knows the secret. The code is not a secret itself. So a TOTP 2FA app is a single factor unless there are details to the situation that you have not provided.

So, no, a non-secret username and a TOTP app is just a single factor.

Answer 2

As far as I am familiar with similar schemes the argument is not that the username is a factor (it's the identity), but the claimed two factors would be:

• The device you have generates a unique code when you install the app and goes through some type of more robust authentication system (e.g. a similar Dutch scheme¹ will sent you both an SMS and an email and require you to know your postcode (in NL, 1 postcode = 1 specific street), and if any fail you have to wait for a physical letter to arrive in your mailbox). This is one factor.
• And then you have the passcode, which is not verified or stored on your device, so your device doesn't know the correct passcode. This is the other factor. (Note: The usage of biometric 'security' solutions typically takes this factor away by storing the passcode in a slightly less insecure location in the device, trusting the device to only give it when certain biometric authentication passes. This is always less secure. For example my banking app makes this very explicit).

So when you enter your passcode your device is sending some derivative of both (1) the secret stored on your phone and (2) the secret stored in your head. Next it is checked whether there is a corresponding login request for the matching username (which is typically not stored on the device, thus significantly lowering the danger of the device being stolen) and if there is the app offers you to approve the request.

In conclusion: If you do not use biometric security then I think calling this two factor authentication is fair. The biggest irritation for me with this system is that it only allows for numeric (short) passcodes rather than proper passwords, which in my opinion is just stupid and greatly reduces the overall security. And as passcode systems make the use of password managers harder it also means that more people reuse their passcodes. But if they would replace the passcode with a password it could be a pretty decent system overall.

Of course it's also worth noting that there is no guarantee that any specific system that tries to implement this implements it correctly. I would recommend to any architect to just use an off the shelf solution, but I do appreciate the advantages that this approach bring (governments have to spend a lot of effort ensuring their solutions are simple enough for literally everyone).

¹ The last time I interacted with this is years ago. I definitely remember going through this multi step process, but I also remember the first time around having to wait for a letter. I am unsure by this point how the 'robust authentication' process works exactly, but I am confident in the overall concept (robust authentication makes your version of the app unique).

Answer 3

Can you guarantee that the person using the 2FA application is using a password, passcode, or other method to unlock either their phone or their authenticator app? Unless you are working in an organization with specific device policies and are sure that people are using their organization-managed device for their 2FA application, you can't.

Can you guarantee that someone would reasonable keep a username a secret? It's relatively common knowledge that passwords are meant to be secrets, even though not everyone treats them this way or creates and protects them in a secure way. User names, on the other hand, are not commonly considered to be secrets. Treating user names like passwords (especially in the example where you can find out what user names exist) doesn't make much sense from an experience perspective.

Since you cannot generally enforce that a 2FA app requires a password to get to, I don't think that it's reasonable to say that the 2FA app itself is both "something you have" and "something you know". It can only be safely assumed to be "something you have".

In theory, I suppose that the "secret username" could be the "something that you know", but the specific example of unique usernames and the ability to find a username makes that much weaker.

The only case where this makes sense is if your application (or authentication system, if you're using SSO for multiple applications) requires a specific 2FA app that requires a secure password to see the codes. In this case, the only difference is where the work happens. However, I'd want to understand more about how the system links 2FA codes with usernames to see if there are weaknesses there.

Answer 4

The 6 digit code is only something you know and the app is not unique so cannot be a something you have. Furthermore a 6 digit code + a password would only be 2 something you know.

But if the app also has a unique token stored in your phone and hard to extract, it becomes a something you have: nobody with the same app and the 6 digit code but anotheur phone could impersonate you.

A good example for that in a smartcard X509 certificate authentication: the user only types the PIN code for the certificate. Yet the authentication level is the currently highest common level because extracting a certificate from a decent smartcard is not possible without expensive tools, and even with that it should take more than one day, so the user should notice that their card was stolen and have the certificate to be invalidated.

I am not aware of such a secure storage on smartphones, but simply extracting a private app value is not easy on a not rooted (or jailbreaked) phone. So IMHO generating a random token on the app, using it as a private asymetric key and only giving the public key to the authentication server could make that app act as a valid 2FA authentication system. Simply the what you have is not the app but is the phone content.

Answer 5

Correct me if I'm wrong (the source docs, as you say, are in Danish), but this is how it seems. Start by asking what I need, to access a resource protected with this system, that is otherwise too well protected to gain unauthorised access, I get the following:

• I need a username. This is what you enter as an identity, so it can't also be an authenticating factor for that identity. The part you write about how The username is treated essentially like a password in terms of "should not be known by anyone is essentially either no security, or security by obscurity. Either way as they basically admit, its not a factor.

• I need the authenticator app. Well, everyone can get the app, right? They didn't create a novel app just for you alone. At best the app has individualised output, so if two people ran it, same moment, same login, they'd still get different unrelated outputs (a bit like individual one time encryption data created at download for every user of the app). At that point, assuming sensible use of hashing or similar, someone would need the version of the app, or app setup data, that you have. That might count as "something you have". But I don't see anything so far that says that's how it is. Sounds like the app is same for everyone, in which case not a factor. But I could be mistaken.

• I need to login to the authenticator app, using a passcode or face ID, and it then gives me a one time login approval for the resource. We need to know how that login is generated, exactly, because right now I don't see a thing that stops me running the same app on an emulator, tracing where it checks the face ID or passcode is right or wrong, and bypassing the resulting branch. In which case, not a factor. (Remember, the client software is in the hands of the enemy, so they can do anything with it that they like, that's technically possible...) If the app uses (e.g. hashes or whatever) the original face ID or passcode to create the login code, then I can't use the app without that data, and it counts as one factor, which could be something you have (face-> digital biometric data) or something you know (passcode). If it checks the face ID or passcode internal against some expected data, and that check.isn't done against some hashed value or similar, then I can bypass that check or use the check data myself without a problem.

In short, without knowing Danish, its hard to go far into this. My questions would be:

• Is the app or its setup data the same or different per user?
• How are your face ID/passcode, and (if its done this way) any individualised app setup data, used, to generate the authentication code?

If you update the OP with that, I can update this answer. But right now, doesn't sound very much like great security. Sounds like "security designed by non security people". Could be wrong though.

Answer 6

Yes, if the 2FA app contains and uses a secret that's unique to you. If it's got an embedded client key that's different for each install, then it becomes something that you, and only you, have (ignoring the risk of exfiltration).

If multiple users have identical 2FA app it can no longer be something that authenticates you, and only the passcode you provide will contribute.

Answer 7

If you go too far deep, everything becomes something you have. If attacker has access to your computer and has installed lets say a key logger, then they can extract your password and extract TOTP key from your app.

So if your level of security allows for a software app for one time passwords, then a use of a competent password manager shouldn't be worse than entering your password on the web site and using special app for one time passwords.

If you require users to login from a separate device than they use for one-time password generation, then that's higher security. But if one uses 2+ banks and multiple other important accounts like to government/tax services, etc. it becomes unreasonable to believe that users will not turn their passwords into another thing they have (instead of something they know).

At the end you better have a good remedy plan in case of successful attacks.