September 27, 2018 | Written by: shane.weeden
Categorized: Cloud Identity | General Technical | ISAM
Share this post:
I was fortunate to recently find myself amongst the first round of server vendor participants to take a product through FIDO2 certification, and that’s what today’s article is really all about. IBM’s authentication platforms, which include both on-premise (ISAM) and cloud-based (IBM Cloud Identity) offerings, are the perfect vehicle to bring this new era of strong authentication technologies to your business. Expect to see this technology appear in our commercial offerings soon. My advice – start learning about it now! In this article I will outline some of the history of web authentication – the journey that got us here, and demonstrate scenarios that are now possible with the FIDO2 and WebAuthn standards.
Anyone in the IT security game knows that password authentication is out of flavour. It’s almost a taboo subject. The reasons are simple – passwords represent copiable, easily remembered and almost always re-used keys to our increasingly critical digital kingdoms, both personal and professional.
The problem is amplified because of the nature of people and the human brain. People compete with (i.e. actively try to circumvent) the arcane policies dictated mostly by security “experts” in their places of employment, such as:
- make your password complex and include non-alphanumerics (who doesn’t use one of ‘!’, ‘@’ or ‘#’ which are the most convenient first three punctuation chars above a US-keyboard?)
- make them long (ok that’s easy)
- expire them (just another dumb idea – people just increment the numeric part of their password or switch between well-known patterns until they break the authentication system’s “not like the last few” rules)
- don’t re-use them (I love this one, it’s completely un-enforceable across disconnected authentication systems)
- have a minimum expiry period (I love this one too, it’s designed to stop people from iterating through password changes till they get back to the one they started with. It’s also easily circumvented by a forgot-password reset flow in most cases)
Get the idea yet? Passwords are bad because people are required to remember them, or write them down, or use a digital password manager (which almost always doesn’t port across all the platforms and devices you use and has risks, and a password, of it’s own). The policies are ineffective because people are continually just finding ways to work around them for their own convenience.
Second-factor and alternative-to-password authentication options
Enough of this rant – what is the world doing about it? Well, that is part of my job. For several years many of us in the IT security industry have been working on and delivering 2nd-factor and strong authentication solutions for digital systems of human engagement, including web and mobile. These were initially mostly second-factor systems (think SMS OTP, email OTP, TOTP, FIDO U2F). The reason they are 2nd-factor systems is that you first need to be aware of who the user claims to be, with some basic level of assurance such as their password, so that you can lookup their phone number, email address, TOTP secret, registered public key credential, etc to initiate the strong-authentication portion of the login process. This works fairly well, but still has a password to get things under way which is a little inconvenient for the user.
Enter the world of alternative-to-password first-factor authentication. Some environments have been capable of doing this for years – one example is the PIV/CAC cards used in the US federal space. In their traditional physical form these work well but require bespoke hardware to use and have costly provisioning and lifecycle management processes.
The mobile platform has afforded new opportunities for alternative-to-password authentication too, and I have blogged about one that we have done at IBM already: Password-less login with IBM Verify. Ultimately this relies on the user implementing reasonable user-to-device security controls as well as maintaining physical possession of their phone.
And it’s real.
Let’s take a look at an example use case that is now possible, and explore the components involved.
A retail bank today offers internet banking via a browser-based web application. The existing user authentication experience is:
- Login with a username and password, then
- Receive an OTP via SMS on their registered mobile phone for 2nd factor
- Enter this OTP on the web page, and then you are logged into the internet banking application.
In the new model, the retail bank allows the user to register any compliant FIDO2 resident key authenticator. This registration occurs one-time under the context of a legacy authentication, or as part of initial account establishment (meaning the user never had or will ever have a password for their account). The new user authentication experience on opening their browser at the banking site is:
- See a prompt to authenticate with a previously-registered FIDO2 authenticator.
- Perform a user-verification action or gesture (this step varies based on authenticator capabilities) and you are logged in.
That’s a lot better. In the rest of the article I’ll take you through a shallow dive of the components involved in this type of architecture, and provide some advice for getting started.
FIDO2 Technology Components
I thought it might be useful to seed your own educational journey with my own high-level description of the components involved in a WebAuthn+FIDO2 authentication scenario such as the one mentioned above.
Authenticators are essentially user-owned devices or components that use asymmetric key technology to prove possession of a private key by signing server-generated challenges. There’s more to it than that (such as ensuring that different key pairs are generated for privacy reasons during every registration), but that’s good enough for a high-level understanding.
At registration time, the server sends a generated random challenge, via the browser, to the authenticator. The server actually also tells the authenticator who is registering. This is a key difference between FIDO2 resident keys and FIDO U2F second factor. The authenticator responds with both the signed challenge and the public key able to validate the signature (and other information used for attestation described later). The public key is registered against the user’s account at the server. On subsequent authentication flows, the server send a newly generated challenge to the authenticator, and validates the returned signature using the same public key previously registered for the user.
Authenticators are loosely grouped into two categories – platform authenticators, and portable authenticators.
Platform authenticators are, as the name suggests, those that are somewhat built-in to the operating system platform where the browser is running. Examples that I have used at the time of writing this article include Microsoft Edge with Windows Hello, Chrome+TouchID on a Mac, and Chrome on an Android phone using the existing user-to-device security set up by the user (swipe pattern, fingerprint, device pin, etc).
Portable authenticators include security keys in form factors that communicate with the browser via USB, BLE (Bluetooth Low Energy) or NFC. Some include fingerprint readers for user verification. Others do user verification via only a simple PIN. Some even have small screens to display information to the user during the authentication process. I’ve even seen and used wearables that have FIDO2 strong authentication capabilities built in.
Either way, the user can (with privacy and safety in mind) register and then later authenticate using one of these user-verifying authenticators at any site that supports WebAuthn. The authenticator is either part of your device, or in the case of a portable authenticator typically cheap enough that the bank might give them away as a promotion, or the user’s may just buy them standalone. For backup and redundancy, a user should be encouraged to register multiple such authenticators against their account, perhaps the built-in platform authenticator on their laptop, plus a portable authenticator they keep in a safe place in the event of laptop loss or failure. The authenticator may be used solely for 2nd-factor authentication scenarios, however I think the high-value experience is when the authenticator is used as part of a completely alternative-to-password strategy. This latter scenario requires use of authenticators that support a FIDO2 concept called Resident Key Credentials. All of the platform authenticators I have seen support this, and most new FIDO2 portable authenticators do too. A few do not, and U2F-only authenticators do not, so watch out for this if you want alternative-to-password authentication and are looking at what authenticators to use.
Servers and Attestation
Servers, including IBM’s access management products, need embedded technology to understand the FIDO2 messages and the WebAuthn APIs and manage the lifecycle of public key registrations for users’ accounts. To be flexible in the commercial sense, they also need policy engines that can be configured by administrators to decide if certain brands or types of authenticators are even acceptable for use at this site or for specific step-up authentication scenarios.
This process of vetting the authenticator characteristics is called attestation. In traditional client certificate authentication to a website, administrators whitelist CA certificates in a trust store and use PKIX chain validation including OCSP or CRL’s for revocation. This is attestation – making a determination about trust. It is no different than the physical attestation that occurs in transactions people do in everyday life. When you buy a house or other high-value item, you make sure that the seller is really the current owner, is entitled to sell you the item (doesn’t have outstanding mortgages), and that it is guaranteed to be free from contamination or other de-valuing defects. That is also attestation.
In the FIDO2 authentication landscape, there will be high security scenarios for which it is essential that security administrators consider the merits of different authenticator vendors and decide what authenticators are permitted for use at a site, or under particular transactional circumstances. There is an entire process to consider around attestation and the FIDO2 ecosystem provides mechanisms (called metadata) for doing just this.
Make sure that attestation capabilities and authentication and authorization policy engine integration are a key part of your evaluation process when looking at servers.
If you are interested in reading more about the pro’s and con’s of attestation, I do recommend these articles which I found very informative, and discuss it in much more detail:
Take action – read more, and go try it out
I am a firm believer that this technology and the subsequent fast, fun and safe user authentication experience that it offers is a vital part of a larger multi-modal set of alternative-to-password authentication strategies that our customers should consider. WebAuthn and FIDO2 authentication aligns well with IBM’s access management strategy for both on-premise and cloud adoption patterns.
If you would like to start experimenting with the capabilities from the end-user perspective today, we have a demonstration playground where you can give it a go:
Also take a look at the FIDO announcement for a list of conforming authenticator vendors, or reach out to your IBM technical sales representative who can put you in touch with me or one of the other folks here at IBM and we will be happy to show you how to get started.