En zo meteen komen die emails dan van "opsporingsdienst@politle.nl" en gebruiken ze een andere smoes.
Nu zou ik hier zelf niet zo snel in trappen, maar genoeg mensen zouden dat wel doen. (Geheel begrijpelijk, helaas)

Ik hoop dat de pakkans van dit soort oplichting/phishing omhoog gaat zodat het minder voorkomt.

Maar de uiteindelijke kwetsbaarheid is dat echt-of-nep momenteel afhangt van de juiste spelling van het domein.
Niet iedereen is tech-bewust genoeg om te realiseren dat "politle.nl" een heel andere eigenaar heeft dan "politie.nl".
Het onderliggende principe van domeinnamen is prima, maar ik denk dat er een extra laag van identiteit overheen moet.

Je zou bijvoorbeeld email adressen kleurtjes kunnen geven op basis van geverifieerde identiteit.
Email adressen van de overheid krijgen dan een blauw kleurtje, banken krijgen een groen kleurtje, etc.
En je kan ook een kleurtje geven als je in het verleden wel eens een mail hebt gestuurd naar dat email adres.

Sarcasme: Ja, maar !!??, het komt van de overheid af !!

Als je bedoelt, dat een willekeurige oplichter opeens mails verstuurt via het topleveldomein "politie.nl", dan moet ik je toch teleurstellen, aangezien dit domein alleen beheerd kan worden door de politie en dat geldt ook voor het aanmaken van e-mailadressen met dit topleveldomein.

"Maak melding bij fraudehelpdesk"
Doen die er eigenlijk wat mee? Lijkt me echt zo'n instelling die de meldingen op de grote hoop gooien en er verder niets mee doen.

nou ze komen maar will ik mee maken.....

Je bewijst met je reactie dat Named gelijk heeft.
Sommige mensen zijn dyslectisch. Veel mensen letten gewoon niet op.

Dit wordt helaas ook nog eens gefaciliteerd door de algemene acceptatie van Domain Validated certificaten, die alleen maar vast kunnen stellen of iemand controle heeft gehad over het betreffende domein (met of zonder spelfouten of vreemde tekens), en sowieso NIET wie de eigenaar is van dat domein.

p o l i t l e . n l (met een kleine letter "L" op de 6e positie)
is iets anders dan
p o l i t i e . n l (met een "i" op 6)

En politie.nl is geen top-level domein, nl wel.

En een spammer/scammer kan wel degelijk een email sturen met als afzender adres iets "@politie.nl", maar deze zal vanwege SPF, DKIM en/of DMARC hoogstwaarschijnlijk als spam worden aangemerkt of worden geblokkeerd door de server van de ontvangende partij.

Lijkt erop dat ook jij gevoelig bent voor echt lijkende domeinen.
Daarnaast lijkt het dat je het bericht niet helemaal hebt gelezen.

... Niet iedereen is tech-bewust genoeg om te realiseren dat "politle.nl" een heel andere eigenaar heeft dan "politie.nl".
...

Dit is niet de eerste keer. Vaak kun je de aanklacht ook nog afkopen met een leuk bedrag in Bitcoins.

De eerste die ik heb gezien was een Waalse versie, daarna een Vlaamse, een Franse en de Nederlandse versie....en nog diverse andere versies zoals die van Europol.

U leest niet goed, er staat politle.nl (met een L ipv een I), veelgebruikte methode van phishers/scammers.

Er zijn al meerdere mailservers van grote instanties overgenomen waardoor de aanvallers vanaf legitieme adressen kon sturen.

Ik ben niet bepaald tegen DV certificaten. Ze hebben (via de Let's encrypt beweging) ervoor gezorgd dat momenteel praktisch gezien al het verkeer versleuteld is. Dit heeft de drempel voor AitM en vergelijkbare aanvallen flink verhoogd, wat de veiligheid en privacy ten goede is gekomen.

Wel heeft het het makkelijker gemaakt om via typosquatting voor te doen als iemand anders. Hier word al steeds vaker misbruik van gemaakt en ik denk dat we hier een oplossing voor moeten verzinnen. Het doel is helder: Er is duidelijkheid nodig over welke persoon of dienst iets stuurt en diens legitimiteit, en we zagen zojuist dat enkel vertrouwen op domeinnamen gewoon ontoereikend is... ;-)

