How to make Authentification accessible

Today's topic is accessible authentication, specifically two-factor authentication. Two-factor authentication means that you need at least two independent factors to log in. For example, a password and a code from an authenticator app.

An important point to note is that a fingerprint or facial recognition does not count as a second factor. When I unlock my smartphone using a fingerprint or face scan, it merely replaces the PIN. Therefore, it remains just a single factor. This is frequently confused.

Today, two-factor authentication is one of the major obstacles in daily digital life. More and more applications require multiple security factors. This particularly affects administrative apps, health insurance apps, or digital mailboxes.

An example of this is the German electronic patient File. Users often have to go through multiple steps there: entering a password, entering an app PIN, and additionally holding the health insurance card against the smartphone.

Why is accessibility so important in authentication?

Because we absolutely depend on many of these applications. Banking apps are a prime example. They must comply with high security standards. There are legal requirements for this, including directives from the EU.

In the past, there were the well-known TAN lists with long sequences of numbers. Later came SMS authentication. Today, mostly only authenticator apps or dedicated hardware are used. Those who cannot operate these procedures are often locked out from essential services.

This is particularly problematic because many banks now have hardly any local branches left. Without a working authentication method, one is quickly excluded.

Authentication in the WCAG

In WCAG 2.2, which is the current version of the international accessibility guidelines, there are two criteria concerning the topic of authentication.

The first one is "3.3.8 Accessible Authentication (Minimum)". It is a Level AA criterion and must therefore be met in many cases.

Put simply, it states that people should not have to memorize anything when logging in. Passwords would actually be problematic because of this. However, passwords are permitted if password managers can be used. In that case, users do not have to memorize the passwords themselves.

Captchas are also mentioned. This refers, for instance, to graphic codes or image puzzles. These so-called cognitive tests are permitted if an audio alternative is available. Captchas are also not a second factor. However, since they are frequently used, I would still like to mention them here.

Nevertheless, I consider this to be problematic. This is because there are also people with deafblindness or combined vision and hearing impairments. For them, neither image nor audio Captchas are usable.

In general, I no longer consider Captchas that require users to actively solve something to be a good solution today. Many people fail them – due to technical or cognitive reasons.

Systems that analyze user behavior are much more sensible. That means procedures designed to detect in the background whether a human or a bot is using the website. Examples of this include Friendly Captcha or solutions by Cloudflare. There are now also open-source alternatives available. I cannot judge how secure they are, but the approach seems significantly more practical.

Please avoid using Captchas that require people to decipher characters or solve tasks whenever possible.

Then there is also the criterion "3.3.9 Accessible Authentication (Enhanced)". This is a Level AAA criterion and usually does not have to be met. Fundamentally, it deals with the same topic, but it is stricter. Classic Captchas are no longer permitted there. Only procedures that work in the background and evaluate user behavior are allowed.

The topic of Captchas will probably stay with us for a long time. Due to AI systems and Large Language Models, many websites are now trying harder to block automated access. Because of this, more and more sites are implementing Captchas – even normal websites without any special security requirements.

I fear that this will still cause major problems for us if classic Captchas like reCAPTCHA or hCaptcha are used for this purpose again.

The desire for protection against bots is completely understandable, of course. Nevertheless, systems that are as accessible as possible and based on behavioral analysis should be used. This is not always straightforward in terms of data privacy laws, but it is often still the better solution.

How can authentication be made accessible?

The honest answer is: there is no perfect solution. Passwords, SMS codes, authenticator apps, or biometric methods each have advantages and disadvantages – depending on the user group.

Relying solely on passwords is not enough. Many people use very simple passwords or reuse the same password multiple times. If a password becomes known, multiple accounts are often compromised at once.

Therefore, you should always offer multiple options. It is also important to provide alternatives to classic passwords or PINs.

On smartphones, biometric methods have now become standard. Fingerprint or facial recognition frequently replaces the entry of a PIN there.

I myself, for example, have long forgotten the PINs of many banking apps because I enter them so rarely. Without biometric login, I would probably no longer be able to use some apps at all.

The reality is therefore often: either people use the same simple PIN everywhere – or they use biometric methods, which in many cases are even more secure and significantly more convenient.

Another possibility is so-called passkeys. Unfortunately, they are still relatively rarely seen. I can only describe how this works from a user's perspective: when you log in with a username and password, you are frequently asked whether you want to save a passkey on the device. Presumably, this involves encrypted information that is stored locally on the device.

