In part 1 of this article series we talked about authentication in general and introduced the concept of multi-factor authentication. It was shown that multi-factor authentication is that an entity, such as a person is authenticated by the use of not just one but two authentication factors. Typically, the 1st factor is a secret password and the 2nd one is an algorithmically determined number, generally known as a one-time password (OTP).
This article explains which methods are generally used to technically implement MFA into existing systems.
Before digging into details, have a look at Figure 1. It shows the basic concept of how MFA technically looks like. In the center of the diagram the authentication client is shown. This is the service to which the user (shown on the right side) has to authenticate himself. This could be a web page, a network device (e.g. a router, a switch, a Wifi access point,…), a Windows client in an office network, or similar.
It is called authentication client because very often, at least conceptually, it does neither serve the user credentials itself nor does it do the actual authentication task, i.e. the password comparison. This is done at the authentication servers shown on the left side. These authentication servers are typically some kind of database system. In an office network very often this is the Microsoft Active Directory (AD).
As also shown in Figure 1 there are two authentication servers in place. Obviously, because with MFA two different authentication factors are used. Thus, each factor has to be authenticated against a database.
From a security point of view it is a good practice to split the authentication systems and methods as far from each other as possible. This is because if we assume that a system was partially compromised by an attacker he might still not control the full authentication mechanism.
Traditionally this concept has a long history within electronic banking systems. To complete financial transactions transaction authentication numbers (TAN) are used. They were always transmitted on a 2nd and different way than the user authentication (the login) itself. Formerly, they have been printed on plain paper and sent to the users with snail mail. Later and still today SMS messages are used for the 2nd authentication factor. Nowadays, Push-TAN apps on smartphones got popular. But actually, one should be aware that the concept of having separated ways for the transmission of authentication factors is weakened by having electronic banking and the Push-TAN app on the same system. Of course, strong cryptography and other security measures are employed but still, the concept gets weakened. Immediately, attacks have been shown as soon as these apps have appeared.1 However, this was just mentioned to describe and emphasize the meaning of having independent authentication systems and transmission ways for these two factors.
Basically, we can distinguish between two different approaches:
In the first case, if the client directly supports MFA, the client will divert the two factors appropriately to the authentication services (according to its configuration). Basically this is a very elegant solution and from the security point of view also advisable because it allows to hash and encrypt both factors in an early stage of the whole authentication process. It also diverts both factors onto different transmission lines. Both makes it harder for an attacker to break it during transmission.
Keep in mind that it is vital to hash passwords during transit because even if MFA is in use an attacker may still not login to the service being observed because of the OTP, but the attacker may reuse the password on some other service if it is not unique. Even if it is hashed he may reveal the plaintext password if it was not chosen properly. You should read our article series about “Password Insecurity” for more details.
This concept is increasingly seen across the web on public services. Even many social networks such as Xing, Facebook, Twitter, and similar offer MFA as a login option. Most of them use the time-based one-time password algorithm, generally known as TOTP. This was standardized2 in RFC6238 in 2011. Standards mostly guarantee good interoperability.
Of course there are several other methods available, some of which are proprietary and are implemented as small hardware devices which either display the OTP directly or which work as USB-based keyboard emulations (U2F) and “type” the OTP after pressing a key on it.
A further method is to use smartcards. Smartcards are small hardware devices which are a little bit more intelligent than those simple hardware tokens from above. Actually, smartcards are a hybrid approach to MFA because the authentication itself is done solely with the smartcard which is just a single factor. But the smartcard usually has to be unlocked with a password or PIN. You can think of it as being like a bankcard. The transaction is authorized by the card but you have to unlock it usually with a PIN.
These smartcards are a pretty secure method if done right. The big drawback of smartcards are their interoperability. During the past decades many vendors produced many different cards and protocols all based on some proprietary solutions. This may cause huge headaches and are thus very often just useful in a small environment with a limited number of people accessing some very secure services. Meanwhile there is the upcoming FIDO2 standard3 which might improve this situation in the future.
What if the client does not support MFA but MFA is a requirement? There is a solution for this scenario and it might be implemented on almost all clients with some constraints. Figure 3 shows how the concept works.
Any client to which a user may authenticate provides a username and password field but no possibility to input a 2nd factor. In this case the user inputs the password and the 2nd factor into the same field concatenated to each other. As described in the previous Section this 2nd factor is derived from any token generator independently if it is a hardware token or a mobile app. Smartcards usually do not work with this concept.
Usually, the authentication client will send this set of credentials to an authentication server (a single one) but we place an authentication proxy in between. As show in Figure 3 the proxy will split the request – the password field in particular – and forward it to the appropriate authentication servers.
From this we can derive some advantages and disadvantages.
We showed the basic concepts of how MFA generally is implemented and which roles are involved in the whole authentication process. It can be distinguished between clients which support MFA and those which do not. The first one have some security benefits and usually have a more simple network and configuration setup. Very often users can easily manage their own 2nd factors.
A different approach is the use of an authentication proxy, being PrivacyIdea an example. This is necessary for clients which do not natively support MFA but can also be used for other clients. In this variant both factors are combined into a single password which is dissected by the authentication proxy again. The advantage of this concept is that it fits better for a centralized authentication management and that various different MFA systems can be used at the same time for different applications.
Bernhard R. Fischer started his career as a network engineer responsible for building up a national IP network and later developing and maintaining the major Internet services for this network such as DNS and Email. After his studies of business economics and information systems on the University of Vienna he became a researcher and teaching fellow on the University of Applied Sciences of St. Pölten in the fields of computer networks, operating systems, and IT security. Since 2017 he is employed as a senior security consultant at Antares-NetlogiX GmbH.
During his whole career Bernhard contributed to a lot of public projects and discussions, attended conferences as a speaker, and voluntarily supported numerous open source projects not just as an advocate but as software engineer and developer. He always placed emphasis on robustness and quality of software and systems. He painstakingly investigates the details of everything and he willingly passes his knowledge to everybody who is interested.
Some of his own public projects can be found on Github, some articles and opinions on his personal Tech & Society Blog, and on Twitter. Bernhard is also into sailboat sailing and runs his own professional web site and produces the technical podcast Schiff – Captain – Mannschaft which is about sailing, seamanship and sailboats.
[1] Vincent Haupert, “(Un)Sicherheit von App-basierten TAN-Verfahren im Onlinebanking”, 2015, @32C3, https://media.ccc.de/v/32c3-7360-un_sicherheit_von_app-basierten_tan-verfahren_im_onlinebanking
[2] IETF, “TOTP: Time-Based One-Time Password Algorithm”, 2011, https://tools.ietf.org/html/rfc6238.
[3] FIDO2: WebAuthn & CTAP, https://fidoalliance.org/fido2/