Ik suggereerde al om email adressen een kleurtje geven, maar ik denk dat een label/certificaat meer details bied.
Je kan e-mailtjes van de overheid redelijk makkelijk labellen, dit is publiek bekende informatie.
Diensten die je zelf hebt afgenomen of mensen waar je op gereageerd hebt zijn ook een label te geven.
Mogelijk kan je alle financiële instellingen ook een labeltje geven?

Wie heeft nog andere ideeën om dit probleem aan te pakken?

Die worden door SIDN heel snel weer uit de lucht gehaald omdat er op gescand wordt.

Dit zijn asci-nazi's, variant van de taalnazi die op spellingsfouten controleert. Toch is het in sommige lettertypes gewoon niet te zien. Al of AI Zie jij het verschil? (kopieer tekst, en zet in ander lettertype en controleer wat er staat, dan zie je het wel. )

Vraag wat mij betreft is, kan je mensen aanrekenen, dat ze deze extra handeling niet uitvoeren?

Je hebt NIETS aan een versleutelde verbinding met een nepwebsite.

Bekijk eerst dit (binnenkort meer): "Cloudflare (maffiamaatje), Pulitzer en onzichtbare inkt" in https://todon.nl/@ErikvanStraten/115505157350541788.

Dit heeft de drempel voor technische AitM-aanvallen in een klein déél van de gevallen verhoogd, want:

De HELE WERELD publiceert links zónder dat er https:// vóór staat, o.a. in tijdschriften, kranten, op TV en in QR-codes (zie ook https://security.nl/posting/904650). Uit (notabene!) https://www.ing.nl/de-ing/veilig-bankieren/wat-kan-je-zelf-doen/check-het-gesprek:

https://internet.nl/site/mijn.ing.nl/3517194/: 66% (dat is heel laag voor https://internet.nl).

