You soon may not need to remember those passwords to log in to the likes of Facebook
The traditional password that you use to authenticate with an online service is in the throes of losing this role.
This is coming about due to a lot of security risks associated with server-based passwords. One of these is for us to use the same password across many online services, leading towards credential reuse and “stuffing” attacks involving “known” username/password or email/password pairs. As well, the password is also subject to brute-force attacks including dictionary attacks where multiple passwords are tried against the same account. It also includes phishing and social-engineering attacks where end-users are tricked in to supplying their passwords to miscreants, something I had to rectify when an email account belonging to a friend of mine fell victim to phishing. This is facilitated by users creating passwords based on personal facts that work as aide-memoires. Passwords can also be stolen through the use of keyloggers or compromised network setups.
Managing multiple passwords can become a very user-unfriendly experience with people ending up using password-vault software or recording their passwords on a paper ore electronic document. As well, some applications can make password entry very difficult. Examples of these include connected-TV or games-console applications where you pick each character out using your remote control’s or game controller’s D-pad to enter the password.
You will be able to set your computer up to log you in to your online services with a PIN, fingerprint or other method
The new direction is to implement passwordless authentication where a client device or another device performs the authentication role itself and sends an encrypted token to the server. This token is then used to grant access to the account or facilitate the transaction.
It may be similar to multifactor authentication where you do something like enable a mobile authenticator app after you key in your online service’s password. But it also is very similar to how a single-sign-on or social-sign-on arrangement works with the emphasis on an authenticated-session token rather than your username and password as credentials.
The PIN will be authenticated locally nd used to enable the creation of a session token for your online service
There will be two key approaches which are centred around the exchange of an asymmetric key pair between the client and server devices.
The first of these will be the primary client device like your laptop computer or a smartphone that you are using the online service on. Or it can be a secondary client device like your smartphone that is holding the private key. You authenticate with that device using a device-local PIN or password or a biometric factor like your fingerprint or face.
The same holds true for your Android or other smartphone
The second will involve the use of a hardware token like a FIDO2-compliant USB or Bluetooth access key or an NFC-compliant smart card. Here, you activate this key to pass on the credentials including the private key to the client computer for your online session.
It is being facilitated through the use of FIDO2, WebAuthN and CTAP standards that allow compliant Web browsers and online services to implement advanced authentication methods. At the moment, Windows 10 is facilitating this kind of login through the use of the Windows Hello user-authentication functionality, but Android is in the process of implementing it in the mobile context.
There is effectively the use of a form of multifactor authentication to enable the cryptographic key pair between the client and server devices. This is based around the device you are using and the fact you are there to log in.
The fingerprint reader on this HP Elitebook and similar laptops will become more important here
If the authentication is to take place on the primary client device like a laptop or smartphone, the device’s secure element like a TPM module in a laptop or the SIM card in a smartphone would be involved in creating the private key. The user would enter the device-local PIN or use the fingerprint reader to enable this key which creates the necessary session token peculiar to that device.
On the other hand, if it is to take place on a secondary device like a smartphone, the authentication and session-token generation occurs on that device. This is typically with the user notified to continue the authentication on the secondary device, which continues the workflow on its user interface. Typically this will use a Bluetooth link with the primary device or a synchronous Internet link with the online service.
The online service has no knowledge of these device-local authentication factors, which makes them less likely to be compromised. For most users, this could be the same PIN or biometric factor used to unlock the device when they switch it on and they could use the same PIN across multiple devices like their smartphone or laptop. But the physical device in combination with the PIN, fingerprint or facial recognition of that user would be both the factors required to enable that device’s keypair and create the session token to validate the session.
A hardware token can be in the form of a USB or Bluetooth security key or a NFC smart card. But this device manages the authentication routines and has private keys kept in its secure storage.
There will be the emphasis around multiple trusted devices for each service account as well as the same trusted device supporting multiple services. Some devices like hardware tokens will have the ability to be “roaming” devices in order to do things like enabling a new device to have access to your online services or allow ad-hoc use of your services on shared equipment such as the public-use computers installed at your local library. They will also work as a complementary path of verification if your client device such as a desktop PC doesn’t have all the authentication functionality.
Similarly, when you create a new account with an online service, you will be given the option to “bind” your account with your computer or smartphone. Those of us who run online services that implement legacy-based sign-in but are enabled for passwordless operation will have the option in the account-management dashboard to bind the account with whatever we use to authenticate it with and have it as a “preferred” authentication path.
Some of the passwordless authentication setups will allow use with older operating systems and browsers not supporting the new authentication standards by using time-limited or one-use passwords created by the authentication setup.
Questions that will arise regarding the new passwordless Web direction is how email and similar client-server setups that implement native clients will authenticate their sessions. Here, they may have to evolve towards having the various protocols that they work with move towards key-pair-driven session tokens associated with the particular service accounts and client devices.
There will also be the issue of implementing this technology in to dedicated-purpose devices, whether as a server or client device. Here, it is about securing access to the management dashboards that these devices offer, which has become a strong security issue thanks to attacks on routers and similar devices.
IT WILL TAKE TIME TO EVOLVE TO PASSWORDLESS
