Veilig inloggen - Security.NL (2024)

Lees niet alle "10 vuistregels voor wachtwoorden" van de Begische politie in [1] (bron: [2]). Mijn advies:

1) Onbetrouwbaar apparaat = Game Over

Wat u ook doet, zorg dat het apparaat dat u gebruikt om op accounts in te loggen en/of betalingen te doen en/of persoonsgegevens in te vullen, daar veilig genoeg voor is en blijft. Eén foute app met teveel permissies kan rampzalig zijn; de maker daarvan kan uw gegevens kopiëren en zich mogelijk voordoen als u (en zo zelfs uw bankrekening(en) plunderen).

Nb. Ook als u géén wachtwoordmanager gebruikt, of in plaats daarvan passkeys, of FIDO2 hardware keys of client certificaten, kan het desastreus zijn als het door u gebruikte toestel gecompromitteerd is (d.w.z. software van een kwaadwillende derde partij toegang tot dat toestel en andere software daarop heeft). Een betrouwbaar toestel is een voorwaarde om, maakt niet uit welke, handeling voldoende veilig uit te kunnen voeren.

2) Gebruik een betrouwbare wachtwoordmanager

Gebruik een wachtwoordmanager waar u de makers van vertrouwt en verwacht te kunnen blijven vertrouwen (zie ook de disclaimer in 4).

3) Nepsoftware

Laat u in elk geval niet foppen door een "lijkt op" wachtwoordmanager, gemaakt door criminelen, te downloaden en te installeren. Ga niet "ff googlen" en laat u niet foppen met foute apps, die af en toe zelfs in de Google of Apple stores kunnen staan.

4) Kies een WW-manager die domeinnamen checkt

Kies een wachtwoordmanager die, op basis van de domeinnaam van een website, automatisch de bijpassende inloggegevens opzoekt (voor Android is dat bijvoorbeeld KeePassDX, en voor iOS/iPadOS bijvoorbeeld KeePassium; voor geen van beiden is een browser-plugin vereist, mits in het besturingssysteem de juiste instellingen zijn geconfigureerd). Daarmee kunt u de manier van inloggen bijna net ze sterk maken als bij passkeys, maar zonder de nadelen van genoemde passkeys [3].

Disclaimer: niemand (dus ook ik niet) kan garanderen dat nu (ogenschijnlijk) betrouwbare ontwikkelaars van een wachtwoordmanager betrouwbaar blijven, geen kwetsbaarheden (onbewust of bewust) in hun software hebben aangebracht en dat nooit zullen doen, en zij zich nooit zullen laten hacken (maar dit alles geldt voor alle software die u -al dan niet bewust- gebruikt, inclusief besturingssysteem en drivers voor hardware).

5) Nepwebsites: voorkóm dat u in phishing trapt

Indien u een wachtwoordmanager gebruikt die, zodra u probeert in te loggen, checkt welke website er in het vóórste tabblad van uw browser geopend is, geldt het volgende.

Kijk en onthoud hoe die wachtwoordmanager reageert als u op een website, waarop u géén account heeft, probeert in te loggen. Bijvoorbeeld, als u géén account heeft op https://security.nl, klik dan rechts boven op "Inloggen". Nadat u de wachtwoorddatabase hebt ontgrendeld, hoort die website dan niet door uw wachtwoordmanager "herkend" te worden (en login-gegevens voor te stellen). Echter, meestal kunt u vervolgens wél zoeken naar inloggegevens in de wachtwoorddatabase - hetgeen meestal zéér onverstandig is (laat u ook niet foppen door een nepsite die liegt dat er een problerm is met de echte website, en de eigenaar daarom tijdelijk naar een andere domeinnaam is "uitgeweken").

Wat u hebt zien gebeuren is hetzelfde als dat u een phishing (nep-) website in uw browser geopend zou hebben. Als u inloggegevens bestemd voor een andere website met een nepwebsite deelt, is de kans zeer groot dat uw account op de echte site wordt gekaapt (zie bijv. "Instagram en Facebook nog steeds niet opgewassen tegen simpele phishing" vandaag gepubliceerd door Joost Schellevis in [4]).

Het volgende voorbeeld maakt dit hopelijk duidelijk. Stel u hebt een account op
https://example.com. Op een gegeven moment krijgt een overtuigend phishingbericht met daarin een link naar
https://example.net, en stel dat u niet (meer) weet dat dit niet de juiste domeinnaam is van de, in het bericht, gesuggereerde eigenaar (organisatie) van de website. Als u op die foute link klikt, kan het volgende gebeuren (ik ga ervan uit dat u een browser op uw smartphone gebruikt, maar dit kan net zo goed op een tablet, laptop of vaste PC zijn):

Uw browser maakt hierbij verbinding met een "mini-server" van de aanvaller, een "twee-richtingen doorgeefluik" dat ook wel een "proxy" of een "proxy-server" wordt genoemd (ik noem zoiets een "evilproxy").