• Veel websites ondersteunen HSTS niet (o.a. http://google.nl en http://google.com) - of incorrect.

• HSTS implementaties in browsers zijn onbetrouwbaar. Zo kan er een limiet zijn aan het aantal records in de HSTS database van jouw browser. Meestal werkt HSTS überhaupt niet in private modus (Firefox Focus negeert HSTS). De tijd dat HSTS-records geldig blijven is zelden meer dan 365 dagen. Als je meerdere browsers (vooral op meerdere apparaten) gebruikt neemt de effectiviteit rap af. En je kunt eenvoudig (en ongemerkt) HSTS records in de database van jouw browser kwijtraken (o.a. door de browser-historie te wissen).

• HSTS werkt pas NÁ het eerste bezoek van een website [*].

[*] Terzijde: xs4all (KPN) flikkert een deel van de legitieme mails die ik ontvang in mijn spambox - maar zet dit type phishingmails steevast in mijn inbox:
De link onder al deze spams begint met http://.
WAAROM? OMDAT BIJNA NIEMAND EEN FOUTMELDING KRIJGT.

De default is browsers is nog steeds NIET WAARSCHUWEN bij http - een cadeautje voor technische AitM-aanvallers. Zoals bij http://gemeente.amsterdam.

Kennelijk pas volgend jaar een risico, uit https://security.nl/posting/911033/Google+Chrome+gaat+websites+volgend+jaar+standaard+via+https+laden:

P.S. DV-certs zouden nauwelijks een probleem zijn als internetters onderscheid konden maken tussen serieuze en JUNKSITES (altijd anoniem - voorbeeld van bulletproof hosting in https://todon.nl/@ErikvanStraten/115468542929986900). Maar dán zijn de vette (miljarden-) bonussen lastiger te financieren. Daarom laten browsers het NIET zien als een website bij een junkhoster "gevestigd" is. Cybercrime faciliteren is "niemands" schuld (terwijl er vet aan verdiend wordt) maar wel iedereens probleem.

#BigTechIsEvil

@Named en EricVanStraten

Het probleem en de oplossing ligt helemaal niet in certificaten en encryptie.

Het probleem (en oplossing) is dat iedere Jan Lul een domeinnaam kan registreren.
Ik heb dit al oeverloos beargumenteerd in o.a. topics van Eric.

Wij (mensheid) beroepen en schreeuwen wel om vrijheid maar kunnen er uiteindelijk niet mee omgaan.

Het eerste probleem is dat je ANONIEM een domeinnaam kunt registreren.

Maar degelijke authenticatie bij domeinnaamregistratie gaat om tal van redenen NIET HELPEN en is sowieso KANSLOOS.

Voorbeelden: domeinnamen zijn er niet alleen voor websites en het is volstrekt duidelijk wie de eigenaar is van *.pages.dev (en workers.dev), maar ook bijv.

https://sites·google·com/cryptowalllet·com/trezoriostart/home

(daarin heb ik elke punt door · vervangen).

In mijn antwoord op mijn eigen toot in https://todon.nl/@ErikvanStraten/115510068493747875 is een screenshot van die "sites.google.com" nepsite te zien.

Nb. deze sites WERKEN (anders waren het er niet zoveel) - de doelgroep is echter niet de bij het Kifid hoofdstotende bejaaijde maar de "intelligente" CryptoCoinJunk.

De oplossing zit m.i. in browsers die, bij het eerste bezoek (of relevante veranderingen) van een website met een specifieke domeinnaam, de bezoeker informeren over wie de verantwoordelijke is voor de op dat moment geopende website (na het ophalen en valideren van het certificaat plus checken van bezit van de private key, nog vóórdat überhaupt content is opgehaald) alsmede hoe betrouwbaar die informatie is.

Anonieme websites zijn (discutabel) prima. Maar als dat zo is wil ik dat WETEN, net zoals ik dat van een website wil weten met een verantwoordelijke.

Precies de reden waarom we voor real life een KvK hebben en voor internet uitsluitend kwaadaardige zakkenvullers.

#BigTechIsEvil

Nou, via KvK gegevens hebben ook veel ondernemers last gehad van spookfaktuurstuurders. Op een of andere manier waren die uitstekend op de hoogte als een bedrijf weer eens een nieuwe op de administratie had aangenomen.

Kwaadaardig zakkenvullers maken gebruik van het bestaan van het internet, dat is niet alleen BigTech.

Of valt de hele opgetuigde organisatiestructuur achter de NIS2 beweging daar ook onder?

Willie Whataboutism, hoe vaak denk je dat ik vermoed dat je jezelf stukken minder hebt verlaagd door met "je hebt gelijk" te antwoorden?

Naast dat je niet eens de vier letters van mijn voornaam kunt onthouden: tot ziens bij de eerstvolgende keer waarbij je -oeverloos- opnieuw hetzelfde raaskalt (ik beloof geenszins dat ik daar élke keer mijn tijd aan verspil).

Enjoy your simple life.

-
volgens mij als er genoeg melding over iets binnen komen dan worden er mails van jun uit verstuurt;

Nou, dat is wel héél erg recht toe recht aan gedacht. Het heeft niet alleen met tech-bewustzijn te maken.
Hoe kom je daar toch op?
Er kan ook ook iets anders; iets veel meer voor de hand liggend een negatieve rol spelen: Het zicht. Ofwel: Hoe is het gesteld met je ogen. (voor alle duidelijkheid: geen leesblindheid, dat betreft de mentale verwerking van wat je leest)

Ik zat mij volledig blind te staren op beide url's. Pas toen ik de weergavegrootte van deze pagina op 150% instelde zag ik dat de criminele url politIe.nl was.

Precies. Maar sowieso verbergen veel e-mail clients (vooral mobiele) het SMTP-afzenderadres. Als je een e-mail met Politie-logo ontvangt en op de link daarin geklikt hebt (en op dat moment nog niet twijfelde), ga je niet meer 150% zoomen om te kijken of in de URL balk staat wat jouw high speed Actual Intelligence denkt te zien (als je al kijkt). Achterdocht is geen standaard-eigenschap van mensen.

Daarnaast, of alle "technische" mensen snappen dat websitenamen (domeinnamen, de spatie vóór ".nl" is door mij tussengevoegd) zoals

    check-het-gesprek-politie .nl

en

    incasso-belastingdienst .nl

NIET van resp. de Politie en Belastingdienst zijn, waag ik ook te betwijfelen (over die laatste binnenkort meer).

Met de lockdowns is ook de cybercriminaliteit van huis uit sterk toegenomen.

Het handhavingsbeleid is echter afgezwakt.

G.J. van Eersum, je hebt gelijk, het is niet zozeer tech-bewustzijn, maar of het je opvalt.

Iedereen, zelfs de meest technisch aangelegde personen, zouden er overheen kunnen lezen. Het helpt dan ook niet bepaald dat email adressen worden verborgen of niet in monospace worden getoond. En ongelukkig gekozen lettertypen of Unicode homogliefen maken het al helemaal onmogelijk om op je ogen te vertrouwen.

Hierbij moeten we cyberveiligheid dan ook opdelen in 2 delen: technische veiligheid en gebruiksveiligheid.

TLS heeft de veiligheid op technisch gebied verbeterd, maar dit is nog niet perfect. Als ik bijvoorbeeld "https://example.com/" intyp in de adresbar, dan weet ik dat zelfs via onversleutelde WiFi bijna niemand met de data kan knoeien. Hier zitten nog een aantal haken en ogen aan, zoals dat HTTPS-only aan moet staan, maar over het algemeen zit dit wel snor.

De echte cyberrisico's voor de gemiddelde burger zit niet in technische aanvallen, maar in aanvallen die misbruik maken van gebreken in de user interface of in het gebrek aan IT kennis. Domeinnamen die "echt" lijken, verborgen afzender adressen, nagemaakte websites, neppe vertrouwenslabels, etc.

Hierin is het vertrouwen in de domeinnaam een kwetsbaarheid die uitgebuit word, maar dit is niet de enige reden. Sommige gebruikers kijken niet naar de URL-balk, maar naar de website zelf. Zij zijn zich dan niet bewust dat het een namaakwebsite is en volgen dan gewoon doodleuk de instructies die op de pagina staan.

De groep mensen die wel naar de URL-balk of email adres kijken zullen hier minder snel in trappen, maar voor hun is het lastig om te weten of een domein "echt" is of namaak. Het vallen voor "politle.nl" is maar al te gemakkelijk en dit is in mijn ogen een tekortkoming van de gebruikersinterface.

Voor deze domeinnaam shenanigans zie ik een aantal oplossingen:
1. Gebruik monospace fonts die duidelijke verschillen tussen vergelijkbare tekens hebben.
2. Toon altijd het email adres of de domeinnaam, het verbergen maakt gebruikers kwetsbaarder.
3. Als er Unicode in het spel is, kleur de tekens van een afwijkende groep dan rood.
4. Voeg labels toe aan domeinnamen die "officieel" zijn, zodat de legitimiteit van een een domein duidelijk is.


Onze overheid heeft zelf onduidelijk gemaakt welke website van hun is door geen enkele structuur te hebben.
Geen "<ding>.overheid.nl", maar "<ding>.nl" terwijl iedereen zelf een "<ding>.nl" kan aanmaken.
Je zou de lijst van overheidswebsites kunnen pakken en deze een kleurtje kunnen geven.
Dit geeft gebruikers dan tenminste houvast tegen phishing en andere oplichtingen die vanaf de overheid komen.
Maar dat is een halve oplossing, banken zijn dan onbeschermt...

Ja, dat heeft ook te maken met geopolitiek, cybercriminaliteit bestrijden, dat doe je met z'n allen, door samen te werken, zoals dat in het verleden gebeurde. Zowel met de Russen als Amerikanen als Israeli zijn er momenteel wat issues. Hebben ook met toepassingen van AI op het slagveld te maken. Die zijn allang niet meer experimenteel.

Dat het handhavingsbeleid is afgezwakt, en de financiele schade bij het slachtoffer komt te liggen, vind ik onverterteerbaar asociaal.

Dit tech-bewustzijn zou wel eens vaker in mainstreammedia aangestipt mogen worden, om iedereen te bereiken.

Het probleem met de hyphens is er ook zo een: - en _

Hele luie tekstschrijvers, laten ze gewoon staan, en andere mensen gebruiken ze expres om te suggereren dat het een AI gegenereerde tekst is.

Als je geheel AI-kopschuw bent -en daar hebben we er in onze security.nl community nogal wat van- dan valt het je waarschijnlijk niet eens op.

Je hebt het dan over de EM-dash (—), neem ik aan?
Zie: https://en.wikipedia.org/wiki/Dash#Usage_in_AI-generated_text
(Zelf gebruik ik deze nooit, want ik kan ze niet typen.)

Ik ook niet;)

Dat laatste is onjuist (met de rest van wat je schreef ben ik het grotendeels eens).

Als je zelf "https://example.com" (met of zonder / daarachter), intikt, ben je safe. Dan gebeurt namelijk het volgende:

1) De browser vraagt via DNS het IP-adres op van example.com. Aan mij gaf https://mxtoolbox.com/SuperTool.aspx?action=dns%3aexample.com als antwoord:
199.43.135.53

