ASN Bank waarschuwt klanten voor phishingaanval
De ASN Bank waarschuwt klanten voor een nieuwe phishingaanval die de ronde doet, maar daarbij gebruikt het zelf ook obscure links. Zowel op de website als via e-mail laat de bank weten: "Momenteel worden er e-mails verstuurd die eruit zien alsof de ASN Bank ze verstuurt. Dat is echter NIET het geval. In deze e-mails wordt u gevraagd op een link te klikken. U krijgt dan verbinding met een vervalste website."
De vervalste website vraagt om toegangsnaam, wachtwoord, pincode, geboortedatum, naam, adres, postcode en telefoonnummer. Volgens de bank zijn overboekingen alleen mogelijk met behulp van de persoonlijke ASN Digipas. "Zo bent u er zeker van dat er nooit geld kan worden overgeboekt naar externe rekeningen zonder uw instemming."
Link
Opmerkelijk genoeg geeft de ASN Bank zelf niet het juiste voorbeeld. In de e-mail laat het klanten weten dat ze door op de link in het bericht te klikken, voorbeelden van phishingmails kunnen bekijken. De link wijst echter niet naar het domein van de bank, maar naar emassaging.nl. Sommige banken gebruiken een externe partij om het aantal clicks in e-mailberichten bij te houden. Dit maakt het echter lastig voor klanten om te bepalen op welke website ze uitkomen.
Wat wil je daarmee? Denk je dat gebruikers er iets mee kunnen?
SPF is naast andere pseudo authenticatietechnieken een van de grootste falen in de emailcontrole. Eerst voorgesteld als anti-spam maatregel, toen gecorrigeerd naar "iets anders" en nu een teken dat kans groot is de verzender een spammer is. Onbetrouwbaar. Onbruikbaar.
Wat wil je daarmee? Denk je dat gebruikers er iets mee kunnen?
SPF is naast andere pseudo authenticatietechnieken een van de grootste falen in de emailcontrole. Eerst voorgesteld als anti-spam maatregel, toen gecorrigeerd naar "iets anders" en nu een teken dat kans groot is de verzender een spammer is. Onbetrouwbaar. Onbruikbaar.
is wat kort door de bocht. Ik zou er van maken dat spf de nodige beperkingen/afhankelijkheden kent en eisen stelt aan de bank (publiceren van passende policy [spf maar ook mbt content en gebruikte mailservers'] en aan de ontvanger (de klant met eigen mailclient en/of ontvangenden isp namens de klant) om het "nuttig effect" te sorteren.
1: Vertrouw simpelweg GEEN enkele email die van een bank afkomstig is.
2: Vertrouw simpelweg GEEN telefonische medewerkers die je opbellen.
als je dat al serieus neemt zou het verboden moeten zijn dat je uberhaubt toegang tot internet hebt.
Wat wil je daarmee? Denk je dat gebruikers er iets mee kunnen?
SPF is naast andere pseudo authenticatietechnieken een van de grootste falen in de emailcontrole. Eerst voorgesteld als anti-spam maatregel, toen gecorrigeerd naar "iets anders" en nu een teken dat kans groot is de verzender een spammer is. Onbetrouwbaar. Onbruikbaar.
is wat kort door de bocht. Ik zou er van maken dat spf de nodige beperkingen/afhankelijkheden kent en eisen stelt aan de bank (publiceren van passende policy [spf maar ook mbt content en gebruikte mailservers'] en aan de ontvanger (de klant met eigen mailclient en/of ontvangenden isp namens de klant) om het "nuttig effect" te sorteren.
Met jou maken andere SPF aanhangers dat er ook van. Probleem is dat er in de praktijk geen nuttig effect is en er niet zal komen. Er zijn veel betere methoden voor authenticatie, en dan hebben we het over echte authenticatie van de echte verzender. Vergeet niet dat de authenticatie afhankelijk is van de betrouwbaarheid van de domeinbeheerder. Iemand die linksom of rechtsom het beheer heeft bemachtigd over de name server kan dus eenvoudig mail vervalsen van alle gebruikers van het domein.
Spammers gebruiken SPF en DomainKeys om hun spamdomein van waardeloze pseudo-authenticatie te voorzien. Als je op een MX een bericht vind met correcte SPF (of DomainKeys), is de kans een stuk groter dat het spam is, dan dat het een legitiem bericht is. Waar is dan het nut? Als er al een client-end is, kun je gebruikers niet vertellen dat het ok is als SPF/Domainkeys correct zijn, want dat is duidelijk niet zo.
SPF is door veel postmasters al lang afgevoerd als te foutgevoelig.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
