1. FIDO2 under the hood
1.1. Crypto Signing and Verification
1.1.1. Signer: Hash of the message is encrypted with the Private Key, and add the signature is added to the encrypted hash.
1.1.2. Verifier: signature is decrypted with the Public Key
1.2. FIDO2 Authentication
1.2.1. Authe
1.2.1.1. Step 0: In the registration process the Public Key which will be used for the encryption is provided to the Relying party.
1.2.1.2. Step 1: Relying party send a challenge to the browser
1.2.1.3. Step 2: Browser forwards the challenge to a Authenticator
1.2.1.4. Step 3: User authenticates against the Authenticator
1.2.1.5. Step 4: Authenticator signs the response with the Private Key
1.2.1.6. Step 5: Relying Party uses the stored public key of the User and verifies the response
1.2.1.7. Assertion is a signed response
1.2.1.8. Azure AD supports 2 Authentication methods
1.3. Shared secrets are replaced with asymmetric cryptography
1.3.1. User sign the message with the Private Key
1.3.2. Relying party validates the signature with the users Public Key
1.4. WebAuthN
1.4.1. FIDO2 works with CTAP2
1.4.2. Older U2F keys used for 2FA and comunicate using CTAP1
1.4.3. Windows Hello uses a platform Authenticator using the internat TPM
1.5. Registration Ceremony
1.5.1. Registration includes binding a FIDO credential on an given Authenticator to a specific users. Multiple Authenticators can be registered on an account for recovery.
1.5.2. Client checks the origin of the request matches the Relaying party Id, and can avoid a Man In The Middle attack (MITM).
1.5.3. Client sends the Userid, Rpid (Relaying Party Id), any specific options to the actual Authenticator
1.5.4. Authenticator requests user verificaton and generates a Public key pair and credential Id.
1.5.5. During registration, a new public key is created and signed with an Attestation Private Key that was created with the device when it was manufactured.
1.5.6. Attestation (Private) Key is burned into device used
1.5.6.1. FIDO TechNotes: The Truth about Attestation - FIDO Alliance
1.5.7. Relaying Party send the initial origin in the received signed Authenticator response
1.5.8. FIDO Alliance Metadata Service (MDS) contains the metadata published by the Authenticator vendors
1.5.8.1. Provides characteristics and capabilities of a particular Authenticator
1.5.8.2. Allows risk-based descisions to be made about a particular Authenticator
1.5.8.3. Authenticators are identified by an Authenticator Attestation GUID (AAGUID). This identifier is unique for a product model.
1.6. Authentication Ceremony
1.6.1. Client validates the origin and sends through to the Authenticator
1.6.2. Authenticator verifies the User
1.6.3. Authenticator retrieves the Private Key based on the Credential Id
1.6.4. Authenticator builds and signs the response with the credential Private Key
1.6.5. Relaying Party validates the response and the signature with the Public Key
1.6.6. https://webauthn.io/
2. FIDO2 and Windows 10 / Azure Sign-in
2.1. Azure currently has two Authentication Method Policy
2.1.1. FIDO2 Security Key
2.1.2. Microsoft Authenticator passwordless sign-in
2.2. Future: MFA, Self-Service Password reset, Password
2.3. Keys only have to be registered once, and coupled to a group of users afterwards.
3. Going passwordless
3.1. Standards are needed if you want to have a scalable passwordless solution
3.2. FIDO standards
3.2.1. 2012
3.2.1.1. Founding of the Fast Identity Online (FIDO) alliance, mission to create a passwordless authentication protocol
3.2.2. 2014
3.2.2.1. Publishment of the first two protocols
3.2.2.2. FIDO UAF
3.2.2.2.1. Universal Authentication Framework
3.2.2.2.2. FIDO UAF Architectural Overview
3.2.2.3. FIDO U2F
3.2.2.3.1. Universal 2nd Factor protocol
3.2.2.3.2. Universal 2nd Factor (U2F) Overview
3.2.3. 2019
3.2.3.1. FIDO2 Web Authentication (WebAuthN) protocol was adopted W3C
3.2.3.1.1. FIDO2: Web Authentication (WebAuthn) - FIDO Alliance
3.2.3.1.2. Hundreds of different keys are supporting FIDO2
3.2.3.2. Windows Hello was certified as FIDO2 compliant
4. Passwords are a problem
4.1. User have to create them
4.2. 43% of users use same passwords on different sites. Easy to guess passwords can lead to...
4.2.1. Spray attacks, where passwords are sprayed over multiple accounts. At some point one of the accounts will get compromised.
4.2.2. Brute-force attacks, which attacks one account and can easily be detected.
4.3. MFA is a must and eliminates 99% of sign-ins with compromised passwords.
4.3.1. Don't over prompt for MFA
4.3.2. In most cases SMS MFA is sufficient
4.4. A password is the secret with the relying party, which is hopefully properly protecting your password.
4.4.1. Just check the following site to see if some passwords has been compromised in the past: https://haveibeenpwned.com/
4.4.2. 425 pwned sites, 9,319,713,483 pwned accounts
5. FIDO Scenarios
5.1. 2FA
5.2. Passwordless
5.3. Nameless & Passwordless
6. FIDO2 Benefits
6.1. A user is required to create the password
6.1.1. No password is required.
6.1.2. A unique cryptographic key pair is created for each site.
6.2. User reveal their passwords via phishing attacks
6.2.1. Even if a user gave away their PIN, an attack is not going to succeed without the Authenticator
6.2.2. All credentials are scoped for a particular Relying Party, eliminating phishing attacks via fake websites.