How is mailbox.org 2FA method referred to as, correctly?

Question

Their 2FA to log in to their web interface requires two things:

1. something you know (PIN);
2. something you have (OTP, generated by app for example).

After that, you need to log in by:

1. input email address;
2. input PIN, in password field;
3. input generated OTP right after PIN, in password field.

I have never seen such a 2FA method and from an ignorant-point-of-view, it seems ineffective or less secure (at least).

Hence, I want to learn about it and before doing so: I need to know how to refer to it, so I can make my searches.

What is it called?

Answer 1

I've only heard of this method being called OTP "append mode".

From what I can tell, it's a legacy / backwards-compatibility method of 2FA, for cases where an interface doesn't support adding an additional authentication step or field.

Examples include some modes of Symantec's VIP offering (used on a few major financial sites like E*TRADE; and because it's one of the earliest solutions, it uses append mode to make it easy to integrate without modifying login pages); and Duo's append mode.

From a UX perspective, it's pretty confusing for users. Unless the authentication site/context makes it very explicit how to do it, and because appending the OTP isn't intuitive (very different from the other authentication workflows most people carry out every day) ... it's very easy to forget to mess it up - to forget to append, or enter only the OTP or only the password, etc. So the support burden (user lockouts, support tickets/calls, etc.) is probably pretty high.

So it's probably better to avoid OTP appending unless there's a backwards-compatibility need. (But it's no less secure than other options, as long as the OTP is truly randomly generated and expires in a small time window.)

Answer 2

This is a normal two factor authentication (2FA).

They are requiring two things:

• Something you know, in the form of a password (what you refer above as a PIN, but they don't seem to require that it is a number, so it's just a normal password)
• Something you have, which you prove by providing the OTP (one-time password) generated by an app (it could also be provided by a hardware token, for instance).
  • The assumption for this is that if you are able to provide the correct OTP, you have the phone or hardware token with you (this isn't strictly true in that it would be possible to extract the secret from a completely compromised phone, or you could have configured multiple phones with the same seed, but it's generally considered a good enough compromise)

Then, you obviously need to provide the three pieces in order to log in:

• Username (which is the full email address in this case)
• Password
• OTP

The only odd part here is that the OTP is provided in the same field as the password. This is generally used so that existing systems asking just username and password can easily work with an additional OTP. Only the authentication system need to be updated in order to support 2FA, as the rest of the systems would simply consider it part of the password.

This is not less secure than using a separate field. Let's consider that the OTP codes have a length of six digits, which are the most common ones. The authentication server would check if the user has OTP enabled and, if so, take the last 6 characters from the password field and check if they match with the expected OTP, while they validate the rest of the provided password for the actual password.

However, as noted by Royce Williams, while more simple architecturally, it leads to a more confusing user interface.