Dan liever een PassKey.

Ik ben groot voorstander van hardware security keys...
maar bij PassKeys is de naam veelzeggend: 2FA downgraden naar 1FA - zoals bij Google het geval is.

Toegang tot mijn smartphone om iets op een computer te mogen doen?
Nee, hartelijk bedankt!

Nieuwe technologie, zelfde kwetsbaarheden.

Ik kan niet geloven dat QR codes inscannen opeens veilig is. Omdat je altijd een man-in-the-middle probleem blijft houden bij encryptie hoe goed je je best ook doet.

Zoals ze vroegen zeiden bij het ontwerpen van een encryptie algoritme: Iedereen kan een encryptie algoritme bedenken dat ze zelf niet kunnen kraken. Dat betekent niet dat niemand het kan kraken. Dat geldt dubbel voor beleidsmakers.

Het helpt tegen SIM-swapping maar niet tegen nepwebsites (zoals ik ook al beschreef in https://security.nl/posting/877590):

1) Echte Google site toont QR-code;

2) Phishing Google website toont kopie;

3) User scant QR-code en voert code in;

4) Eigenaar van nepsite logt in op de echte Google site.

Zonder channel-binding is authenticatie zeer zwak; impersonatie ligt dan voor de hand.

@Google
Maak het internet veiliger, geef mensen de mogelijkheid om nepwebsites van echte te kunnen onderscheiden op basis van méér dan slechts een domeinnaam - zoals ik beschreef in https://security.nl/posting/876914.

Als je zelf domeinnamen zoals translate·goog gaat gebruiken, hoe moeten mensen dan weten dat bijv. de volgende websites, die op 21-02-2025, allemaal gehost werden op een server van "Google Cloud Hosting" in Finland [1], niet van Google of van andere volstrekt duidelijk geïmpersoneerde partijen zijn? Als je hier maar door mee blijft gaan (al sinds medio 2024), ben je dan niet ordinair medeplichtig aan cybercrime?


Voor een beter/korter overzicht heb ik de meeste subdomeinnamen verwijderd, in elk geval zijn dat: admin., analytic., checkout., demo., emv1., explore., google., insight., intelligence., mail., news., payments., stats., superset. en www..

Een '#' kan een willekeurig cijfer zijn, en een '?' staat voor een willekeurig cijfer, een spatie of niks.

Eerder schreef ik hierover in https://infosec.exchange/@ErikvanStraten/113837934294209517.

[1] https://www.virustotal.com/gui/ip-address/35.228.45.159/relations (open het "RELATIONS" tabblad als dat niet vanzelf gaat met deze URL).

Is het alias geven aan een domein dan een oplossing?
Dat ik bijvoorbeeld security.nl de naam "cybernieuws" geef, en dat dit dan een soort super-bookmark word?
Dan word de URL vervangen door dat de naam die jij gegeven had en krijgt de balk een (zelf-gekozen) kleurtje.
Op die manier herken je direct of je wel op de website bent waar je verwacht te zijn.

(Oftewel, een domein-brede bookmark met sterke visuele indicatie.)

Waarom via een QR code en niet gewoon via TOTP? Bij een QR code is een smartphone verplicht en waarschijnlijk moet je online zijn (en vermoedelijk Google Mobile Services aan hebben staan). Allemaal niet nodig bij TOTP, dat ook zonder smartphone gebruikt kan worden. Alles om de arme Gmail gebruikers verder het Google ecosysteem in te rommelen.

Daar ga je de mist in omdat er volgens het artikel niets is wat de gebruiker moet invullen bij de nieuwe methode.

Volgens Google:

Hoe dit exact geïmplementeerd wordt, lees ik echter nergens.

Ja het is weer erg onduidelijk allemaal.
Dat op zich is al weer een ernstig veiligheidsprobleem dat Google dus zelf veroorzaakt.
Want als ingelogd zijn bij Google vereist is om in te loggen op je Desktop computer, hoe log je dan in bij Google op je telefoon?!

En dat allemaal omdat SMS zogenaamd zo onveilig zou zijn.

Ze willen gewoon toegang tot je smartfoon. Dat is het hele verhaal.
Waarom zou je nog bij google in willen loggen? Dat is aan deze kant toch wel zeker 20 jaar terug dat ik dat voor het laatste gedaan heb - of een product van hun gebruikt natuurlijk...

Nee.