2) Alle actuele browsers proberen dan verbinding te maken met 199.43.135.53 op TCP poort 443 en een TLS-verbinding op te zetten. Ik ken geen enkele browser die, als TLS niet foutloos lukt, als alternatief http://example.com gaat proberen - ongeacht de browser-instellingen.

3) Er zijn nu twee mogelijkheden:

I - Wél een foutmelding uit de browser
Tijdens het opzetten van de https-verbinding gaat er iets fout. Denk hierbij bijv. aan een verlopen of "self-signed" certificaat. Of aan de situatie dat het certificaat ongeldig is voor de in de adresbalk van jouw browser zichtbare domeinnaam.
Voorbeeld: met https://wrong.host.badssl.com krijgt jouw browser een versleutelde TLS-verbinding, met die server, maar het door de server gestuurde certificaat (te zien in https://crt.sh/?id=21066306113) is ongeldig voor wrong.host.badssl.com en idem voor *.host.badssl.com (het is wél geldig voor badssl.com en *.badssl.com, maar daar "matcht" wrong.host.badssl.com niet op).

II - Géén foutmelding uit de browser
Het opzetten van de https-verbinding lukt zonder fouten. Daarvoor moet het certificaat geldig zijn, het moet geldig zijn voor de in de URL-balk getoonde domeinnaam én de server moet hebben bewezen te beschikken over de private key die past bij de public key die is opgenomen in het certificaat.