During the next login, you can then simply use the normal device authentication. On Windows, for instance, the familiar Windows login screen appears. You then log in with the Windows password or via fingerprint and no longer with an additional password for the respective service.

This is a very convenient solution. In addition, passkeys are considered relatively secure because they are tied to the specific device. They cannot simply be copied and used on another device.

Then there are also special hardware tokens. These devices generate one-time codes, for example, or serve as a means of logging in in another way. I myself have hardly any practical experience with them so far.

This can also be a sensible solution, especially for people who prefer working with hardware rather than apps or passkeys. Furthermore, hardware tokens are often well-suited when you need to log in on multiple devices.

Another option that I personally find very pleasant is login links via email. Spotify offers this, for example. I like this solution because I hate entering long passwords on smartphones. This is particularly tedious on iPhones because you constantly have to switch between letters, numbers, and special characters. But it isn't really pleasant under Android either.

A login link eliminates this data entry. You simply click on the link and are logged in directly. This is convenient and often significantly more accessible.

QR codes could also be an interesting solution. For example, you could provide the username and password or a login token as a QR code. However, this is seen only very rarely.

Of course, QR codes are not accessible to all people either. Nevertheless, they can be helpful in certain situations.

Another widespread solution is Single Sign-on, or SSO for short. With this method, you log in via an existing service, for example via Google, Apple, or Microsoft.

Fundamentally, I consider this a good solution. It is a pity, however, that these procedures are dominated almost exclusively by large US platforms. It would be nice if there were more independent or European alternatives here.

Nevertheless, it must be said: many people already have accounts with Google, Apple, Microsoft, or Facebook anyway. Therefore, SSO is often a practical and comparatively secure option for logging in.

What should be avoided as much as possible, on the other hand, are purely visual Captchas or other tasks that must be actively solved. Such systems exclude many people.

In general, you should always offer at least two different authentication methods. Ideally, these should appeal to different senses or abilities. This significantly increases accessibility.

Another important point is error messages. Many applications today display extremely cryptic error messages. Users often do not understand at all what exactly went wrong or how they can solve the problem.

Of course, for security reasons, you cannot allow an unlimited number of login attempts. Nevertheless, you should support people as early as possible. For example, when they have forgotten their username or a password was entered incorrectly. Clear and understandable instructions are particularly important here.

Another major topic is time limits and timeouts.

Such time limits exist practically everywhere, but they are almost never visibly displayed. In any case, I cannot remember ever having seen at a bank or any other service how much time you actually have to enter the second factor.

Yet, these limits naturally exist for security reasons. What is not understandable, however, is why they are not displayed to the users.

The WCAG explicitly recommend making time limits transparent and offering an extension well before they expire.

Let's assume the time limit is 30 seconds. That can quickly become tight. Therefore, the remaining time window should be visible, and users should have the option to extend the time at least once or twice.

Delays frequently occur particularly when using assistive technologies. People sometimes need more time to read content, have texts read aloud to them, or enter codes.

Motor impairments also play a role. Perhaps it simply takes a little longer to pick up the smartphone or to switch between devices.

And this does not only affect people with disabilities. Older people often require more time as well.

However, many systems are designed for young, tech-savvy, and experienced users. This quickly leads to problems.

Setup and Recovery

Another important topic is the initial setup and the so-called recovery, meaning the restoration of access.

The initial setup is often unnecessarily complicated. Really simple and easily understandable processes are unfortunately rarely seen.

The problem is frequently that the focus is not on the user experience, but rather on legal or organizational requirements. This creates very complex procedures and long explanations that hardly anyone reads.

What is needed here, above all, is clear language and good user guidance.

The same applies to recovering an account or a device. This process should also work as simply and accessibly as possible.

Ideally, this should not require a phone call.

I recently had a case myself where an ATM swallowed my credit card. I still had access to online banking. Nevertheless, I was unable to request a new card via the web portal. It was mandatory for me to call the bank. The same partly applies if you have forgotten your PIN.

For deaf or hard-of-hearing people, this is of course a massive problem.

Conclusion

Fundamentally, there are already many established patterns for good authentication processes today. These would primarily need to be consistently improved and implemented in an accessible manner.

Important factors here are:

multiple authentication options,
sufficient time,
understandable error messages,
good support during initial setup,
and simple recovery processes.