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.

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.