This technology guide from idemeum will help us first take a look at the current state of password-based authentication, and then we'll dig into various technologies that can help you go passwordless with your apps. Password-based world Digital identity is so critical to we do online, yet it gets compromised in almost every cyber security breach. Every now and then we would hear the news and learn about yet another data breach where identity compromise would be at the core of it. But not everybody is willing to accept the simple truth - . We keep using old inefficient architectures and tools that have been invented decades ago. everything we are not equipped with the proper tools to protect our identity First passwords probably arrived at the Massachusetts Institute of Technology in the when researchers at the university built a massive time-sharing computer called CTSS. The punchline is that even then, passwords didn't protect users as well as they could have. mid-1960s, Fast forward 60 years and we are still using the same that can ruin our lives and reveal everything about us. Your email. Your bank account. Your files. Your private photos. Your location. No matter how complex, no matter how unique, our passwords can no longer protect us. We constantly try to patch passwords, but we are unsuccessful. Take as an example. Despite the obvious benefits, users are still leveraging it on a selective basis due to the significant user experience friction that it introduces. "strings of characters" Multi-Factor Authentication At idemeum we believe patching passwords is no longer an option. We have to come up with simple, secure, and passwordless technology stack to handle our authentication online. How passwords survived for that long Using passwords to access online services is a commonplace experience and so are the user frustrations. Passwords have survived for that long probably due to the three major reasons: - passwords are very simple to use. Type in characters, press a button, and you are in. No additional hardware required and no compatibility issues with pretty much any service online. Simplicity - passwords are everywhere. Unfortunately, they are like - everywhere we go, we leave a password behind. The experience of using passwords is so ingrained in our digital routine that there is no need to explain anyone how to use them. It is familiar and casual. Ubiquity digital waste - when compromised passwords are easy to replace. Unlike biometrics that are immutable, we can generate as many passwords as we want. Replaceability Why passwords need to go away When one starts digging into real password experience and implications the reality becomes more disappointing. - passwords are expensive for users and developers alike. Developers pay maintenance $ for storing, hashing, encrypting, and managing password infrastructure. Users pay productivity hours given the fact that passwords cause lock-outs, need to be reset frequently, and consume time with inevitable recovery flows. Expensive - yes typing password is simple. But looking at the overall lifecycle, we first need to create one, and with more and more stringent requirements (seven uppercase letters, four special characters, etc.) it is not an easy feat. But the real dance comes when you need to remember your password out of 100s of combinations that you already have 😤. Cause friction - more than 80% of breaches are due to compromised credentials. The statistics is validating that hackers' tools are effective: , , , , and many others are always there to aid in compromising your password. Wildly insecure phishing spear phishing brute forcing rainbow tables The reality is that we are all annoyed by passwords. We've got dozens to remember, some of them annoyingly complex, and on any given day, as we read e-mails, send tweets, and order groceries online, we're bound to forget one, or at least mistype it. Moreover, we know passwords are going to compromised. That will happen sooner or later. And no one is going to enjoy it when that happens. Passwordless world Passwordless authentication (or “modern authentication,” as it is known in the industry) is the term used to describe a group of identity verification methods that don’t rely on passwords. Biometrics, security keys, certificates, and specialized mobile applications are all considered passwordless authentication methods. We will now get deeper into each passwordless technology: Certificate based authentication Magic links One-time passwords (OTPs) Hardware tokens Webauthn/FIDO2 Mobile as authenticator Before digging deep into each technology area we also recommend reading about , as it will help understand user digital identity journey holistically. our post identity lifecycle 1. Certificate based authentication Certificate based authentication allows users to securely access an application by exchanging a instead of a username and password. digital certificate To create a digital certificate, 🔐 must be used. PKI allows for what is called an asymmetric encryption. Client generates two keys: that is kept secret by its owner, and that is disseminated widely and openly. Leveraging this asymmetric key pair, PKI enables: Public Key Infrastructure (PKI) private key public key message is encrypted with a recipient's public key. For properly chosen and used algorithms, messages cannot in practice be decrypted by anyone who does not possess the matching private key. Public key encryption - - message is signed with the sender's private key and can be verified by anyone who has access to the sender's public key. This verification proves that the sender had access to the private key, and therefore is very likely to be the person associated with the public key. This also ensures that the message has not been tampered with, as a signature is mathematically bound to the message it originally was made from, and verification will fail for practically any other message, no matter how similar to the original message. Digital signatures Client can then create a digital certificate that will conform to . X509 certificate will have to identify the owner, including , , and others. The key here is that digital certificate needs be by some trusted 3rd party, so that this certificate can be trusted to represent identity of the owner. X.509 standard various fields public key subject name validity period signed In order to use digital certificate to authenticate to a target application, client will need to share a X.509 digital certificate with the application along with the . Proof of possession will be represented by a nonce signed by a private key. When application receives the digital certificate, it can extract the user information from that certificate, and then will verify proof of possession to make sure that the requestor actually owns the private key. proof of possession Certificate based authentication is very popular in enterprise space due to the fact that most employee devices are managed with , and it is convenient and easy to provision certificates to client devices. MDM However, certificate based authentication is not as prevalent in consumer and developer space, as it is quite complex to install and manage X.509 certificates on unmanaged user devices. Some vendors try to create mobile and desktop applications that aim to simplify certificate provisioning and management, but the user experience will still be complex for ordinary users. 2. Magic links With magic links an application sends a unique URL link to user's email address or mobile phone via SMS. There is no need to enter any credentials. Instead, the user clicks on the magic link to authenticate. Since the magic link includes unique one-time authentication token, the user is logged in and redirected to an application landing page. Magic links enable great frictionless experience for the users as there are no credentials to remember and very few steps to perform. However, we believe that to provide best possible experience magic links need to be combined with cross app , so that when the users verify their email with magic link they can maintain the session and seamlessly login across applications. Single Sign-On 3. One-time passwords (OTPs) OTPs are heavily used in multi-factor authentication flows, but one-time passwords or one-time codes can also be used as a standalone authentication method. OTPs are . time-bound numeric codes linked to a reference One-time passwords function via random algorithms that create a new and random code each time access is requested. These codes are sent to a user upon providing a reference (email address or phone number). When the user enters the code back to a target application, the user is authenticated. As soon as the OTP enables access to the account, its validity comes to an end. Since an OTP (a four or six-digit numerical PIN code in most instances) can be entered just once, it’s not as risky as static passwords that can be used multiple times. The biggest advantage offered by OTPs in contrast to standalone passwords is that they’re safe from replay attacks. In plain language, an adversary who uses trickery to capture your OTP can’t reapply it, since it’s no longer valid for future logins or sessions. 4. Hardware tokens A hardware security token is a physical device that validates user’s identity and grants access to the target application or resource. The user must possess this token to complete the authentication process. Hardware tokens can be used as a primary authentication method, or used in combination with other authentication factors such as username and password. Hardware tokens come in many forms, most commonly as USB tokens, key fobs, and wireless Bluetooth tokens. Also, there are three main types of hardware tokens. - a user must plug the security token into the system, computer, cardholder, etc. to complete the verification. Two examples of this type of token includes a USB token and a , the latter of which requires the use of a CAC reader. Connected tokens Common Access Card (CAC) - these are the small devices that look like a sim card, keychain fob, or USB flash drive. These tokens generate a unique and temporary cryptographic code that must be input by the user to gain access to a computer resource. Disconnected tokens - with contactless tokens, you don’t need to connect to a device or enter any access codes. Instead, contactless devices connect with the system wirelessly. Based on the connection’s credentials, the system either grants or denies access. The most noteworthy examples of contactless tokens are Bluetooth tokens. Contactless tokens 5. Webauthn / FIDO2 The Web Authentication API (also known as WebAuthn) is a written by the and , with the participation of Google, Mozilla, Microsoft, Yubico, and others. The API allows servers to register and authenticate users using public key cryptography instead of a password. specification W3C FIDO WebAuthn is part of the , which is a set of technologies that enable passwordless authentication between servers, browsers, and authenticators. Today WebAuthn is supported by major browsers, including Chrome, Firefox, Edge, and Safari. FIDO2 framework Webauthn allows applications to integrate with strong biometric authenticators built into end user devices, like Windows Hello or Apple’s Touch ID. Instead of a password, a private-public key-pair (known as a ) is created for a website. The private key is stored securely on the user’s device; a public key and randomly generated credential ID is sent to the server for storage. The server can then use that public key to prove the user’s identity. credential Let's first look at the major components required to enable passwordless authentication with Webauthn. common and public API implemented by all major browsers that provide a mechanism to interact with FIDO based authenticators. This API defines registration, meaning enrollment of a credential, and authentication methods. Webauthn API - - FIDO2 implementation in the application's backend. FIDO2 server calls browser based Webauthn API in order to communicate with the platform or roaming authenticator. FIDO2 server - Client to Authenticator Protocol. CTAP defines how the FIDO client running on a specific platform, e.g. an operating system or a web browser, can talk to an external authenticator such as a USB-powered security key or a mobile phone that can interact with the computer via NFC or Bluetooth. CTAP - hardware based authenticator (USB device or built-in biometric sensor) that protects that user private key with which the authentication is performed. FIDO authenticator Here is the high level flow to show how Webauthn authentication is performed on the web. Webauthn registration: First a user proves his identity with some other means, such as proving ownership of an email (using magic link), or uploading ID document for online identity proofing. FIDO2 server starts the process by calling Webauthn browser API with the registration request. registration Webauthn API communicates with FIDO authenticator over CTAP to create scoped credentials for the user. Private key will be stored with authenticator and public key will be passed to the application backend. Response to the FIDO2 backend server will include various attributes including , , and . public key attestation client data Application backend will store the public key and associate it with the identity of the user. Webauthn authentication: User requests access to the application. FIDO2 communicates with the Webauthn API using method and passing the authentication challenge. authentication Webauthn API passes the request to authenticate and challenge to FIDO authenticator using CTAP protocol. User is prompted to use biometrics to unlock access to authenticator private key. Upon success, challenge is signed with the user private key by FIDO2 authenticator and is passed back to application backend. Application validates the signed challenge with the user public key and grants access to the user. Webauthn is the modern authentication protocol that is currently undergoing broader adoption across website and browsers. It offers strong passwordless authentication for the users, however as you can see it is not solving enrollment / registration step. To provide complete frictionless experience to users Webauthn needs to be paired with other tools such as magic link or online identity proofing to address user enrollment. You can try Webauthn demo . here 6. Mobile as authenticator The last passwordless method we wanted to cover is using your mobile phone as an authenticator. It is also called as it combines multiple authentication factors together: Passwordless MFA - you mobile phone and certificate that resides on your mobile device. Something you have - mobile device biometric sensor, such as Face ID or Touch ID. Something you are There are various implementations that we have seen in the industry, but we believe that the best and most secure implementation should be leveraging and on a mobile device. Meaning that authentication shall be driven by FIDO protocol, and both iOS and Android support FIDO today. And the FIDO private keys need to be protected by HSM modules on mobile devices (Secure Enclave on iOS or TEE / StrongBox on Android). FIDO Hardware Backed Security The most typical authentication flow is to install and leverage a mobile app that will handle authentication. User requests access to an application. QR-code is displayed instead of asking user for any input. There are various possibilities here - for instance asking for email and then sending push notification, but we find QR-code providing the most seamless experience. User scans the QR code with mobile app. Application triggers FIDO based authentication. User authenticates with a biometric sensor on a mobile device. The application verifies the authentication response according to FIDO spec and grants access to the user. Final thoughts When we talk about Passwordless Authentication we immediately think and focus on only. However, we need to think about user digital identity journey holistically - how will users enroll into our identity system, how will we authenticate them strongly yet providing great experience, and how will we let users manage and maintain their digital identity. authentication At we believe that at this day and age there are 3 major requirements for implementing a for a modern application: idemeum successful login system - no more passwords, no more compromises, no more frustrated users who are overwhelmed with account creation. It needs to be passwordless - users need to login once and be able to access any application they want without any boundaries. No one wants to verify his email or enroll a new FIDO key with every new application sign up. It needs to offer Single Sign-On - privacy is becoming ever more important in our digital world. Digital identity is critical and it needs to be owned and controlled by users, and not monetized by 3rd party companies. It needs to guarantee privacy At idemeum we build All-in-One Passwordless Identity Platform. We are happy to help you solve your sign up and login challenges. Also published here .

Flow

Apple

Google

Microsoft

Mozilla

Routine

Target

How to Go Passwordless with idemeum JavaScript SDK

Go passwordless with idemeum!

Too Long; Didn't Read

CTA: Download the FREE AI Productivity Shift report

Solid Benefits of Authentication Without Passwords: Passwordless Identity Platforms Simply Explained

Solid Benefits of Authentication Without Passwords: Passwordless Identity Platforms Simply Explained

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How to Go Passwordless with idemeum JavaScript SDK

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

10 Tips for developers

10 Things Every New Developer Should Know

10 Tax Tips for Freelance Developers and Startups

How to Go Passwordless with idemeum JavaScript SDK

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

10 Tips for developers

10 Things Every New Developer Should Know

10 Tax Tips for Freelance Developers and Startups

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps