Building on Passwordless Experience, extending FIDO2 support as Primary Authentication
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Printer Friendly Page
- Report Inappropriate Content
No one likes passwords, and they are the weakest link in the security chain. End users have way too many passwords to manage and they are impossible to remember— especially when you are required to change them every few weeks. 80% of breaches still involve compromised and weak credentials1. Passwords are expensive for administrators and help desk, as difficult passwords get forgotten frequently and results in higher administrative and help desk costs. In 2018, security breaches costed companies an average of $3.86 million per breach². For CISOs, they are the leading cause of breach-related nightmares. End users and administrators can easily fall into the trap of phishing attacks, resulting in access to systems or database breaches and exposing critical customer and organizational information to adversaries.
Passwordless is not new to RSA
Do you know that RSA has been providing passwordless experience to our customers? Yes, for last 35 years our customers have been using RSA SecurID Tokens for securing their VPN, firewall, Unix servers and much more without requiring passwords -- a passwordless experience. Building on this, now end users can also use FIDO2 authenticators for passwordless authentication experience when accessing Web/SaaS applications (acting as SAML Service Provider) and using RSA Cloud Authentication Service as Identity Provider (IdP).
FIDO as a strong authentication method
For starters, the FIDO protocol, part of FIDO Alliance, uses standard asymmetric cryptographic techniques to provide stronger authentication which offers a much better phishing resistant alternative to passwords. During the FIDO device registration process, a user’s device creates a public/private key pair and registers its public key with the online FIDO service. Authentication is done by the client device proving possession of the private key to the service by signing a challenge sent by the service. In FIDO2, the client’s private key can be used only after the user unlocks the FIDO device using secure action such as PIN or Bio-metrics. Many of the Hardware FIDO2 authenticator vendors offer tokens that can be setup to use PIN or have a built-in fingerprint reader on the device to secure the private key. Many of the Software FIDO2 Authenticators built into platforms (e.g. Google’s Android 7+ mobile platform or Microsoft Windows 10 1903 patch) can also secure the token using Face Id (or other methods) for user verification, if supported by the device they are running on.
If you are wondering how FIDO2 is considered a strong authenticator and a better phishing resistant alternative, reason is that it supports MFA by providing two of the three authentication factors required to meet NIST 800-63-3 AAL2 security requirements – Know something (PIN) OR Are something (Biometrics) AND Have something (asymmetric cryptography based FIDO2 Token).
FIDO Token enrollment and self-service at scale
While FIDO2 protocol requires need for user verification and uses asymmetric cryptography for strong authentication, it does not talk much about life cycle management of the FIDO token itself from end user’s point of view and leaves it to the security vendors offering FIDO2 as an authentication service. RSA strongly believes that using FIDO at scale within the enterprise requires far more than just adopting a new authentication protocol. Managing the entire lifecycle of FIDO tokens at scale plays an important role in the success of its adoption within an enterprise. As an example, it requires making the enrollment process of these devices convenient by offering secure self-service capabilities at scale and also support device replacement in case current device is lost. These are some of the key FIDO token life cycle management aspects which cannot be ignored and need to be taken care at scale within an enterprise.
RSA SecurID Access and FIDO Support
RSA is a board member of the FIDO Alliance and has been driving the enterprise security workstream. RSA SecurID Access has been supporting FIDO devices for many years as an additional authentication method, and now we are extending that support to use FIDO2 authenticators as a primary authentication (2FA/MFA) method replacing password to access SaaS or Web Applications (service providers).
As part of RSA SecurID Access, both FIDO and FIDO2 devices can be managed using the enterprise grade RSA self-service portal My Page. In case users lose their FIDO devices, they can go to My Page and delete the existing device and register a new FIDO device. If these FIDO authenticators are used as step-up authentication, they can also be registered in-line during step-up authentication flow itself.
Let us discuss below the end-user experience of using FIDO2 Token to securely access SaaS/Web applications followed by administrative workflow of managing the FIDO2 authenticator using RSA SecurID Access.
End-User experience using FIDO2 Token
Enterprises are looking to provide friction less user experience to their modern work force who needs to access business applications from anywhere and anytime. Passwords being prone to phishing attacks and hard to manage, customers can now offer FIDO2 Tokens to their end users to gain access to business-critical applications. Now users accessing SaaS Business Applications like (Salesforce) can use FIDO2 Token to securely authenticate and get access these applications without requiring password.
Click on this demo to see how RSA SecurID Access allows a user (a sales person in this example) to use FIDO2 Token to authenticate their identity and get access to their Salesforce account after validation.
Demo 1: Passwordless Authentication using FIDO2 Token
Understand the steps involved in authenticating using FIDO2 Token
Let us briefly talk about the authentication flow using FIDO2 Token shown in the demo. In this use case Administrator has configured a service provider (e.g. Salesforce) to require FIDO2 Token for passwordless authentication and end-user already has a registered a FIDO2 Token to use.
- User tries to access Salesforce (SP) and chooses RSA SecurID Access as an Identity Provider (IdP) to authenticate. User is redirected to IdP (CAS). SP and IdP are communicating over SAML.
- User enters their email address and CAS checks the access policy for this user and finds that FIDO2 Token is required as primary authentication method.
- CAS challenges the user to authenticate using FIDO2 Token. User presents FIDO2 Token to authenticate and uses PIN or Biometric for user verification. Note that this is a passwordless authentication flow.
- CAS (FIDO Servers) authenticates the user and communicates to SP using SAML about the successful auth.
- SP (Salesforce) allows user to access their account after successful authentication.
End-User experience enrolling FIDO token at scale
1. RSA SecurID Access self-service portal, My Page, to manage FIDO Token
Users can register their FIDO Tokens by using, self-service portal, My Page. This portal also allows users to manage their registered mobile devices along with FIDO tokens. Users can delete an existing mobile devices or FIDO Tokens and re-register new ones in case they lose their current devices using this self-service portal.
Demo 2: Registering FIDO Token using My Page
2. In-line registration of FIDO Token as part of Authentication work flow
In the case where FIDO authenticators are used for additional authentication (not the primary or first factor), new tokens can be registered during the authentication work flow itself. This is not allowed if the FIDO2 token is used for primary authentication. The user must first register it using My Page, as mentioned above.
Admin experience enabling FIDO2 Token Authentication for Service Providers
First, an administrator configures a service provider (SaaS or Web application like Salesforce) in the Cloud Administration console and chooses the authentication option RSA SecurID Access manages all authentication and FIDO Token as primary authentication.
With the above steps, an administrator is configuring the service provider to require FIDO Token for primary authentication, without requiring any password. As mentioned earlier, this has to be a FIDO2 Token as it supports user verification. Optionally, an admin can configure additional authentication methods for higher security, if needed. Also, policy-driven conditional attributes and identity assurance in RSA SecurID Access can be added as part of further securing access to service providers.
Admin experience setting up self-service portal, My Page
Administrators, through the Cloud Administration Console, can control if users are allowed to manage their mobile devices or FIDO tokens using My Page. This is where they enable self-service portal for users and manage their mobile devices and FIDO Tokens. Administrators can achieve a higher assurance level by creating a custom access policy using MFA so that users can securely access My page. Optionally, conditional attributes and identity assurance can be added as part of securing My Page for FIDO Token registration
In case My Page is enabled for users to manager FIDO Tokens, inline registration will be disabled automatically
FIDO2 is a great step forward, enabling passwordless access to business-critical resources and mitigating phishing attacks. RSA is proud to be leading this effort and helping our customers take passwordless journey for on-prem applications as well as SaaS applications and enabling secure and convenient life cycle management of FIDO Tokens.
1 Verizon Data Breach Investigations Report (DBIR)
2 2018 Cost of Data Breach Study, Ponemon Institute Research Report
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.