Minimizing User Burden in Authentication

Minimizing User Burden in Authentication

Rolf Lindemann, May 6th 2022

Have you ever been frustrated to spend minutes trying to find a password that you couldn’t remember?  Or seeing an online payment you made declined even though it should have been approved? You are not alone.  Many online applications put a significant “burden” on the user to use them.

Psychologists came up with the term “cognitive load” [1] to describe the mental effort to learn new information.  In the field of user experience, the Nielsen Group defines cognitive load imposed by a user interface as “the amount of mental resources that is required to operate the system” [2].  A newer and broader concept is called “User Burden” [13].  Multiple user burdens are being distinguished – the mental user burden is similar to the cognitive load.  So the frustrations mentioned above are frustrations about systems that put more burden on us than we expected or even are willing to accept.  You can see many examples indicating the relevance of cognitive load/user burden in this article [18].

Authentication is the front-door to digital services.  So let’s look into the user burden of online authentication but more importantly what organizations can do to fix the dysfunction.

  1. Passwords

Complexity rules When using passwords, the user needs to know and understand the complexity rules imposed by the service when providing a new password.  This is especially painful when those rules are not stated upfront, but only appear in an error message.

Different passwords For security reasons, passwords shouldn’t be re-used [3]. That means the user needs a scalable way to generate new and different passwords for various sites. 

Memorizing passwords Since the password is needed frequently, we need to memorize them all.  Either in our brain or written down somewhere.  Approx. 20% of users utilize password managers [4] for that scenario leaving 80% to either struggle with memory or find a safe place to write them down.

Enter or not to enter Whenever the user wants to sign-in, the correct password needs to be entered into the legitimate application.  The wrong one doesn’t work and might even put the security of the password at risk.  This is even more complex as the user cannot verify which entity rendered the password entry dialog.  The high number of successful phishing attacks confirms that.  Typical attack vectors are homograph attacks [5], confusion on interpreting the base URL [6] or even Browser In the Browser (BITB) Attacks [7].

  1. One-Time Passcodes (OTPs)

Context switch When using OTPs, the user needs to switch from the application context to the context of the OTP token or the SMS app on the phone to find the OTP, memorize it and type it into the application.

Enter or not to enter For OTPs, this is the same challenge and user burden as it is for passwords (see above).

  1. App-based authentication

I just switched to a new smartphone and had to move all my banking apps.  This clearly showed another layer of user burden: Many European banks (I live in Germany) encourage (or even enforce) customers to use a dedicated Authenticator App or the Mobile Banking App as a possession factor for authenticating to the bank account.  

The process of “bootstrapping” the apps on the new phone created a significant user burden. The details are too immense for this article, but for one bank account I have 4 different PINs or “Keys” to memorize and I needed to reset one that I have forgotten over the years.  For another bank, bootstrapping the authentication functionality in the banking app required me to wait for a paper letter that the bank sent me – while bootstrapping the dedicated Authenticator App worked through my old smartphone.  Why have the two Apps from the same bank been implemented so differently?  If you want some fun (and you happen to understand the German language), listen to this [8].

  1. Recent progress – A Better Approach

There are modern authentication methods [9] [10] that reduce the user burden on many levels.

There is no need to think about Complexity rules as the password can either be avoided completely (i.e. being replaced by biometrics or a single authenticator specific PIN), or at least the reliance on the password is significantly reduced so that complexity requirements can be lowered. This is accomplished by leveraging the authenticators as a strong and phishing-resistant possession factor.

Another advantage is that an additional user burden was moved from the user to the machine: The platform automatically decides which credential is to be used – obviating the need for the user to decide whether to Enter or not to enter a specific credential for a given app.  This is a huge relief for users and a big security win for the specific relying party providing the online application and a big win for the cybersecurity in general.

Additionally, there is no need for a Context switch as there is nothing to read on another device and to reproduce in the application we are in.  The user interaction is now limited to the main application and the authenticator that is being used (platform authenticator, Security Key or phone as security key [20]).  Note that in the case of “phone as security key”, no additional app needs to be installed on the phone.

This modern authentication method also allows you to entirely obviate the need for a password.  In that case, there is also no need for Different passwords for each account – a single biometric or a single authenticator PIN are sufficient.  The same applies to Memorizing passwords, that is no longer required and helps us to free up our brain for more important things.

This modern method is already being used today by hundreds of millions of (financial and mobile network) users [11] – reducing the user burden that is required for sign-in to online services.

  1. Upcoming improvements

As mentioned above, I recently switched smartphones.  A tool helped me to get all apps that I had installed on my old phone to the new one.  On the new phone I bootstrapped my platform account (e.g. Google account, Apple ID, Microsoft account), but then I had to re-enter my username and password for each app and online web account separately – and I have more than the average of 100 accounts [17].  Sure enough I forgot one account and needed to find the password when I urgently wanted to use the account – not a pleasant experience.  

Wouldn’t it be great if a device could tell the server that I already bootstrapped my platform account on the new device (of course not disclosing my platform account details)?  Many online services might take that as a sufficiently strong signal that I am now using the new device.  Other online services might want to trigger an additional authentication performed by the old device – but hopefully not sending paper letters.   

The new concept of Multi-Device credentials [12] (also called “Passkeys”) addresses exactly this user burden and shifts it to the machine.  As a result, strong possession factors will just work on all of your smartphones, tablets and laptops (as long as they belong to the same device family and support this technology) – without requiring the user to initiate any explicit “bootstrapping” process (beyond taking ownership of the device).

What service providers could do about it

If you are working for an organization that requires users to use passwords, OTPs or App based Authentication to sign-in, you should consider reducing your customers’ user burden by introducing modern authentication technologies.  Some of the real world benefits are described in [19].

With the modern authentication methods described in [9] and [10], you can already reduce the burden of your users today and you will be able to reduce it even more when platforms start supporting the upcoming improvements [12] in the near future.


Translate »