There is increased pressure to ensure a sufficient level of assurance when interacting with your users over time. User integrity is increasingly at risk from fraud and identity theft and compliance requirements are becoming more stringent. You have two major options for solving this: 1) Managing complex and costly end-to-end processes which may also hurt user experience, or 2) working with an external authentication app that integrates identity verification and continuous authentication with all the necessary security safeguards out-of-the-box. In this article, we explain why the latter is the best of these two options.
.jpg)
The Driver in the Front Seat May Not Be the Same Person Who Onboarded the Rideshare Service
Pressure on knowing your customers comes from fraudulent behaviour. Take as an example a ridesharing platform. Upon entering a vehicle, you would like to know that the driver in the front seat is actually the same driver that onboarded the service. But sometimes that is not the case, instead someone else is driving the car.
It may sound like a made up problem, but in fact, Uber and Lyft drivers in the US, UK and Australia have been revealed to share accounts on the dark web or using fake names to register new accounts, sometimes even being convicted felons**.
The identity fraud challenge is of course not exclusive to the ridesharing industry. In the beginning of 2024 we saw the so far largest data breach in history happening, "mother of all breaches", revealing the leakage of a stunning 26 billion passwords from online platforms***. Imagine the wave of password-based identity fraud that we will experience as a consequence of this.
Any service that gives customers access to high value transactions through a bank account, a gaming platform, social networks, or open up the opportunity to physically interact with other customers in last mile delivery or large international sports events would like to secure online identities so that they continuously know who their customers are.
There is an increasing compliance pressure from authorities as they try to mitigate these risks in different ways. For example, the City of London reacted with identity related regulations to the above mentioned prevalence of identity fraud in the ridesharing industry****.
The same type of regulations have also been made in for example the gaming industry, where an identity verification of new customers, together with a bank account is required among other things to validate their age and avoid money laundering in online transactions.
Thus, you will need to comply with regulations but compliance doesn’t necessarily imply that you actually know who is accessing the user account repeatedly and over time. This depends on what overall level of assurance you manage to establish with your solution. If the authentication solution is too weak, nothing prevents the wrong user from accessig the account once the identity verification for the profile has been performed.
It’s All About the Level of Assurance
The challenges outlined above implies that you, as a digital service provider, continuously and over time need a way to make sure who you are actually dealing with. The key is to secure an appropriate assurance level both for identity verification and authentication.
The assurance level refers to the level of confidence that can be placed in the identity of the user or entity, or the level of trustworthiness of the authentication systems and verification processes used to provide access to a service.
There are several international standards for identity assurance, like ISO29115, eIDAS (Europe) and NIST (USA). With respect to the need to manage the challenges discusses above, and avoid identify fraud, our assumption is that a digital service overall needs to reach at least the third level of assurance according to ISO (LOA3), or a “Substantial” assurance level according to eIDAS. We will come back to how this can be translated to NIST assurance levels, as NIST is a tool that can bring further understanding to this issue.
Distinguish Identity and Authentication Assurance Levels
Thus, we would like to achieve at least LOA3 or a Substantial level of assurance overall. The problem is that authentication and verification each can be performed at different levels of assurance. This distinction is fundamental to understand why an authenticator app is the best choice for this.
To sort this out, we can use the NIST standard, which actually distinguishes the Identity Assurance Level (IAL) from the Authentication Assurance Level (AAL).
Most businesses focus all-in on identity verification to reach IAL2 - but leave the Authentication challenge aside (stay on AAL1). One example might be performing an identity verification but using a simple password solution for login. This even though most identity frauds are targeting the authentication process. Unfortunately, this means that overall you are left on the second level of assurance (LOA2).
.jpg)
Balance the Level of Identity and Authentication Assurance
Thus, in order to reach an overall LOA3, it is not enough to have a solid identity verification process - you must also establish a sufficient assurance level in your authentication process. As an example, it is not enough to only verify a user's identity when a user first signs-up for a service - you also need an authenticator that reaches the same level of trust and makes sure that it is the same user that returns later to use the service. The figure below shows what combinations that may give you an overall LOA3.
You Don’t Want to Compromise Customer Experience
There are obvious needs to stay secure and compliant - but most businesses are afraid to risk an otherwise positive customer experience, especially in the onboarding process when users are setting up a new account. Users will (unfortunately) measure simplicity in relation to session-aware social media account login with single-sign-on or browser-facilitated password-manager driven sign-in. Whatever has to be done to reach AAL2 cannot add a significant complexity compared to that baseline.
.jpg)
The Solution lies in App-Based Digital Identities
NIST, just as other standards and regulations, are pretty clear upon what authentication methods we are left with - and by just a quick glance it is obvious that we need something referred to as a Cryptographic Software Authenticator App ideally with built-in two factor authentication (2FA), or Multi Factor Authentication (MFA).
Other options are disqualified since an authenticator must allow users to authenticate themselves in apps on their hand held device. One cannot expect users to keep anything but the mobile phone in their pocket and a one time password or one time passcode on SMS/E-Mail doesn’t qualify as an additional MFA factor, since it hardly ever fulfills the criteria of being out-of-band (OOB).
Ensure that users are in Possession of their Device
With a Cryptographic Software Authenticator, authentication is accomplished by proving possession and control of a cryptographic key managed in a FIPS 140-2 certified module. The Trusted Execution Environment (TEE) on all modern smartphones is FIPS 140-2 certified - hence the authenticator can be (and is ideally) made available through an app. The TEE typically holds a private key, and the corresponding public key is used by the device to identify itself. Proof of possession can then be achieved through signed messages.
How to ensure that no one else has taken control of the authenticator? The cryptographic software authenticator is “something you have” and access to the cryptographic key must be additionally protected with either “something you know” (memorized secret) or “something you are” (biometric data) in order to achieve MFA - hence reach AAL2.
How to ensure that the authenticator belongs to the same person as was originally onboarded? The public key of the device must be securely associated with the digital identity, either at an IdP/CSP or as an immutable credential in the “digital wallet” of the user.
Identity verification is best achieved after the authenticator is registered and inside an authenticated session. It is crucial that the identity verification process has safeguards in place to verify the integrity of the authenticator - to protect both users and services from spoofing and other fraudulent threats.
Build or Purchase?
You won't benefit from engineering this yourself! Although it likely includes facilitating third-party software and provided services - the service provider will become the asserting party of the digital identity. This covers the full responsibility of compliance including engineering and maintenance around all technological, identity data and cryptographic challenges needed to reach a sufficient level of assurance.
Further, the users need to go through yet another service-specific identity verification process and they likely need to maintain at least another service-specific memorized secret, at the expense of user experience.
The only feasible option with minimal friction to reach Substantial assurance level for digital identities on the internet is to partner up with someone who takes the full responsibility around identity proofing and authentication. Someone who can take the user through the (often quite extensive) identity proofing flow only once - and seamlessly authenticate customers towards all integrated services with a user friendly cryptographic software authenticator app.
References
*For an elaboration of verification vs authentication, see our other blog articles.
** “Uber's 'dirty little secret': Shared driver accounts,” The Wall Street Journal, 27-Nov-2019. [Online]. Available: https://www.wsj.com/articles/ubers-dirty-little-secret-shared-driver-accounts-11574883278. [Accessed: 13-Apr-2023]
*** Dhaliwal, J. (2024) 26 billion records released in ‘The mother of all breaches’, McAfee Blog. Available at: https://www.mcafee.com/blogs/internet-security/26-billion-records-released-the-mother-of-all-breaches/ (Accessed: 29 January 2024).
**** D. Kerr, “Some uber drivers aren't who you think they are,” CNET, 26-Nov-2019. [Online]. Available: https://www.cnet.com/tech/mobile/uber-drivers-using-fake-identities-isnt-just-a-london-problem/. [Accessed: 13-Apr-2023]