BELANGRIJK: pas als met de server (met de gegeven domeinnaam) een TLS-verbinding met succes is opgezet (situatie II), kan uitsluitend die server de browser redirecten (doorsturen) naar een andere webserver of content (zoals plaatjes of Javascript) laten ophalen van andere servers. Nb. in beide gevallen zijn dat vaak verzoeken die met https:// beginnen, maar er zijn nog steeds absurd veel servers die automatisch doorsturen met http-links - of die pagina's bevatten met daarin http-links. Ook veel QR-codes bevatten expliciet http-links of helemaal geen protocol-aanduiding, hetgeen de meeste (zo niet alle) browsers interpreteren als een http-link.

Dus zélfs als je https:// tikt vóór elke link die je zelf invoert: op een deel van de links waar je mee te maken krijgt heb je geheel géén invloed (denk bijv. aan een link naar een URL-verkorter die doorstuurt met een link die met http:// begint).

Naast het probleem dat ik direct hierboven beschreef: ik ken NIEMAND die begint met https:// te tikken - want kaal example.com werkt ook. Bijna altijd.

Bij expliciete http-links (of impliciete, als het voorvoegsel http:// ontbreekt), gebeurt het volgende:
a) De browser vraagt via DNS het IP-adres op (zie punt 1 hierboven).

b) De meeste (zo niet alle) actuele browsers proberen dan (ongevraagd) verbinding te maken met 199.43.135.53 op TCP poort 443 en een TLS-verbinding op te zetten. N.b. de meeste browsers proberen zelfs eerst https als de internetter expliciet http://example.com intikte of op een link klikte die zo luidde (of met http://example.com/ begon).

b]c)[/b] Als https niet lukt proberen alle browsers, zonder dat te melden - laat staan om toestemming te vragen, verbinding te maken met 199.43.135.53 op TCP poort 80 en zo een http-verbinding op te zetten - TENZIJ de standaard-browser-instelling "waarschuwen voor onveilige verbindingen" (of een vergelijkbare tekst) is aangezet. Dat is trouwens een instelling die in veel browsers überhaupt niet beschikbaar is (voorbeelden: Edge onder Windows, Firefox onder iOS/iPadOS, en Safari op oudere versies van iOS/iPadOS).

Dat https niet lukt kan allerlei redenen hebben, bijvoorbeeld:
• De server is echt offline;

• De server ondersteunt wél http maar niet https. Voorbeelden: http://gemeente.amsterdam en http://http.badssl.com (als je die URL's opent ben je kwetsbaar als jouw browser je niet waarschuwt);