De computer van de aanvaller doet zich voor:

• Richting uw browser: als een (potentieel exacte) kopie van de webpagina van de echte webserver (Nb. de aanvaller heeft géén invloed op de in de adresbalk van uw browser getoonde domeinnaam. In zoverre, de aanvaller kan uw browser (op elk gewenst moment) doorsturen naar elke andere website, maar dan heeft die aanvaller geen invloed meer op de vervolgens getoonde pagina en kan niet meer "zien" wat u invoert. Ook kan de aanvaller daarna uw browser niet "terughalen" naar diens nepserver).

• Richting de bedoelde webserver: als uw browser (soms maken aanvallers gebruik van een extra "transparante proxy" tussen hun nepserver en de echte server, om de server te laten denken dat u inlogt vanaf een IP-adres dat geografisch bij dat van u in de buurt ligt (zie [5]).

Zélfs als u met 2FA (d.w.z. dat u, naast met een wachtwoord, met een SMS-code, TOTP-code of via een push-bericht) inlogt op de nepsite (die als twee druppels water op de echte kan lijken), kan de aanvaller "in het midden" daarmee op de echte website inloggen en uw account kapen (technisch: de aanvaller kan, als alternatief, alles heen en weer doorgeven en, nadat u bent ingelogd, uw "session-cookie" kopiëren en dat vervolgens misbruiken om de sessie van uw browser op de echte server te klonen of over te nemen).

6) Maak backups van de wachtwoorddatabase

Verzeker u ervan dat, na elke wijziging in de wachtwoorddatabase, deze op minstens twee plaatsen wordt opgeslagen (meestal op het apparaat zelf en in een cloud-account). Maak daarnaast regelmatig minstens één offline backup van die database.

7) Ontgendel-WW voor WW-database moet sterk zijn

Gebruik een sterk wachtwoord (zie [6]) voor het ontgrendelen van de wachtwoorddatabase. Overweeg om biometrie als alternatieve ontgrendelmogelijkheid te gebruiken; dat levert extra risico's op, maar als het daardoor acceptabel wordt om een langer wachtwoord voor het ontgrendelen van de wachtwoorddatabase te gebruiken (ter bescherming van op onveilige plaatsen opgeslagen backups van die database, zoals in cloud-accounts), dan kan dat een verstandige keuze zijn.

8) Lange random WW, met keuze uit véél karakters

Laat de wachtwoordmanager, voor elk account, een willekeurig wachtwoord genereren, dat voldoet aan de volgende eisen:
• Zo lang mogelijk als wordt toegestaan door de betreffende website;
• Waarbij de wachtwoordgenerator (naast uit '0'..'9', 'a'..'z' en 'A'..'Z') uit zoveel mogelijk leestekens kan kiezen, dus uit spatie, maar uit zoveel mogelijk in:

D.w.z. voor zover toegestaan door de betreffende website (alles op de tweede regel, dus vanaf '€', is zelden toegestaan).

Nb. Uitvinden wat de maximale lengte is en welke tekens (of combinaties daarvan) een website toestaat, kan een heel gedoe zijn (de foutmeldingen zijn vaak nietszeggend). Zie ook [7] (waarop u, desgewenst, ook zelf stupide sites aan de schandpaal kunt nagelen).

9) Verplicht gebruik van "https://" door uw browser

Stel uw browser, indien mogelijk, zo in dat uitsluitend "https://" wordt gebruikt als u op een link zonder zo'n (communicatieprotocol-) voorvoegsel klikt, en zelfs als u op een link klikt die met "http://" begint.

Als u uw browser goed instelt, en op de volgende link klikt:
http://http.badssl.com/, dan moet uw browser u waarschuwen dat er geen "https://" verbinding mogelijk is (zie ook het voorbeeld onder 11.a). Bij normale (niet test-) websites kan dat namelijk twee dingen betekenen:

a) De website ondersteunt echt geen "https://" (dat is absurd, zie ook [8], nu gefixed);

b) Er "zit" een aanvaller tussen uw browser en de echte website:

Het "https://" protocol geeft een behoorlijke zekerheid dat uw browser daadwerkelijk verbinding heeft met de in de adresbalk van uw browser getoonde domeinnaam (daarnaast is die verbinding, tussen uw browser en de webserver met die domeinnaam, "End-to-End" versleuteld). Bij gebruik van het "http://" heeft u geen van beide zekerheden.

Vooral bij het gebruik van onbetrouwbare netwerken, zoals publieke WiFi, is dit een niet te verwaarlozen risico.

Merk op dat de aanvaller uw browser meteen kan doorsturen naar een derde website die ook op de computer van de aanvaller kan draaien en die wél van https gebruik maakt, zoals bijvoorbeeld https://login-example.com. Dit kan zó snel gaan dat u niet doorheeft dat uw browser door een htttp:// website is doorgestuurd, en u kunt denken dat de echte https://example.com website uw browser heeft doorgestuurd (naar de nepsite https://login-example.com). De situatie is dan veranderd in de omstandigheden zoals weergegeven in het "plaatje" onder 5).

