WebAuthn-API:er för lösenordsfri autentisering i Windows
Lösenord kan göra dina kunder sårbara för dataintrång och säkerhetsattacker från skadliga användare.
Microsoft har länge varit en förespråkare för lösenordsfri autentisering och har introducerat PLATTFORMS-API:er för W3C/Fast IDentity Online 2 (FIDO2) Win32 WebAuthn i Windows 10 (version 1903).
Från och med Windows 11 version 22H2 stöder WebAuthn-API:er ECC-algoritmer.
Vad innebär detta?
Med hjälp av WebAuthn-API:er kan utvecklarpartner och utvecklarcommunityn använda Windows Hello eller FIDO2-säkerhetsnycklar för att implementera lösenordslös multifaktorautentisering för sina program på Windows-enheter.
Användare av dessa appar eller webbplatser kan använda valfri webbläsare som stöder WebAuthn-API:er för lösenordsfri autentisering. Användarna får en välbekant och konsekvent upplevelse i Windows, oavsett vilken webbläsare de använder.
Utvecklare bör använda WebAuthn-API:er för att stödja FIDO2-autentiseringsnycklar på ett konsekvent sätt för användare. Dessutom kan utvecklare använda alla transporter som är tillgängliga enligt FIDO2-specifikationerna (USB, NFC och BLE) samtidigt som interaktions- och hanteringskostnaderna undviks.
Nota
När dessa API:er används har Windows 10 webbläsare eller program inte direkt åtkomst till FIDO2-transporterna för FIDO-relaterade meddelanden.
Helheten
CTAP2 (Client to Authenticator Protocol 2) och WebAuthn definierar ett abstraktionslager som skapar ett ekosystem för starkt autentiserade autentiseringsuppgifter. I det här ekosystemet använder alla samverkande klienter (till exempel en inbyggd app eller webbläsare) som körs på en viss klientenhet en standardiserad metod för att interagera med alla samverkande autentiseringsanordningar. Samverkande autentiserare omfattar autentisering som är inbyggda i klientenheten (plattformsautentisering) och autentiserare som ansluter till klientenheten med hjälp av USB-, BLE- eller NFC-anslutningar (roamingautentiseringar).
Autentiseringsprocessen startar när användaren gör en specifik användargest som anger medgivande för åtgärden. På begäran av klienten skapar autentiseringen på ett säkert sätt starka kryptografiska nycklar och lagrar dem lokalt.
När dessa klientspecifika nycklar har skapats kan klienter begära attesteringar för registrering och autentisering. Den typ av signatur som den privata nyckeln använder återspeglar användargesten som gjordes.
Följande diagram visar hur CTAP och WebAuthn interagerar. De ljusblå prickade pilarna representerar interaktioner som är beroende av den specifika implementeringen av plattforms-API:erna.
Relationer mellan de komponenter som deltar i lösenordsfri autentisering
En kombinerad WebAuthn/CTAP2-dans innehåller följande karaktärer:
Klientenhet. Klientenheten är den maskinvara som är värd för en viss stark autentisering. Bärbara datorer och telefoner är exempel på klientenheter.
Förlitande parter och klienter. Förlitande parter är webbprogram eller interna program som använder starka autentiseringsuppgifter. De förlitande parterna körs på klientenheter.
Som förlitande part kan ett internt program också fungera som en WebAuthn-klient för att göra direkta WebAuthn-anrop.
Som förlitande part kan ett webbprogram inte interagera direkt med WebAuthn-API:et. Den förlitande parten måste asynkrona avtalet via webbläsaren.
Nota
Föregående diagram visar inte autentisering med enkel Sign-On (SSO). Var noga med att inte förvirra FIDO-förlitande parter med federerade förlitande parter.
WebAuthn API. Med WebAuthn-API:et kan klienter göra begäranden till autentiserare. Klienten kan begära att autentiseraren ska skapa en nyckel, tillhandahålla en försäkran om en nyckel, rapportfunktioner, hantera en PIN-kod och så vidare.
CTAP2-plattform/värd. Plattformen (kallas även värden i CTAP2-specifikationen) är den del av klientenheten som förhandlar med autentiserare. Plattformen ansvarar för att på ett säkert sätt rapportera ursprunget till begäran och anropa API:erna för CTAP2 Concise Binary Object Representation (CBOR). Om plattformen inte är CTAP2-medveten tar klienterna själva på sig mer av bördan. I det här fallet kan de komponenter och interaktioner som visas i föregående diagram skilja sig åt.
Plattformsautentisering. En plattformsautentisering finns vanligtvis på en klientenhet. Exempel på plattformsautentisering är teknik för fingeravtrycksigenkänning som använder en inbyggd fingeravtrycksläsare för bärbar dator och ansiktsigenkänningsteknik som använder en inbyggd smartphonekamera. Plattformsoberoende transportprotokoll som USB, NFC eller BLE kan inte komma åt plattformsautentisering.
Roamingautentisering. En roamingautentisering kan ansluta till flera klientenheter. Klientenheter måste använda ett transportprotokoll som stöds för att förhandla om interaktioner. Exempel på roamingautentisering är USB-säkerhetsnycklar, BLE-aktiverade smartphone-program och NFC-aktiverade närhetskort. Centrala autentiseringsfunktioner har stöd för CTAP1, CTAP2 eller båda protokollen.
Många förlitande parter och klienter kan interagera med många autentiserare på en enda klientenhet. En användare kan installera flera webbläsare som stöder WebAuthn och samtidigt ha åtkomst till en inbyggd fingeravtrycksläsare, en inkopplad säkerhetsnyckel och ett BLE-aktiverat mobilprogram.
Driftskompatibilitet
Före WebAuthn och CTAP2 fanns det U2F och CTAP1. U2F är FIDO Alliance universal second-factor specification. Det finns många autentiserare som talar CTAP1 och hanterar U2F-autentiseringsuppgifter. WebAuthn har utformats för att vara samverkande med CTAP1 Authenticators. En förlitande part som använder WebAuthn kan fortfarande använda U2F-autentiseringsuppgifter om den förlitande parten inte kräver FIDO2-funktioner.
FIDO2-autentisering har redan implementerats och WebAuthn-förlitande parter kan kräva följande valfria funktioner:
- Nycklar för flera konton (nycklar kan lagras per förlitande part)
- Klientens PIN-kod
- Plats (autentiseringen returnerar en plats)
- Hash-baserad HMAC-hemlighet (Message Authentication Code) ( aktiverar offlinescenarier)
Följande alternativ kan vara användbara i framtiden, men har inte observerats i naturen ännu:
- Transaktionsgodkännande
- Index för användarverifiering (servrar kan avgöra om biometriska data som lagras lokalt har ändrats över tid)
- Metod för användarverifiering (autentiseringsmetoden returnerar den exakta metoden)
- Biometriska prestandagränsningar (den förlitande parten kan ange godtagbara falska godkännanden och falska avvisningsfrekvenser)
Microsoft implementering
Genomförandet av Microsoft FIDO2 har pågått i flera år. Programvara och tjänster implementeras oberoende som standardkompatibla entiteter. Från och med versionen av Windows 10 version 1809 (oktober 2018) använder alla Microsoft-komponenter den senaste WebAuthn Candidate-versionen. Det är en stabil version som inte förväntas ändras normativt innan specifikationen slutligen ratificeras. Eftersom Microsoft är bland de första i världen som distribuerar FIDO2 är vissa kombinationer av populära icke-Microsoft komponenter inte kompatibla ännu.
Här är en ungefärlig layout för vart de Microsoft bitarna går:
Microsoft implementering av WebAuthn- och CATP2-API:er
WebAuthn-förlitande part: Microsoft-konto. Om du inte är bekant med Microsoft Konto är det inloggningstjänsten för Xbox, Outlook och många andra webbplatser. Inloggningsupplevelsen använder JavaScript på klientsidan för att utlösa Microsoft Edge för att kommunicera med WebAuthn-API:erna. Microsoft konto kräver att autentiserare har följande egenskaper:
- Nycklar lagras lokalt på autentiseringshanteraren och inte på en fjärrserver
- Offlinescenarier fungerar (aktiveras med HMAC)
- Användare kan placera nycklar för flera användarkonton i samma autentisering
- Om det behövs kan autentiserare använda en klient-PIN-kod för att låsa upp en TPM
Viktigt
Eftersom Microsoft konto kräver funktioner och tillägg som är unika för FIDO2 CTAP2-autentiseringsuppgifter, accepterar det inte autentiseringsuppgifter för CTAP1 (U2F).
WebAuthn-klient: Microsoft Edge. Microsoft Edge kan hantera användargränssnittet för funktionerna WebAuthn och CTAP2 som beskrivs i den här artikeln. Det stöder även AppID-tillägget. Microsoft Edge kan interagera med både CTAP1- och CTAP2-autentisering. Det här omfånget för interaktion innebär att det kan skapa och använda både U2F- och FIDO2-autentiseringsuppgifter. Men Microsoft Edge talar inte U2F-protokollet. Förlitande parter måste därför endast använda WebAuthn-specifikationen. Microsoft Edge på Android stöder inte WebAuthn.
Nota
Auktoritativ information om Microsoft Edge-stöd för WebAuthn och CTAP finns i dokumentationen om äldre Microsoft Edge-utvecklare.
Plattform: Windows 10, Windows 11. Windows 10 och Windows 11 värd för Win32 Platform WebAuthn-API:er.
Centrala autentiserare. Du kanske märker att det inte finns någon Microsoft roamingautentisering. Anledningen är att det redan finns ett starkt ekosystem med produkter som specialiserar sig på stark autentisering, och varje kund (oavsett om det är företag eller individer) har olika krav för säkerhet, användarvänlighet, distribution och kontoåterställning. Mer information om den ständigt växande listan över FIDO2-certifierade autentiserare finns i FIDO-certifierade produkter. Listan innehåller inbyggda autentiserare, roaming-autentisering och till och med chiptillverkare som har certifierad design.
Utvecklarreferenser
WebAuthn-API:erna dokumenteras i Microsoft/webauthn GitHub-lagringsplatsen. Läs följande två specifikationer för att förstå hur FIDO2-autentisering fungerar:
- Webbautentisering: Ett API för åtkomst till autentiseringsuppgifter för offentlig nyckel (tillgängligt på W3C-webbplatsen). Det här dokumentet kallas webauthn-specifikationen.
- Klient till Authenticator Protocol (CTAP). Det här dokumentet finns på FIDO Alliance-webbplatsen , där maskinvaru- och plattformsteam arbetar tillsammans för att lösa problemet med FIDO-autentisering.