Overcoming the UX Challenges Faced by FIDO Credentials in the Faced by FIDO Credentials in the Consumer Space
Many websites are vulnerable to phishing attacks due to traditional authentication methods. To address this, the utilization of cryptographic authentication, such as key pairs, is recommended to enhance security and prevent MITM attacks.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Overcoming the UX Challenges Overcoming the UX Challenges Faced by FIDO Credentials in the Faced by FIDO Credentials in the Consumer Space Consumer Space Presented at HCI International 2023 on July 24, 2023 Francisco Corella fcorella@pomcor.com
Today, most web sites are still vulnerable to Today, most web sites are still vulnerable to phishing attacks phishing attacks 1. Most users still authenticate with username and password, which can be phished 2. MFA using an authentication code is vulnerable to a man-in-the- middle (MITM) phishing attack, because the attacker can relay the username, the password and the authentication code to the legitimate site and capture the session cookie that the legitimate site sends to the victim's browser
Surprise? Surprise? It may come as a surprise to users who are asked to use MFA, but it is not a surprise for IAM professionals In 2017, the Evilginx attack tool showed how easy it is to mount a MITM phishing attack, and people started paying attention Today, there is consensus that traditional MFA is not secure enough and something else should be used instead
There is also consensus on what to use instead: There is also consensus on what to use instead: cryptographic authentication using a key pair cryptographic authentication using a key pair A very simple protocol: 1. At registration: a. The JavaScript frontend of the web site creates a key pair and registers the public key with the backend 2. To authenticate: a. The backend sends a challenge b. The frontend signs the challenge with the private key and sends the signature c. The backend verifies the signature using the public key
Does this prevent a MITM attack? Does this prevent a MITM attack? Why doesn't this MITM attack work? 1. The victim sends a login request to the attacker's site, mistaking it for the web site 2. The attacker relays the login request to the web site 3. The web site responds with a challenge 4. The attacker relays the challenge to the victim 5. The victim signs the challenge and sends the signature 6. The attacker relays the signature to the web site At step 5, the victim's browser is running JavaScript code coming from the attacker, which does not have access to the private key, due to the same origin policy of the web, enforced by the browser
But cryptographic authentication cannot be But cryptographic authentication cannot be used by itself used by itself A cryptographic factor is a possession factor, and as such has an inherent vulnerability to theft of the cryptographic secret, in this case the private key A second factor is needed, such as a password or a biometric There are two methods for adding a second factor
Method No. 1 for adding a second factor: Method No. 1 for adding a second factor: Use the second factor to unlock the first factor Use the second factor to unlock the first factor Used by the FIDO Alliance The key pair is called a FIDO credential and is stored in a FIDO authenticator Using a FIDO credential requires unlocking the authenticator with the same PIN or biometric used to unlock the device Good news: Today, every OS provides a platform authenticator accessible to all browsers So FIDO is a generally available technology on the internet
But general availability does not mean general But general availability does not mean general adoption adoption In March 2022 the FIDO Alliance published a white paper announcing that FIDO "has not attained large scale adoption in the consumer space"
The reason for lack of adoption is that FIDO The reason for lack of adoption is that FIDO credentials face multiple UX challenges credentials face multiple UX challenges The FIDO Alliance white paper correctly diagnosed one of the challenges: Challenge 1: the credential is bound to the authenticator, and lost if the device containing the authenticator becomes unavailable and it proposed a solution: Synchronize credentials via the OS across devices with OSes from the same OS vendor Apple, Microsoft and Google where ready to implement the credential, and they have indeed implemented it: synchronized FIDO credentials are known as passkeys is
But passkey synchronization faces its own UX But passkey synchronization faces its own UX challenges challenges Not available across devices with OSes from different vendors Requires the user to log in to the OS vendor with the insecure MFA that FIDO is trying to avoid My paper proposes an alternative solution to Challenge 1 that avoids these passkey challenges without requiring any modification to current FIDO technology: Use an email address as username and generate credentials on-the- fly upon email address verification
This solution to Challenge 1 results in a simple This solution to Challenge 1 results in a simple user experience user experience 1. The user logs in by entering the email address. 2. If there is no cryptographic credential in the browser, a message with an email verification link is sent 3. A credential is automatically created when the user opens the link in the browser
But the FIDO Alliance white paper failed to But the FIDO Alliance white paper failed to diagnose a second UX challenge: diagnose a second UX challenge: Challenge 2: reliance on the device-unlocking mechanism (e.g. Windows Hello) To use FIDO, Windows users have to set up Windows Hello, which only 30% of them do And few web sites will implement an authentication mechanism that most Windows users cannot use
Challenge 2 cannot be solved with unmodified Challenge 2 cannot be solved with unmodified FIDO technology FIDO technology It requires a different method for adding a second factor And that would require an extension of the Web Authentication API, or giving up on FIDO and storing the cryptographic credential in localStorage
Method No. 2 for adding a second factor Method No. 2 for adding a second factor Use a password as second factor Extend the credential by adding a secret salt To authenticate, the frontend sends: The signature on the backend challenge, computed with the private key The hash of the password with the secret salt The public key The backend: Hashes the public key with the salted hash and verifies the result against a registered value Verifies the signature with the public key, then discards the public key
Security properties Security properties Authentication resists a MITM phishing attack thanks to the same origin policy The password is protected against reuse at a malicious site because every site has a different secret salt The password is protected against backend breaches because the secret salt is not stored in the backend The private key is protected against a postquantum attacker who breaches the backend because the public key is not stored in the backend
Replicating a cryptographic credential without Replicating a cryptographic credential without synchronization synchronization Technique 2 requires the same extended key pair to be used in all browsers and devices This is achieved without credential synchronization by: Using an email address as username Deriving a seed for generation of pseudo-random bits from the email address and a master secret Using the seed to generate the cryptographic credential upon email verification
A familiar UX A familiar UX The user authenticates as usual with username and password, using an email address as username When using a new browser, a message with an email verification link is sent, and a cryptographic credential is created when the user opens the link in the browser