10) Browser ondersteunt verplichte "https://" niet:

Log nooit in als er geen https:// verbinding wordt gebruikt. De meeste browsers laten het voorvoegsel "https://" (of zelfs "https://www.") wég uit de adresbalk. Onderzoek hoe uw browser het onderscheid toont tussen "https://" en "http://" verbindingen.

En nogmaals: indien u inlogt doch géén wachtwoordmanager gebruikt, of een wachtwoordmanager die niet de domeinnaam checkt (zie 5), dan moet u zelf de domeinnaam in de adresbalk van uw browser (dubbel-) checken (is die domeinnaam daadwerkelijk van de bedoelde eigenaar of organisatie - zoals beschreven onder 11).

11) Als u (nog) geen account heeft

Als u met uw browser verbinding maakt met een nepsite waarop u (nog) géén account heeft, kan uw wachtwoordmanager u niet helpen (zoals beschreven in 5) om vast te stellen dat het om de door u verwachte (en geen nep-) website gaat.

Zowel als het om een website gaat waarop u een account wilt gaan maken, als op een website waar u persoonsgegevens op moet invullen, als op een website die u om een betaling vraagt, is het in uw eigen belang dat u grondig checkt:

a) dat uw browser een "https://" verbinding heeft;

b) en dat dit met de juiste website is (en geen nepkopie daarvan). Dit laatste kan aan de hand van de, in de adresbalk van uw browser, getoonde domeinnaam.

Bijzonder lastig daarbij is het om, gegeven een domeinnaam, vast te stellen wie of welke organisatie eigenaar is van (c.q. verantwoordelijk is voor) een website. Vertrouw daarbij nooit op wat er in de webpagina(s) te zien valt; dat bewijst helemaal niets indien het om een nepsite gaat (zie ook [9] en mijn reacties daarop).

Enkele tips met betrekking tot een in de adresbalk van uw browser getoonde domeinnaam:

11.a) Geen hoofdletters

In domeinnamen kunnen formeel geen hoofdletters zitten. In links kan dat wel (voorbeeld: https://NOS.NL) maar nadat u op zo'n link klikt zal uw browser, in de adresbalk, de domeinnaam in kleine letters hebben omgezet. Nb. dit geldt niet voor wat er, verderop in een URL (achter de domeinnaam) volgt.

U kunt genept wordt met het bekijken van een link in bijvoorbeeld een bericht of in een webpagina - zoals bij
https://appIe.com (daarin zit een hoofdletter 'i' in plaats van een kleine 'L'). Ik heb die link "onklikbaar" gemaakt, maar als ik dat niet zou doen en daarop zou drukken (in Firefox op mijn Android smartphone), zou ik in de adresbalk links een hangslotje met een schuine rode streep er doorheen zien, gevolgd door:

ww25.appie.com/?subid1=202405… (de rest valt weg in portretmodus)

en daaronder (dit is een melding uit Firefox zelf, dankzij de instelling beschreven in 9):

De eerste regel is verschrikkelijke desinformatie van Mozilla: het "https://" protocol bevestigt de identiteit van de website en zorgt voor een versleutelde verbinding, maar zegt helemaal niets over de beveiliging van een website.

Als ik op de knop "[Doorgaan naar HTTP website]" druk, wordt mijn browser automatisch doorgestuurd naar uiteindelijk https://www.above.com/marketplace/appie.com, met een pagina waarin onder meer staat:

Maar of dat ook geldt als iemand (zoals AH?) daar genoeg voor over heeft, blijft de vraag (ook wat er gebeurt mocht de domeinparkeerder "above.com" ooit worden overgenomen).

11.b) Meer info over domeinnamen

In [10] vindt u aanvullende informatie over domeinnamen.

Referenties

[1] https://www.politie.be/5998/nl/nieuws/10-vuistregels-voor-wachtwoorden

[2] https://www.security.nl/posting/840165/Belgische+politie+raadt+aan+om+wachtwoorden+regelmatig+te+wijzigen

[3] https://www.security.nl/posting/798699/Passkeys+voor+leken

[4] https://nos.nl/artikel/2518932

[5] https://www.security.nl/posting/839626/Okta+waarschuwt+voor+grote+credential+stuffing-aanval+via+residential+proxies#posting839641

[6] https://security.nl/posting/839395

[7] https://dumbpasswordrules.com/sites-list/

[8] https://www.security.nl/posting/803597/werk_nl%3A+geen+https

[9] https://www.security.nl/posting/837727/Digitale+bankfraude+%28bunq%232%29

[10] https://tweakers.net/nieuws/216878/ministerraad-stemt-in-met-gebruik-gov-punt-nl-als-domein-voor-overheidswebsites.html#r_19450852