TLDR
Zelfs als u niets anders uit dit stuk haalt: als uw organisatie de implementatie van wachtwoordsleutels evalueert, is het onzeker om gesynchroniseerde wachtwoordsleutels te implementeren.
- Gesynchroniseerde toegangscodes nemen het risico over van de cloudaccounts en herstelprocessen die deze beschermen, waardoor er aanzienlijke bedrijfsrisico’s ontstaan.
- Adversary-in-the-middle (AiTM)-kits kunnen authenticatie-fallbacks afdwingen die sterke authenticatie geheel omzeilen
- Schadelijke of gecompromitteerde browserextensies kunnen WebAuthn-verzoeken kapen, de registratie of aanmelding met een wachtwoord manipuleren en automatisch aanvullen aansturen om inloggegevens en eenmalige codes te lekken.
- Apparaatgebonden wachtwoordsleutels in hardwarebeveiligingssleutels bieden meer zekerheid en betere administratieve controle dan gesynchroniseerde wachtwoordsleutels, en zouden verplicht moeten zijn voor gebruiksscenario’s voor zakelijke toegang
Gesynchroniseerde wachtwoordrisico’s
Gesynchroniseerde toegangssleutelkwetsbaarheden
Wachtwoorden zijn inloggegevens die zijn opgeslagen in een authenticator. Sommige zijn apparaatgebonden, andere worden op verschillende apparaten gesynchroniseerd via clouddiensten voor consumenten, zoals iCloud en Google Cloud. Sync verbetert de bruikbaarheid en het herstel in consumentenscenario’s met weinig beveiliging, maar verschuift de vertrouwensgrens naar cloudaccounts en herstelworkflows. De FIDO Alliance en Yubico hebben beide belangrijke adviezen uitgebracht aan bedrijven om deze splitsing te evalueren en de voorkeur te geven aan apparaatgebonden opties voor meer zekerheid.
Operationeel vergroten gesynchroniseerde toegangssleutels het aanvalsoppervlak op drie manieren:
- Overname van cloudaccounts of misbruik van herstel kunnen nieuwe apparaten autoriseren, waardoor de integriteit van de inloggegevens wordt aangetast.
- Als een gebruiker op zijn bedrijfsapparaat is ingelogd met zijn persoonlijke Apple iCloud-account, kunnen de aangemaakte wachtwoordsleutels worden gesynchroniseerd met zijn persoonlijke accounts; hierdoor wordt het aanvalsoppervlak dramatisch vergroot buiten de beveiligingsgrenzen van de onderneming.
- Helpdesk- en accountherstel worden de echte controlepunten waar aanvallers zich op richten, omdat ze dezelfde beschermde sleutelhanger naar een nieuw, onbekend en niet-vertrouwd apparaat kunnen kopiëren.
Authenticatie-downgrade-aanvallen
Proofpoint-onderzoekers documenteerden een praktische downgrade van Microsoft Entra ID waarbij een phishing-proxy een niet-ondersteunde browser vervalst, zoals Safari op Windows, Entra wachtwoordsleutels uitschakelt en de gebruiker wordt begeleid om een zwakkere methode te selecteren, zoals SMS of OTP. De proxy legt vervolgens de inloggegevens en de resulterende sessiecookie vast en importeert deze om toegang te krijgen.
Deze bedreigingsvector is afhankelijk van de ongelijke besturingssysteem- en browserondersteuning van webAuthnpasskey en de acceptatie door de identiteitsprovider (IdP) van zwakke authenticatiemethoden ten gunste van een praktische UX-overweging. Het is een klassieke tegenstander-in-het-midden (AitM) die wordt aangedreven door beleidssturing. Het verbreekt de WebAuthn-oorsprongbinding niet, omdat het platform nooit een WebAuthn-ceremonie bereikt wanneer een compatibiliteitsvertakking deze uitschakelt. Uw zwakste authenticatiemethode bepaalt uw echte veiligheid.
Onmiddellijke bemiddeling in WebAuthn is een functie waarmee sites een alternatieve authenticatiemethode kunnen aanbieden wanneer WebAuthn niet beschikbaar is. Dit is handig voor UX, maar kan ook door aanvallers worden misbruikt om gebruikers naar niet-webAuthn-paden te sturen als het beleid dit toestaat.
Browsergebaseerde beveiliging die kwetsbaar is voor bedreigingsvectoren voor uitbreiding en automatisch aanvullen
Onderzoekers van SquareX hebben aangetoond dat een gecompromitteerde browseromgeving WebAuthn-oproepen kan kapen en de registratie of aanmelding van wachtwoorden kan manipuleren. De techniek verbreekt de wachtwoordcryptografie niet. Het injecteert of onderschept het browserproces, bijvoorbeeld via een kwaadaardige extensie of een XSS-bug, om de registratie opnieuw te starten, een wachtwoordterugval te forceren of stilletjes een bewering af te ronden.
Chrome documenteert een extensie-API met de naam ‘webAuthenticationProxy’ die de methoden navigator.credentials.create() en navigator.credentials.get() kan onderscheppen zodra deze zijn gekoppeld, en vervolgens zijn eigen antwoorden kan leveren. Deze mogelijkheid bestaat voor gebruiksscenario’s op afstand, maar het laat zien dat een extensie met de juiste toestemming in het WebAuthn-pad kan staan.
Extensies voeren ook inhoudsscripts uit binnen de paginacontext, waar ze de DOM kunnen lezen en wijzigen en gebruikersinterfacestromen kunnen aansturen, waaronder het aanroepen van referentie-API’s vanaf de pagina.
Onafhankelijk onderzoek gepresenteerd op DEF CON beschrijft op DOM gebaseerde clickjacking van extensies die zich richt op de UI-elementen die worden geïnjecteerd door extensies voor wachtwoordbeheer. Eén klik van een gebruiker op een gemaakte pagina kan het automatisch aanvullen en exfiltreren van opgeslagen gegevens, zoals logins, creditcards en eenmalige codes, activeren. De onderzoeker meldt dat in sommige scenario’s ook wachtwoordverificatie kan worden misbruikt en somt kwetsbare versies van meerdere leveranciers op.
Apparaatgebonden inloggegevens zijn de enige effectieve bedrijfsoplossing
Apparaatgebonden wachtwoordsleutels zijn gekoppeld aan een specifiek apparaat, waarbij het genereren en gebruiken van privésleutels doorgaans wordt uitgevoerd in beveiligde hardwarecomponenten. In ondernemingen bieden hardwarebeveiligingssleutels consistente apparaatsignalen, attesten en een levenscyclus die u kunt inventariseren en intrekken.

