Two brand new standards for passwordless authentication called WebAuthn and CTAP have been recently introduced.
They seek to streamline and enhance the security of login routine for websites, mobile and web applications. Both have been endorsed by Microsoft, Mozilla, and Google.
WebAuthn splashed onto the scene due to the collaboration of W3C and FIDO Alliance consortiums. The former specializes in adopting technical guidelines on the Internet, and the latter develops and improves reliable authentication standards on the Web.
The WebAuthn development process began in 2015 when FIDO submitted the FIDO 2.0 specifications to W3C consortium. The subsequent versions of the FIDO 2.0 Web API allow users to log into Google, Facebook, Dropbox, GitHub and other services by means of secret tokens.
WebAuthn generally follows the same principles as the FIDO 2.0 Web API, but it additionally supports a number of other authentication methods. The new standard allows users to authenticate with online applications and websites via their fingerprints, facial patterns, iris and other biometric parameters.
FIDO Alliance also created a new authentication protocol called CTAP (Client-to-Authenticator Protocol) that allows for identifying users by means of external security keys, such as USB security keys, or mobile devices.
These standards have already been approved by Microsoft, Apple, Google, PayPal and many other companies. It means they will shortly start being integrated in the global IT ecosystem. In particular, the W3C consortium has encouraged developers to begin implementing WebAuthn.
WebAuthn – how it works
The workflow of logging in via the new standard is as follows:
- A user visits an arbitrary website example.com with their desktop computer or laptop and sees an option that says “Log in with your phone”.
- The user selects this option and gets a browser message that goes, “Please log in on your phone”.
- A message is received on the phone saying, “Log into example.com site”.
- When the user taps this message, they see a list of accounts and select the right one.
- An authentication request appears (for instance, via fingerprint scan, PIN, etc.), and if it’s successful the personal account with the online service opens on the computer or laptop.
The login data belongs to the user, whereas it is managed by an authenticator that interacts with the service using WebAuthn via the web browser and the operating system. Special scripts generate new login data or perform authentication using the existing credentials. These scripts don’t have access to user data – instead, they simply obtain details on it in the form of objects.
The following two registration and system login methods underlie this standard: navigator.credentials.create() and navigator.credentials.get(). WebAuthn leverages them to register credentials on the server and then to verify user authenticity.
- credentials.create() creates credentials either during account registration or in a scenario where it associates a new asymmetric key pair with an existing account.
- credentials.get() uses known login credentials to perform authentication with a service.
Both methods require a secure connection HTTPS, VPNs, etc. Essentially, they get a long number string called “challenge” from the server, then sign it with the private key and submit it back. This proves to the server that the user owns the private key required for authentication. Therefore, there is no need to disclose any extra secrets on the Web.
Importantly, the user’s login credentials are linked with their unique ID. The client will submit this ID to the authenticator during every login attempt in order to ascertain that everything is taking place within the right service.
The ins and outs of the CTAP protocol
Conceptually, CTAP consists of three levels: Authenticator API, Message Encoding, and Transport-specific Binding.
At the Authenticator API abstraction level, each event is defined as an API call – it accepts input parameters and returns an output (or an error). The following methods are used here: authenticatorMakeCredential to generate new input data, authenticatorGetAssertion to verify the authentication, and authenticatorCancel to cancel all current operations.
At the level of Message Encoding, all requests to Authenticator API are constructed and encoded. The host needs to create and encode the request and then submit it to the authenticator over the selected transport protocol.
Speaking of the Transport-specific Binding level, the requests and responses are submitted to external authenticators over USB, NFC, Bluetooth, etc.
Who’s implementing the standards?
Firefox v60 and Chrome v67 releases introduced WebAuthn support. Microsoft had announced this specification in the Edge browser and Windows Hello, a built-in system for verifying the authenticity of login credentials.
Officials of these companies are sure that the adoption of the technology in web browsers will help prevent phishing, main-in-the-middle attacks (MITM) and replay attacks.
Apple hasn’t made any official statements regarding the implementation of this standard in Safari, but some of the company’s engineers are participants in the WebAuthn working group. Therefore, it’s quite likely that the adoption of the new standards by the tech giant will hit the headlines in the near future.
Michael Jones, Director of Identity Partnerships at Microsoft and one of the editors of WebAuthn, pointed out, “This is a major step towards enabling practical, strong, privacy-preserving authentication on the Web.”
From the growing quantity of data to new innovations like Artificial Intelligence (AI) and machine learning, the surveillance and security landscape is changing. The Seagate Surveillance Storage Survey 2018 is a look at what the industry challenges really are—and what businesses, security industry professionals, installers and integrators need from their storage moving forwards.
Discover the challenges now by clicking here.
The post A passwordless world? How new authentication standards work appeared first on IFSEC Global | Security and Fire News and Resources.
The following content is provided by IFSec Global, you can view the original article by visiting the IFSec Global Website