• Een AitM (Attacker in the Middle) kan toegang hebben tot een netwerkapparaat tussen jouw browser en de bedoelde webserver (door zo'n netwerkapparaat te "hacken" of door een vals draadloos/WiFi access point op te zetten - waar je -onbedoeld- verbinding mee maakt). Zo'n AitM kan één (of meer) netwerkpakketjes tussen jouw browser en de bedoelde webserver blokkeren, denk aan https netwerkpakketjes (eenvoudig te herkennen aan het TCP-poortnummer 443). Jouw browser neemt dan aan dat die server https niet ondersteunt. Doordat de standaardinstelling van alle browsers "ongevraagd http proberen" is, kan de AitM zich voordoen als de http-variant van de bedoelde server - en jouw browser doorsturen naar een andere webserver (in bezit van de aanvaller) - meestal eentje die wel https ondersteunt. Dat gaat zó snel dat je niets ziet van de kortstondige terugval naar http - precies hetzelfde effect als je http://gemeente.amsterdam opent - met een niet waarschuwende browser.

• Er kan ook sprake zijn van een aanvaller op DNS-niveau. Dat kan een AitM zijn, maar dat hoeft niet: als een aanvaller een DNS-record kan wijzigen, kan deze (in het DNS-record) het IP-adres wijzigen in dat van een server in hun beheer - waarbij die server geen https-verbindingen aanneemt met de door jouw browser meegegeven domeinnaam. Zodra de browser stilletjes terugvalt naar http kan die server je naar elke gewenste website doorsturen. Een andere, waarschijnlijk vooral theoretische, mogelijkheid is dat een aanvaller-op-afstand jouw MODEM bombardeert met ongevraagde DNS-antwoorden (dit is relatief eenvoudig bij standaard DNS - omdat UDP daar veel kwetsbaarder voor is dan TCP). Een échte AitM (zoals beschreven bij het vorige punt) kan veel eenvoudiger DNS-antwoorden wijzigen, of sneller een vals antwoord sturen dan de echte DNS-server. Een bekende truc van cybercriminelen is het op afstand hacken van MODEMs en de instellingen voor de DNS-server(s) veranderen.

Zet "waarschuwen bij onveilige verbindingen" (ook bekend als "HTTPS-only mode" - een bar slechte omschrijving) aan in jouw browser(s) en neem elke waarschuwing serieus, vooral als je van een openbaar WiFi access point gebruikmaakt. N.b. helaas zijn er browsers (met name Chrome) die toestemmingen voor bezochte http-only-websites heel lang bewaren (ook na afsluiten en weer opstarten van de browser). In Chrome lijkt de instelling uit- en weer aanzetten die "cache" te legen, maar transparant is dit allesbehalve en je vergeet dat uit/aanzetten waarschijnlijk snel (zeker als je vaak gebruik maakt van public WiFi).

Configureer thuis een lang wachtwoord op je WiFi MODEM zodat dit lastig te achterhalen valt. Wijzig dat wachtwoord regelmatig als je wat oudere kinderen hebt die veel vriendjes/vriendinnetjes thuis ontvangen, en toegang geven tot jouw algemene netwerk (een aanvaller die zo'n wachtwoord bemachtigt kan voor jouw deur een "evil twin", een nep WiFi access point, optuigen - en sowieso rondneuzen op jouw interne netwerk, en daar méér mee kunnen dan je dacht).

Erik, Ik heb HTTPS-only modus aan staan en krijg bij http://http.badssl.com/ dus een waarschuwing.
Zelfs als ik handmatig "http://gemeente.amsterdam:80/" intyp word dit naar HTTPS geforceerd.
(Deze modus had naar mijn mening al lang als default ingesteld moeten worden, retro-actief voor iedereen!)

Maar dit is enkel technische beveiliging van de verbinding met een domein.
Of het domein degene is die je verwacht dat het is, dat is een heel ander punt en momenteel de zwakke schakel.
Iedereen kan een domein aanvragen, ook als deze voor een andere verward kan worden.

Zelfs ik kan eens per ongeluk op https://www.securlty.nl/ belanden door een verkeerd linkje te klikken.
Dat er securLty.nl staat valt nauwelijks op, ik zou het pas realiseren wanneer mijn wachtwoord niet word aangevuld.

Dus de veiligheid tussen gebruiker en domein moet verstevigd worden.
Ik had al genoemd om domeinen een label te geven als deze officieel of vertrouwd zijn.
Verder heb ik helaas nog geen andere suggesties gelezen...

Om misverstanden te helpen voorkómen: veel webbrowsers ondersteunen "aan de internetzijde" als websitenamen uitsluitend DNS-domeinnamen bestaande uit combinaties van:


N.b. Een "DNS segment" (een deel gescheiden door punten, dus het TLD (Top Level Domain) of een subdomein daarvan of daar weer van etc.) mag niet beginnen of eindigen met een - (minteken).

Een laagliggend streepje (aka underscore) komt vóór in DNS (bijv. voor SPF records), maar websitenamen (ook bekend als domeinnamen of hostnamen) daarmee worden -voor zover ik weet- niet ondersteund door webbrowsers.

Webbrowsers ondersteunen daarnaast (aan de gebruikerszijde) het tonen en invoeren van UNICODE domeinnamen in de adresbalk, alsmede UNICODE links (de phishingpagina https://lîdl. be/login (zonder de spatie daarin) is nog steeds live). Voor gebruik aan de internetzijde "vertalen" browsers dat soort visuele websitenamen altijd naar reguliere DNS-domeinnamen. In op internet bruikbare vertalingen van visuele UNICODE websitenamen zal minstens één segment beginnen met xn-- (zo'n domeinnaam wordt Punycode genoemd; xn--ldl-vma .be is Punycode voor lîdl. be). Zie https://www.charset.org/punycode.

Goede beveiliging vereist bijna altijd dat je meerdere (soms heel verschillende en/of ongerelateerde) risico's mitigeert.

Veel te vaak wordt geprobeerd om één probleem op te lossen zonder vooruit te denken (MFA) en/of ongerelateerde problemen niet aan te pakken.

Daarbij, is de instelling "waarschuwen bij http" echt een "enkel technische beveiliging"?

Voorheeld, gisteravond hoorde ik in een TV-reclame zeggen:
http://ahvoordeelshop.nl heeft HSTS niet goed geïmplementeerd (zie https://internet.nl/site/ahvoordeelshop.nl/3521014/#control-panel-8). Eventuele (oudere) browsers die niet uit zichzelf
https://ahvoordeelshop.nl proberen, profiteren de volgende keer niet van HSTS.

https://ahvoordeelshop.nl stuurt een HSTS header die een half jaar geldig is en redirect een bezoekende browser naar
https://voordeelshop.ah.nl - hét perfecte recept om bezoekers te leren in phishing (met valse websitenamen) te trappen.

Aanzetten van "HTTPS-only" om te voorkómen dat een AitM "op het netwerk" die verbinding bij het eerste bezoek (of na een half jaar niet gebruiken) kun je inderdaad (in bovenstaand voorbeeld) een "enkel technische beveiliging" noemen.

Echter, is dat ook zo in de volgende situatie? Als het een aanvaller lukt om het DNS-record van ahvoordeelshop.nl te wijzigen naar een website die uitsluitend http ondersteunt, kan die website de browser van de nietsvermoedende bezoeker doorsturen naar élke door de aanvaller gewenste website, zoals (zonder de spatie er in):
https://ah-voordeelshop .nl
https://voordeelshopah .nl
https://voordeelshop-ah .nl
https://ah-voordeel-shop .nl
https://voordeel-shopah .nl
https://voordeel-shop-ah .nl
https://ahvoordeel .shop
https://ah-voordeel .shop
https://voordeelah.shop
https://voordeel-ah .shop
https://voordeelshop.ah .shop
(zo kan ik er nog veel meer bedenken).

Waarom zou de bezoeker moeten denken dat zo'n site nep is - als zij of hij zelfs géén (http-) waarschuwing heeft gezien? Immers, (marketing-) idioten, zoals bij AH, leren internetters dat het normaal is dat jouw browser wordt doorgestuurd naar een website met een andere domeinnaam.

Ik denk dat zelfs "altijd waarschuwen bij http" lang niet ver genoeg gaat. Twee punten uit mijn wensenlijst:

1) Laat http:// altijd https:// worden (nooit meer terugvallen naar TLS-loze http).

2) Introduceer risky:// als vervanging van het oude http:// protocol voor sites die beslist geen https ondersteunen. Tik dat ("risky://") maar in als je een TLS-loze "http" verbinding wilt. Optioneel kan de browser dan alsnog waarschuwen, vooral als het om een website op publiek internet gaat (dus niet op een lokaal netwerk met een RFC 1918 IP-adres).

Je bedoelt "Of het domein van degene is [...]". En ik vind het één van meerdere zwakke schakels - die qua "ernst" lastig met elkaar te vergelijken zijn omdat verschillende externe factoren een grote rol kunnen spelen (zoals public WiFi).

Dan heb je kennelijk de "P.S." onderin https://security.nl/posting/912139 overgeslagen.