Begeleiding voor een sleutelprogramma op bedrijfsniveau
Beleid
- Vereis phishing-bestendige authenticatie voor alle gebruikers, en vooral voor gebruikers in geprivilegieerde rollen. Accepteer alleen apparaatgebonden authenticators die bij registratie niet-exporteerbare inloggegevens genereren en verlaat het apparaat nooit. Inloggegevens moeten zijn geworteld in beveiligde hardware en aantoonbaar zijn gekoppeld aan het fysieke apparaat dat probeert in te loggen.
- Elimineer alle fallback-methoden zoals sms, spraakoproepen, TOTP-apps, e-maillinks en push-goedkeuringen. Deze zijn er om te worden uitgebuit tijdens social engineering- en downgrade-aanvallen. Als er een terugval bestaat, zal een aanvaller deze forceren. Maak van het sterke pad het enige pad.
- Zorg voor universele besturingssysteem- en browserondersteuning voor phishing-bestendige, apparaatgebonden inloggegevens. Bied geen alternatieven aan – ja dit is mogelijk, we laten u graag een demo zien met het identiteitsverdedigingsplatform van Beyond Identity. Universele dekking is noodzakelijk voor volledige verdediging, omdat u slechts zo beschermd bent als uw zwakste schakel.
Browser- en extensiehouding
- Dwing toelatingslijsten voor extensies af in beheerde browsers. Sta geen enkele extensie toe die om webAuthenticationProxy-, activeTab- of brede inhoudscriptmachtigingen vraagt.
- Houd voortdurend toezicht op de installatie van extensies en gebruikstrends op verdachte massale verwijderingen of onverklaarbare escalaties van toestemmingen. Compromis op extensieniveau is steeds minder te onderscheiden van een legitieme gebruiker. Vergrendel het browsergedrag net zo strak als u dat met een eindpunt zou doen.
Inschrijving en herstel
- Gebruik authenticatiemiddelen met hoge zekerheid als basis voor herstel. Geen enkele helpdesk, e-mailinbox of callcenter zou phishing-bestendige controles moeten kunnen omzeilen. Herstel is vaak het toegangspunt voor de aanvaller. Elimineer social engineering-vectoren en dwing beleidsconforme reproofing af.
- Sta alleen de inschrijving van apparaatgebonden inloggegevens toe.
- Leg attest-metagegevens vast bij registratie, inclusief apparaatmodel en betrouwbaarheidsniveau. Weiger niet-herkende of niet-verifieerbare authenticatiemiddelen. Vertrouwen begint bij registratie. Als u niet weet waardoor de referentie is gemaakt, heeft u geen controle over de toegang.
Apparaathygiëne en runtime-verdediging
- Bind sessies aan de vertrouwde apparaatcontext. Een sessiecookie mag nooit een draagbaar artefact zijn. Het afdwingen van runtimesessies moet de identiteit koppelen aan de continue apparaatstatus, en niet alleen aan een initiële authenticatie.
- Dwing continue authenticatie af. Als de houding, locatie of beveiligingsstatus van het apparaat verandert, moet u opnieuw verifiëren of de toegang weigeren. Een login is geen halpas. Risico is dynamisch, authenticatie moet dat ook zijn.
- Stel dat authenticatiepogingen met zwakke factoren standaard moeten worden geblokkeerd. Ontdek hoe Beyond Identity-klanten blokkeer onmiddellijk identiteitsaanvallen op basis van het simpele feit dat het geen sterke inloggegevens zijn die toegang proberen te krijgen.
Hoe dit er in de praktijk uitziet
De architectuur van een identiteitsbeveiligingssysteem dat compromisloze verdediging biedt tegen identiteits-, browser- en apparaatgebaseerde aanvallen kan worden gedefinieerd door deze drie kenmerken:
- Apparaatgebonden referenties: Inloggegevens verlaten het apparaat nooit. Ze zijn niet-exporteerbaar, worden ondersteund door hardware en kunnen niet elders worden gesynchroniseerd of afgespeeld.
- Continu vertrouwen: Authenticatie stopt nooit bij het inloggen. Het gaat door gedurende de hele sessie, gekoppeld aan houdingssignalen van het apparaat.
- Universele eindpunthygiënehandhaving: Alle eindpunten vallen binnen het bereik. Zelfs onbeheerde apparaten moeten in realtime worden geëvalueerd op risicohouding en sessie-integriteit.

De bottom-line
Gesynchroniseerde toegangssleutels zijn geen krachtveld dat geschikt is voor verdediging. Ze verbeteren de bruikbaarheid voor consumentengebruik, ten koste van de toegangsbeveiliging van bedrijven.
Zie meer in-actie in een aankomend webinar, Hoe aanvallers FIDO omzeilen: waarom gesynchroniseerde toegangssleutels mislukken en wat u in plaats daarvan kunt doen waar Beyond Identity zal beoordelen hoe gesynchroniseerde wachtwoordfouten optreden en hoe toonaangevende beveiligingsteams, waaronder Snowflake en Cornell University, deze paden sluiten.
Zelfs als je niet mee kunt doen, schrijf je dan in en je krijgt de opname!