Sorry voor de typo in de titel, pen8ciline moet natuurlijk peniciline zijn (helaas kan ik reacties, 1 uur na posten, niet meer corrigeren). Nogmaals mijn excuses!

En waar haal je vandaan dat MFA niet veilig genoeg is? Volgens mij is het gebruik van MFA altijd nog veiliger dan alleen vertrouwen op wachtwoorden. En ja, wanneer je het goed aanpakt, dus volgens je eigen "veilig inloggen" regels kom je alsnog heel heel ver. Maar als wachtwoorden op straat liggen door een datalek ben je alsnog de sjaak. Hoe veilig ze ook zijn.

Hoe kijk je aan tegen MFA met een hardware sleutel, zoals een YubiKey?
Ik zie dat als veiliger dan SMS of aparte app.

Even een boude stelling: Met een hardware sleutel heb je eigenlijk geen wachtwoord meer nodig!

Helemaal mee eens. MFA is vele malen beter dan geen MFA, geldt trouwens ook voor peniciline. Is het de perfecte oplossing: Nee. Maar wachten tot er een betere is en dan pas wat gaan doen is (ook) geen optie. Elke oplossing heeft voor en nadelen, die je goed in de gaten zal moeten houden.

Dank voor jouw eenvoudig te pareren drogredenen; ik grijp de geboden gelegenheid graag aan.

Als de 2FA/MFA shared secrets óók op straat liggen na datzelfde datalek van een server met een account van jou, ben je ook de Sjaak (de server kan géén gebruik maken van éénweg afgeleiden van shared secrets voor SMS, TOTP en Number Matching - zoals wel kan, en "best practice" of zelfs verplicht is, bij wachtwoorden).

Toegegeven, dat geldt uitsluitend zolang het lek op de server niet gedicht is en de inloggegevens nog niet zijn gereset (een nieuw drama, want hoe weet de servereigenaar wie de échte accounteigenaren waren).

Bovendien liggen de meeste (wellicht geen van allen, maar zie punt 3 hieronder) sterke wachtwoorden niet op straat na een datalek - mits de eigenaar van die server zich aan de regels (GDPR/AVG) heeft gehouden. De kans dat zelfs een MD5 hash van een sterk wachtwoord "gereversed" kan worden, is verwaarloosbaar klein [1].

[1] Voor onderbouwing zie https://tweakers.net/nieuws/217734/#r_19528434 en vooral https://tweakers.net/nieuws/217734/#r_19529272.

En mocht een aanvaller, op een gehackte server, jouw "plain text" wachtwoord hebben gesniffd op het moment dat jij dat invoerde: als jij dat specifieke wachtwoord (net als een 2FA/MFA shared secret) uitsluitend gebruikt voor een account op die server, is het op straat belanden van dat wachtwoord, t.g.v. de toegang van een aanvaller tot die server en de gegevens toegankelijk via jouw account, het minste waar jij je zorgen over hoeft te maken.

Want, in tegenstelling tot andere van jouw vertrouwelijke gegevens, banksaldo of reputatieschade veroorzaakt doordat anderen cryptoscams of kinderporno via jouw account hebben verspreid, et cetera: juist dat wachtwoord kun je doodeenvoudig en zonder nevenschade vervangen (nadat de puinhoop op de server is opgeruimd).

Overigens, bij "sterke 2FA/MFA", zoals Client Certificaten of WebAuthn (FIDO2 hardware keys en Passkeys) ook wel worden genoemd, kan een sniffer op de server het door de server naar de browser gestuurde (tot nu toe altijd 1FA) authenticatie token (bijv. een session cookie) sniffen en hergebruiken om zich voor te doen als de ingelogde persoon.

Daarnaast kan de aanvaller, in veel gevallen, public keys (in Client Certs of zoals gebruikt bij WebAuthn) vervangen of toevoegen aan accounts. Helaas zitten WebAuthn public keys niet in vertrouwde client certificaten, waardoor een eigenaar van een gehackte server geen idee heeft van wie een WebAuthn public key in een account-record is.

De kracht van Client Certificaten en WebAuthn zit hem nauwelijks in de meestal geadverteerde Public Key Cryptography (want bijna niemand snapt daar iets van, handig als Haarlemmerolie), maar primair dat https vereist is en de domeinnaam (grotendeels) moet kloppen; anders weigert het systeem om je in te laten loggen. Door dat laatste is de phishing-resistentie van WebAuthn groot.