Dat hadden we ooit, zie het plaatje bovenin https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/.

Alle nitwits logen toen dat dit probleem werd veroorzaakt door EV-certificaten, maar dat is absurde onzin.

Het beschreven probleem had twee geheel andere oorzaken:
1) Dat de VS geen federale KvK heeft die voorkómt dat je in twee verschillende staten "Stripe, Inc" kunt registreren;

2) Belangrijkste oorzaak: een user-interface-probleem. In browsers (vooral Apple minimalist Safari) werd er te veel identificerende informatie WEGGELATEN - die wel in het certificaat stond: https://crt.sh/?id=273634647. (Ik ga daar mogelijk binnenkort nog eens uitgebreid op in).

Van oudsher was een domeinnaam simpelweg een alias voor een IP-adres. Met als reden dat mensen makkelijker namen dan getallen kunnen onthouden.

De vakgroep-webserver die ik tot begin 2004 beheerde had meerdere domeinnamen, waaronder:

    www.do.tn.tudelft.nl

Zie bijv. https://web.archive.org/web/20031229035918/http://www.do.tn.tudelft.nl/.
Als ik het mij goed herinner resolvde die domeinnaam naar 130.161.188.143.

In het begin van internet was er geen DNS. Je had een hosts file op de (Unix) computer met daarin één of meer domeinnamen gekoppeld aan een IP-adres. Toen er meer en meer computers op "internet" verschenen, schaalde dat niet meer (het lijkt mij goed om in spannende tijden, bijv. met oorlogsdreiging, te weten dat je ergens op kunt terugvallen mocht DNS stoppen met werken).

Want zo'n hosts file werkt nog steeds -naast DNS- (op niet-geroote smartphones heb je helaas geen toegang). Als je in jouw hosts file de volgende regel toevoegt:
, je vervolgens wie.waar invoert in de adresbalk van jouw browser en op Enter drukt, kom je uit op déze site (*), https://security.nl (die jouw browser overigens meteen doorstuurt naar https://www.security.nl op 82.94.191.109).

(*) Als je jouw browser veilig hebt geconfigureerd moet dat tot een waarschuwing en/of certificaatfoutmelding leiden, net als het openen van de volgende websites:
http://82.94.191.109
http://82.94.191.110
http://http.badssl.com
http://gemeente.amsterdam


Een domeinnaam zegt, in potentie, net zo weinig over de huidige "eigenaar" als een autokenteken of een telefoonnummer (omdat mensen slecht zijn in het onthouden van getallen, hebben wij een lijst met contacten op onze telefoons - namen gekoppeld aan telefoonnummers).

Net als autokentekens en telefoonnummers (beide gegeven een specifiek land) zijn domeinnamen (wereldwijd, mits er niks fout gaat) uniek.

En dat is handig, want één van de aliases voor mijn entiteit, "Erik van Straten", is niet uniek (er zijn meerdere Nederlanders die zo heten). Nb. op déze website bestaat er maar één account exact genaamd "Erik van Straten" (een naam die ik overigens ongestraft kan wijzigen, doch uitsluitend in een nog niet op deze site in gebruik zijnde naam).

Echter, waar namen IRL (In Real Life) meestal niet van entiteit (eigenaar) wisselen, kan een autokenteken, telefoonnummer of domeinnaam morgen van een ander zijn (dat geldt bijv. ook voor een vestigingsadres). Je kunt zelfs je geslacht laten veranderen (en dan vaak ook je voornaam).

Voor betrouwbare authenticatie heb je simpelweg méér informatie nodig dan één alias (domeinnaam), vooral als criminelen doodsimpel aan "lijkt-op" of "zou-kunnen-zijn-van" aliases kunnen komen, en daar probleemloos hosting en certificaten voor verkrijgen.

Als in een betrouwbaar certificaat onder meer "bank" zou staan, kan ik aan minder ervaren mensen uitleggen dat als "bank" niet in het certificaat staat, het dus géén "bank" is. Dat zou al veel kunnen schelen.

Let op: een (hopelijk betrouwbaar) authenticerend certificaat van een bank zegt niets over de betrouwbaarheid van die bank. Noch garandeert deze dat de website niet gehacked is en de beheerders betrouwbaar zijn. Maar met een certificaat weet je wél redelijk zeker met wiens website jouw browser een beveiligde verbinding heeft. Mooier kunnen we het niet eenvoudig maken (onafhankelijke organisaties, zoals (in opdracht van) https://thuiswinkel.org, de boel regelmatig laten auditten, kost nog véél meer geld).

Het schaalt niet en is absurd dat elke internetter maar moet zien uit te vinden of een gegeven domeinnaam van een gesuggereerde (o.a. in nepmails, nep-QR-codes en nepwebpagina's) organisatie is. Dan kan je leuk "blocklists" op je website zetten, zoals te zien is in bijvoorbeeld https://www.ggn.nl/contact/phishing/, maar:

a) Bijna niemand gaat daar kijken (zeker niet uit de doelgroep van scammers). Trouwens, waarom zou ggn.nl wél de echte domeinnaam zijn van GGN? Immers, ICS heeft icscards.nl als domeinnaam, CaK heeft hetcak.nl en MitZ heeft mijnmitz.nl (zie https://security.nl/posting/876502). Hoe moet je dat weten?

b) Elke site met zo'n lijst loopt voortdurend achter de feiten aan; scammers verzinnen steeds nieuwe domeinnamen - die de meeste internetters überhaupt niet bekijken. En als zij dat wel doen, kunnen zij die zelden correct interpreteren (vaak kennen mensen het verschil tussen een '-' en een '.' niet - of niet snappen dat als je, in lidl.be de eerste vier letters vervangt door lîdl, je op een nepsite uitkomt).

Alleen als je exact weet hoe een domeinnaam moet luiden, heb je er wat aan (zoals ik beschreef in https://security.nl/posting/877017). Maar als je daarentegen niet weet dat je beslist géén passkey moet aanmaken op bijvoorbeeld google.mypasskey·info (na een bericht schijnbaar afkomstig van Google met de melding dat er een probleem is met jouw Google passkey), heb je potentieel een enorm probleem - in elk geval zolang Google één of meer andere inlogmethodes toestaat dan met jouw bestaande passkey.

En dat Google dat doet is logisch, want hun passkey-implementatie zuigt; je kunt in één klap al jouw Android passkeys kwijtraken (en dan zou je niet meer in kunnen loggen).

Ehhm, ik bedoelde eigenlijk dat de gebruiker ZELF een naam en kleurtje geeft aan een website.
Op die manier heeft men het heel snel door als hij op een namaak website komt.
Want de domeinnaam komt dan niet overeen, dus de "gebruikelijke" naam en kleur missen dan, en dat valt op!

Waar bookmarks enkel op de specifieke URL werken, stel ik dus een "website-brede bookmark" voor.
Dan als je op dat domein zit, ongeacht de pagina, krijgt de URL balk het kleurtje en staat er de zelf gekozen naam.
(En bij het maken van zo'n bookmark krijgt de gebruiker dan uiteraard ook de informatie uit het certificaat te zien.)

Een bookmark maken, of iets zoals jij voorstelt, heeft pas zin als je (op welke manier dan ook) reeds van een domeinnaam wéét van wie die is, en hebt besloten de eigenaar van die domeinnaam (tot op zekere hoogte) te vertrouwen.

Als je op internet bijv. naar skikleding zoekt en mogelijkerwijs https://skicollectie·com vindt, moet je nu een soort forensisch onderzoeker zijn om uit te vinden dat het om een nepwebshop gaat die "Montec" skikleding zegt te verkopen.

Als ik op https://google.com zoek naar montec skikleding, vind op de tweede plaats (helaas kan ik hier geen screenshot tonen, dus ongeveer het volgende):

Het lijkt bij die laatste om een dropshipping website met een Spaanse eigenaar te gaan, maar daar wordt geen enkel bewijs voor geleverd.

Mensen, die de risico's en opbouw van domeinnamen (inclusief IDN's met Unicode) onvoldoende begrijpen, ontvangen phishing-berichten, klikken op links in zoekresulraten of social media, of scannen QR-codes. Daarbij kan het om http-links gaan (met hijack-risico in browsers met default instelling) en/of om URL-verkorters. In beide gevallen kan jouw browser naar een website met een volstrekt onvoorspelbare domeinnaam worden gestuurd.

Mijn voorstel behelst hetzelfde als de manier waarop onze overheid legitimatiebewijzen (o.a. paspoorten) uitgeeft. Beslist niet 100% betrouwbaar, maar een certificaat met een domeinnaam erin is als een paspoort met uitsluitend een paspoortnummer: uniek maar waardeloos.