Helaas neemt de betrouwbaarheid van WebAuthn af naarmate er steeds vaker onterecht https servercertificaten worden uitgegeven, waardoor phishing alsnog mogelijk is (maar dat is een ander topic, waar ik -desgewenst- wel verder op in wil gaan).

Tevens: indien, nadat een backup van jouw database met shared secrets is gelekt, blijkt dat deze slecht beveiligd is en daardoor de tweede factor voor elk van jouw daarmee beveiligde accounts op straat ligt ([2]), vooral als jij geen weet hebt van dat lek, ben je ook de Sjaak. En dat heel erg als je, omdat je op 2FA/MFA vertrouwt, overal hetzelfde zwakke wachtwoord gebruikt.

Het aanmoedigen van zwakke twee- of meer-factor-authenticatie geeft een volstrekt verkeerde impuls.

[2] Niet ondenkbaar, voor onderbouwing -specifiek voor Authy- zie https://tweakers.net/nieuws/207532/#r_18549330 en voor andere zie https://security.nl/posting/796707.

Nb. Ik claim niet dat wachtwoordmanagers risicoloos zijn, integendeel. Het is een SPOF (Single Point Of Failure), en ook hierbij is het risico op verlies van toegang groot (net als bij veel 2FA/MFA apps). Maar dáár, en aan door mensen gebruikte apparaten, besturingssystemen en software, kunnen we eisen (laten) stellen en grotere betrouwbaarheid afdwingen - iets dat véél te weinig gebeurt (net zo min als bij zwakke 2FA/MFA "oplossingen").

Ten slotte: wachtwoordmanagers die betrouwbaar op domeinnamen én op het gebruik van https checken, zijn schaars en nauwelijks ingeburgerd. Echter, zoals ik in punt 4 aangaf: bij onterecht uitgegeven servercertificaten helpen ook wachtwoordmanagers niet.

Om het internet veiliger te krijgen is het bloedlink om met 2FA/MFA of zelfs EDIW/EUDIW burgers betrouwbaarder te laten authenticeren, terwijl tegelijkertijd de betrouwbaarheid van de authenticatie van de verifieerders (servers) achteruit holt.

Pavel Durov wordt gearresteerd omdat hij criminelen anonimiteit biedt, maar big tech (Cloudflare, Google, Let's Encrypt etc.) komen daar massaal mee weg.

Eén voorbeeld (Cloudflare proxy, Cloudflare cert):
   https://www.lîdl.be/login
(nog steeds live, zie ook https://infosec.exchange/@ErikvanStraten/113110017627459641).

Dat je geen wachtwoord meer nodig hebt gaat natuurlijk alleen op in het geval dat je tot het einde der tijden zelf controle hebt over je hardware sleutel.

Een autoriteit kan je natuurlijk dwingen om fysieke goederen af te staan, kennis uit een hoofd peuteren gaat een stuk lastiger.

Je vergelijking van peniciline is ronduit onverstandig. Je probeert een complexe geneeskundige behandeling en chemise structuur te vergelijken met een complexe technische oplossing terwijl het geen enkele raakvlak heeft.

Maar zelfs als we dat negeren haal je je eigen argument meteen de zin erna onderuit omdat je zegt: Maar als mensen dus wel allemaal een slimme (wat dat ook mag zijn) wachtwoord manager gaan gebruiken en we jouw logica volgen betekent dat weer dat er tools zullen komen om daar om heen te werken en dat het dus voor niks was. Anders hadden ze net zo goed ook MFA kunnen gebruiken als het toch geen nut heeft.

Sterker nog als we wel de penicilline logica volgen dan zou men er meer baat bij hebben als er mensen zijn die MFA gebruiken en mensen die juist wachtwoord managers gebruiken. Want penicilline doe je enkel als het niet anders kan. Begrijp je waarom ik zeg dat het een onverstandige vergelijking is?

En nee ik ben voorstander van wachtwoord managers maar je betoog is gewoon niet sterk opgesteld.
Gedeeltelijk eens maar je licht het niet toe en je hoort een argument gepresenteerd als een feit niet te vertrouwen tenzij er bron vermelding en achtergrond informatie over wordt geleverd waar van toepassing zodat je naar redelijkheid de plausibiliteit kan onderzoeken.

Maar er bestaan ook authenticator app zoals microsoft dat passwordless werkt.

Vervolgens een argument dat zo een authenticatie app als van MS al spionage tool wordt gebruikt terwijl zowat ieder hier weet dat ze dat niet eens nodig hebben ervoor met een beetje techniche kennis (https://nl.wikipedia.org/wiki/PRISM). Maar weer geen achterliggende data of bronvermelding.

"Non numeranda, sed ponderanda sunt argumenta"
Argumenten moet men wegen, niet tellen
Marcus Tullius Cicero

En je kan beter Erik kijk naar je laatste post (Vandaag, 13:48 door Erik van Straten - Bijgewerkt: Vandaag, 14:23) hier in dit zelfde topic waar je wel onderbouwing geeft en achtergrond links.Maar dit hoor je niet achteraf te doen, dit hoor je bij begin van begin van je betoog al te leveren.

Ja, als.


Ja, als.


Ja, als. Daarnaast zou ik een veel groter probleem hebben als ze al op mijn server zitten.


Ja, als. Wederom moeten ze op mijn server zitten, dus wederom een groter probleem.

Ik kan wel op alle slakken zout leggen, maar in de praktijk is MFA gewoon een goede maatregel. Dat het theoretisch niet 100% is, prima, zodra je iets weet wat 100% veilig is mag je me bellen!

Onderaan jouw reactie schreef je:
en bovenaan jouw reactie:
Laat ik die (*), die jij weglaat, dan maar herhalen:

Daaruit: "4) Kies een WW-manager die domeinnamen checkt" - naast andere adviezen.

Dat sluit ik niet uit, maar mijn streven is om het aantal mogelijkheden voor aanvallers te verkleinen. Om dat toe te lichten het volgende.

Uiteindelijk is dit de situatie:

[klant]<—>[client device]<—internet—>[server]<—>[owner]

Met "owner" bedoel ik de juridisch verantwoordelijke entiteit voor de server.

Er kan sprake zijn van aanvullende, secundaire "client devices", zoals een FIDO2 hardware key, een smartphone (evt. met gescheiden internetverbinding - naar dezelfde server) naast een PC, een smartcard of een externe biometrie-scanner.

Echter, als het primaire client device gecompromitteerd is (zodanig dat een aanvaller de klant daarop andere dingen kan laten zien dan de bedoeling is, en/of diens invoer kan manipuleren), houdt alles op.

Vanzelfsprekend zullen aanvallers zich richten op elk nog niet gedicht gat of elke andere kwetsbaarheid in elke component uit bovenstaande keten (en secundaire devices).

Aan ons, securitymensen, de taak om de risico's, voor zoveel mogelijk mensen, zo klein als mogelijk te maken. En dat doen we m.i. aantoonbaar niet door zwakke MFA/2FA te promoten (dat niet helpt tegen phishing met "evil proxies", waardoor steeds vaker cloudaccounts worden gehacked en steeds meer individuen en organisaties slachtoffer worden van cybercrime).

Hoewel je de cijfers met een korrel zout moet nemen, is de trend (sinds bijv. 2019, toen Alex Weinert schreef "MFA had failed") in bijvoorbeeld https://www.statista.com/statistics/266155/number-of-phishing-domain-names-worldwide/ duidelijk waarneembaar.

Als het aantal phishingsites toeneemt, kun je er donder op zeggen dat criminelen er steeds meer geld mee "verdienen" en dus dat, ofwel het aantal slachtoffers toeneemt, ofwel dat er per slachtoffer meer geld binnengeharkt wordt. Voor dat laatste zie ik niet zo snel een reden, dus ga ik ervan uit dat het aantal toeneemt.

Ik ben benieuwd naar meer recente gegevens. Als ik bijv. in https://newly-registered-domains.abtdomain.com/2024-09-25-com-newly-registered-domains-part-1/ zie dat er alleen gisteren al 135.760 .com (hoofd-) domeinnamen zijn geregistreerd (nieuw zijn aangemaakt of van eigenaar zijn verwisseld). De meeste domeinnamen zijn absurd. Verstandige mensen snappen dat dit totaal de verkeerde kant opgaat.

Twee uit https://newly-registered-domains.abtdomain.com/2024-09-25-com-newly-registered-domains-part-27/:

Het is primair in het belang van de "klant" dat geen kwaadwillenden toegang tot diens server-account(s) verkrijgen met als doel om daar misbruik van te maken. Op de serverzijde heeft de klant meestal geen invloed.

Ik ken twee fundamentele mogelijkheden om dat digitalel doel te bereiken:
a. Shared secret;
b. "Zero trust": public key op de server, private key op client device.

Zoals ik in een eerdere posting hierboven (onder "4) "Sterke" 2FA/MFA") aangaf, zijn de voordelen van b. t.o.v. a. beperkt (tijdens inloggen wordt b. omgezet in a. - een shared secret dat het client device meestuurt bij elk verzoek aan de server).

Kortom, effectief bouwt uiteindelijk alles op een shared secret.

De kernvraag is m.i. hoe je het bovenstaande zo veilig mogelijk krijgt.

Totaal niet. Want voor zwakke MFA die gebruik maakt van TOTP of Number Matching heb je ook een soort wachtwoordmanager nodig die shared secrets opslaat die je veilig zou moeten backuppen.

Je hebt een punt, ik ben geen AI-bot maar een aanzienlijk minder dan 100% perfecte mensch van vleesch en bloed, met al diens beperkingen.

Echter, als je mijn eerdere reacties op deze site een beetje gevolgd had (zoals deze van gisteren 16:02: https://security.nl/posting/859471) dan was je op de hoogte geweest van onderbouwing en referenties naar derde partijen (waar toch wel enige autoriteit van mag worden verwacht, zoals de Director of Identity Security at Microsoft).

Soms lijken mijn postings op deze site op wetenschappelijke publicaties, maar dan is de kritiek altijd TL;DR.

Mijn stelling was dus weer te kort: ik bedoel de shared secrets, niet een eventueel wachtwoord, pincode of biometrie om toegang te krijgen tot (de 2e factor per server-account in) de app. Je lijkt zelf niet eens op de hoogte van het bestaan van die shared secrets.

Ik merk dat je her en der met heel veel links smijt, lijkt een soort verschroeide aarde tactiek. Ook haal je dingen uit zijn context.
MFA is sowieso en altijd beter dan geen MFA. Jammer dat je die boodschap steeds van tafel veegt met "wat als" redeneringen. Je vergelijking is steeds scheef. Bottomline is met MFA veiliger (veel zelfs) dan zonder.

Dit , met veelal links naar (eigen) reacties.

Daarnaast wil je defence in depth, dus meerdere maatregelen, zoals MFA en sterke unieke wachtwoorden. Nu is dat laatste helaas niet af te dwingen, terwijl MFA wel technisch af te dwingen is. En omdat Bob van HR bij iedere phishing mail zijn gegevens achterlaat, met daarbij een wachtwoord wat voldoet aan de complexiteit maar eenvoudig te raden is, is MFA toch echt wel een nuttige toevoeging. Vraag maar aan de universiteit van Maastricht.

Helaas kan ik op security.nl geen afbeeldingen laten zien.

Voor geïnteresseerden: onderin in https://infosec.exchange/@ErikvanStraten/113204242529188240 heb ik screenshots opgenomen die laten zien hoe Autofill onder Android en iOS reageert op de eerdergenoemde lîdl_be phishing loginpagina (in deze reactie vervang ik de punt tussen lîdl en be steeds door een laagliggend streepje, ook bekend als underscore).

    Inlogger <—> lîdl_be <—> lidl.be

Indien een slachtoffer niet ziet dat lîdl_be (in de adresbalk) een î (i.p.v. een i) bevat, kunnen Autofill en een wachtwoordmanager helpen voorkómen dat het slachtoffer in deze phishingaanval trapt - door (specifiek in dit geval) de Punycode domeinnaam te tonen, maar sowieso doordat de wachtwoordmanager de domeinnaam niet herkent indien je, voor die exacte domeinnaam, geen "wachtwoord" (record in de wachtwoordmanager-database) hebt aangemaakt.

Merk op dat als de echte lidl.be MFA middels TOTP of SMS zou ondersteunen (ik weet niet of lidl.be dat doet), dat niet hoeft te voorkómen dat de inlogger daadwerkelijk slachtoffer wordt. Steeds vaker zijn phishingsites "interactief": zodra de inlogger diens e-mailadres en wachtwoord heeft ingevoerd en op de "Login" knop heeft gedrukt, gebruikt de software op lîdl_be die gegevens onmiddellijk om in te loggen op de echte lidl.be website.

Als die echte lidl.be vervolgens om een 2FA/MFA code vraagt, is het een koud kunstje voor de software op lîdl_be om dezelfde vraag aan de inlogger voor te leggen. Zodra de inlogger diens 2FA/MFA code op lîdl_be heeft ingevuld, stuurt lîdl_be ook die onmiddellijk door naar de echte lidl.be.

Als die 2FA/MFA code correct is, zal lidl.be een authenticatie-token terugsturen - naar lîdl_be. Met dat token kan de aanvaller (de software "op" lîdl_be) het account op lidl.be van het slachtoffer, geheel geautomatiseerd, overnemen (en desgewenst de inloggegevens daarvan wijzigen om het slachtoffer buiten te sluiten).

Overigens weet ik niet of die lîdl_be website echt een phishingsite is, of dat deze voor trainingsdoeleinden wordt ingezet.

Een mooi voorbeeld van wanneer MFA niet helpt, maar een goede wachtwoordmanager wel. Wel even de volgende kanttekeningen:
- Dit is een vrij gerichte aanval. Natuurlijk komen die veelvuldig voor, maar zelfs met de beschikbare tooling vereisen ze de nodige kennis om goed uit te voeren, zoals een goede phishing mail.
- Er is social engineering voor nodig om de gebruiker naar de URL te laten gaan.
- Technische maatregelen kunnen, zoals bijvoorbeeld het melden of blokkeren van inlogpogingen van vreemde locaties, kunnen de slagingskans verminderen.

Maar zoals gezegd, MFA helpt hiertegen niet. MFA helpt wel tegen bijvoorbeeld aanvallen waarbij usernames worden verkregen door username enumeratie en wachtwoordlijsten gebruikt worden om toegang te bruteforcen. Dit soort aanvallen zijn veelal voor een grotere groep actoren op te zetten, omdat deze minder kennis vereisen, en vinden dan ook veel vaker plaats.

MFA kan dus geen toevoegde waarde hebben bij gedecideerde en gerichte actoren, maar vaak zijn dit actoren die als ze binnen komen, meerdere manieren proberen. En juist daarom wil je MFA, naast wachtwoord managers en sterke wachtwoorden. Je wilt namelijk zo veel mogelijk maatregelen om het kwaadwillende zo moeilijk mogelijk te maken.

Ik weet niet of die "lîdl" aanval gericht was of niet.

Ik weet ook niet of je 120.000 Microsoft-klanten nog "gericht" kunt noemen (https://www.bleepingcomputer.com/news/security/evilproxy-phishing-campaign-targets-120-000-microsoft-365-users/, meer links in https://tweakers.net/nieuws/218350/nederlandse-overheid-start-campagne-voor-promotie-tweestapsverificatie.html?showReaction=19586998#r_19586998).

En bijvoorbeeld bij de vele postpakket- en bunq-phishing-scams (voor die laatste zie https://security.nl/search?keywords=bunq+phishing&c%5B%5D=1&c%5B%5D=3&c%5B%5D=4).

De logica van die laatste drie regels ontgaat mij.

M.b.t. de tweede regel: de praktijk is dat mensen, die zwakke wachtwoorden (her-) gebruiken, en zij dáárom worden aangeraden (of verplicht worden) om zwakke 2FA/MFA te gaan gebruiken (notabene zonder hen op de nieuwe risico's daarvan te wijzen), JUIST niets aan die wachtwoorden gaan doen. En dus geen wachtwoordmanager gaan gebruiken. En dus zeker geen wachtwoordmanager die op domeinnamen checkt. Waarom zouden ze? Met MFA/2FA ben je toch safe?

Of de Politiehack het gevolg was van een phishingaanval, weet ik niet - maar steeds meer organisaties zijn in de wolken zonder zich (voldoende) te realiseren dat daarmee élke werknemer een SPOF (Single Point of Failure) wordt (zie ook https://infosec.exchange/@ErikvanStraten/113220145667244882).

Gezien de lengte van deze draad stel ik voor om deze discussie voort te zetten in https://security.nl/posting/859906/Speculatie_over_Politie-hack (maar hier mag natuurlijk ook).

Ja, dat kan je gericht noemen. Er wordt namelijk de nodige moeite gedaan om tot resultaat te komen. Dit in tegenstelling tot ingerichte aanvallen waarbij men probeert bij login pagina’s binnen te komen d.m.v. bruteforcing of password spraying.

Ja dat blijkt, want schijnbaar kan of wil je het concept van defense-in-depth niet begrijpen.
Nee, want zonder MFA gaan ze wel sterke wachtwoorden en een wachtwoordmanager gebruiken? Heb jij ooit mensen ontmoet?

Maar goed, we kunnen deze discussie tot in de eeuwigheid blijven voeren, het heeft er alle schijn van dat jij namelijk geen praktijkervaring hebt met informatiebeveiliging. Dat kan, en dat mag, alleen je komt telkens met argumenten die in de praktijk gewoonweg niet werken.

Onlangs konden we lezen dat de Yubikey gekraakt kon worden, en dus was de Yubikey voor sommigen niet meer het geëigende beveiligingsinstrument. Wie verder dan zijn neus las, kon lezen dat de kraker(s) daarvoor op het financiële, operationele en logistieke niveau van de CIA zou moeten zitten, om die Yubikey te ontrafelen. Lariekoek dus.
Ook hier weer valide en invalide argumenten, die voor mensen zoals mij niet zijn te snappen, maar ik las één suggestie die simpelweg als de meest realistische en veilige oplossing werd genoemd, en dat is de hardware sleutel.

Een hardware sleutel die de eigenaar zelf met een wachtwoord beschermd, ingeval deze in handen van anderen valt, en daaraan alle instanties waar men zich moet identificeren en inloggen in is opgeslagen.
Dit is gewoon de meest veilige en gebruiksvriendelijke optie, maar dan moeten al die instanties daarvoor wettelijk worden verplicht om die mogelijkheid te implementeren.

Het is niet de meest veilige authenticatieoptie, want, alles afwegende, denk ik dat clientcertificaten dat zijn.

Het risico op account-lockout is bij hardware keys (uitsluitend geldig indien WebAuthn gebruikmaken) ook groot, omdat je er geen backups van kunt maken. Omdat mensen ze makkelijk kwijt kunnen raken, ze verouderen (qua ondersteunde protocollen en hardware interfaces) en ze gewoon kapot kunnen gaan, heb je er minstens twee van nodig (die je zelf gesynchroniseerd moet zien te houden) - tenzij er een alternatieve -zwakkere- inlogmethode bestaat (dat is bijna altijd het geval, wat het argument voor hardware keys, passkeys en clientcertificaten volledig ondergraaft).

Bovendien zullen veel mensen een pincode i.p.v. een wachtwoord gebruiken om hun hardware key te unlocken.

Last but not least: als het apparaat (met beeldscherm en invoermogelijkheid) waarmee je inlogt gecompromitteerd is, is de kans groot dat een hardware key niet helpt voorkómen dat jouw online account(s) worden overgenomen.

Linksom of rechtsom is betrouwbare online authenticatie hartstikke ingewikkeld, en is het m.i. onverstandig om elke medewerker op phishable cloudaccounts te laten inloggen (temeer omdat de meeste mensen het phishingprobleem niet serieus willen aanpakken).

Met vereenvoudigingen zoals "gebruik (zwakke) MFA" of "Een hardware sleutel [...] is gewoon de meest veilige en gebruiksvriendelijke optie" gaan we dit -grote- probleem niet oplossen.

Ik heb het een en ander aan MFA methoden moeten gebruiken en als je praat over gebruikersvriendelijkheid dan zijn hardware sleutels (YubiKeys) zeer vriendelijk voor de veiligheid die ze meebrengen voor gebruiker authenticatie. (Reservesleutel nodig!) Client certificaten zijn ook nuttig, maar private keys daarvan kunnen makkelijker gestolen worden. (En je wil onder vrijwel alle omstandigheden verificatie dat de PC waarachter je gebruiker ziet niet besmet is met MITM malware...)

Als je analoog steeds verder afstompt,
hoe kun je dan digitaal bij en veilig blijven?

Kan iemand mij dat is uitleggen,
ik zie alleen maar meer dystopie.

Ja, je kan de hardware sleutel kwijtraken, of hij gaat kapot, bijvoorbeeld, je laat hem bijvoorbeeld per ongeluk vallen, en er komt net een grote bus voorbij die erover heen rijd, of je laat hem vallen, en voordat je hem kan oppakken komt er een kraai aanvliegen die hem voor je neus wegkaapt. Als je maar genoeg fantasie hebt, kan je honderden scenarios bedenken, om je gelijk te halen.

M.b.t. dat laatste: precies.

Maar dat aan het feit dat private keys niet gestolen kunnen worden (omdat zij in hardware keys zitten, of zoals bij passkeys op smartphones / PC's door speciale hardware zoals TPM's worden beschermd) heb je nul-komma-niks omdat elke AitM, na inloggen door jou, de door de server verzonden authenticatie tokens (zoals een session cookie) kan kopiëren (of onderscheppen) en misbruiken.

Het argument "public key encryptie" van clientcertificaten, passkeys en hardware keys is Haarlemmerolie (aka snake oil). Nog even los van dat een aanvaller met toegang tot jouw (of alle) accounts op een server, public keys kan toevoegen of vervangen.

De kracht zit hem, in de eerste plaats, in het herkennen van geauthenticeerde domeinnamen.