De PSD2 eis is dat er twee duidelijk gescheiden kanalen zijn waarmee het proces gevolgd kan worden.
Dat is een verdergaand iets dan alles in een ondoorzichtige app te verbergen waar de kanalen onzichtbaar zijn.

Het is nogal verbazend dat deze striktere beveiligingseis zo weinig aandacht krijgt.
Wel veel commotie over dat een extra gecontroleerde verwerker (het recht om die in te schakelen) transactie kan zien.
De privacyvoorvechters met hun framing aan de leidraad van het grootkapitaal.

Ze moeten hun e-mail beleid ook eens beter beveiligen.

Deze week kreeg ik een phishing mailtje uit hun naam. De mail gaf een nette DMARC fail, maar de phishing mail kwam toch binnen omdat ze een policy gebruiken om niets te doen bij een fail. Hoe fout kun je bezig zijn als instelling waarvan de domeinnaam vaak misbruikt wordt voor phishing.

Wanneer leren de banken en financiele dienstverleners het een keer dat een mobiel platform als Android inherent onveilig is dat het geen enkele zin heeft om daar een super veilige app op te gaan installeren. Het platform is qua security en privacy rot en daar gaat één van hun apps niets aan veranderen.
Je kunt een super veilig huis willen bouwen maar als de fundering slecht of rot is gaat de boel uiteindelijk een keer instorten.
Wie mobiel bankiert heeft een gaatje in het hoofd of wil graag beroofd worden.

Goed werk security technisch zijn ze bij ICS klaar voor 2005 !

Dat is vreemd. Ik heb een VISA kaart en ik moet al heel lang een tweede code invoeren, die ik via de app krijg.

Peter

Vandaar dat je zo ontzettend veel hoort over fraude via mobiel bankieren omgeving van de bank (not).

Is er al een bank die de noodzaak voor het verwerken van telefoonnummers heeft aangetoond? Het staat je natuurlijk vrij om je creditcard op te zeggen, maar als het gehele bankenkartel besluit met SMS codes te werken kan er natuurlijk geen sprake meer zijn van vrije keuze. En dat zonder dat er ook maar iemand is die duidelijk maakt waarom open standaarden (webauthn!) niet zou voldoen. Niks telefoonnummers verwerken, niks vage apps installeren en je gebruikers verplicht een telefoon laten aanschaffen. Met een open standaard zijn al dit soort problemen verholpen.

Als mijn bank dit zou doen zou ik verhaal halen...

Vreemd, ben benieuwd vanuit welk domein ze mailen dan, want icscards.nl zelf geeft gewoon netjes een p=reject en sp=reject terug. Wellicht dat er toch vanuit een gelijkend domein gemaild is? Overigens wel weer bijzonder dat de zakelijke tak (icsbusiness.nl) dan weer wel p=none ingesteld heeft.

Yup, want SMS is o zo veilig anno 2019. Blijkbaar is dat voldoende om aan de nieuwe PSD2 regelgeving te voldoen :(

TheYOSH

FUD. Apps gebruiken in veel gevallen certificate pinning en maken geen typfouten in o.a. URL's. Browsers op desktop OS-en zijn inherent onveiliger dan mobiele apps. Hooguit zou je op grond van fysieke veiligheid een desktop kunnen prefereren boven een mobile device, maar dat staat los van de techniek.

Ik kreeg de mail via icscards.com. Ik zie dat daar inderdaad geen website achter hangt. Ik ging er min of meer van uit dat zij het domein geregistreerd hadden omdat de dmarc info wel naar een icscard.nl adres gestuurd werd.

Maar ik ben geen klant en weet niet wat hun normale domein in mail is.

Veiliger vanuit de belangen van de app makers gezien, niet vanuit de geruiker bekeken. De native mobiele apps zijn stukken makkelijker in staat om in de achtergrond gegevens te verzamelen en weg te sluizen dan een webbrowser.

Gut, meestal neem je iemand anders de maat, maar nu blijkt, dat je dezelfde fout maakt, je bent een normaal mens!

Dat klopt dat het voldoende is voor psd2 als extra bij inloggen.
Staat bij de psd2 implementatie opmerkingen.
Het is onduidelijk bij een betingsopdracht omdat er een betrouwbaarheid van niet aangepaste informatie moet zijn.
Je hebt Denk ik grotere uitdagingen als je elke bekende optie als van mogelijk tot zeker omzet. Wat je nog niet weet is belangrijker. Kan een App op jouw telefoon van alles veranderen?

icscards.nl
_dmarc.icscards.nl descriptive text "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarcreport@icscards.nl"

Maar zo te zien is icscards.com ook van hun:
_dmarc.icscards.com descriptive text "v=DMARC1; p=none; rua=mailto:dmarcreport@icscards.nl;"

Inderdaad vreemd dat ze daar niet ook een policy reject hebben om PHISH te voorkomen.

Enig sarcasme kan de reaguurder niet ontkend worden..

Het lijkt er dus op dat phishers onterecht namens icscards.com e-mail hebben kunnen verzenden, doordat de echte creditcard-uitgever het domein icscards.com, dat zij vermoedelijk in eigendom heeft genomen om dit soort phishing te voorkomen, onvoldoende heeft beveiligd hiertegen.

@Briolet, als je de mail nog hebt, naar welke website verwees deze? (Als je de link publiceert, graag http[s] wijzigen in hxxp[s]).

Tet info, enkele eerdere bijdragen over ICScards.nl phishing:
https://www.security.nl/posting/471357/ICS+Phishing+spamrun (met SPF/DKIM/DMARC info van dat moment)
https://www.security.nl/posting/484007/phishing+ics
https://www.security.nl/posting/493511/ICSCards+phishing

Hij ging naar "all_do_play_web" (Maar dan zonder underscores en met dot com erachter.) Op zich bestaat die domeinnaam al een paar jaar met hetzelfde IP adres. Het kan een gehackte site zijn waar de phishing content alleen op een specifieke pagina staat waar je naar toe gestuurd werd.
De specifieke pagina was "mnjbhvpolk/?ac=3D26"

@Erik, voor het geval je nog interesse hebt in de header van die mail:


Edit: Overigens had het bij mij niet veel uitgemaakt als ze wel een correcte reject op dmarc hadden gezet. Ziggo controleert weliswaar de dmarc status en schrijft zelfs de policy in de header, maar laat ook een mail met reject policy nog gewoon door. (Zo'n phishing mail met reject policy op het domein heb ik deze week ook binnen gehad)

Ik woon in Belgie en heb een rekening bij een Belgische bank.
Ik gebruik een PC.
Ik heb van de bank een apparaatje met toetsen.
Om een betaling via internet en browser af te ronden naar een andere bank in Belgie moet ik:
1.) apparaat inschakelen en mijn 4 cijferige (geheime) code invoeren
2.) een tweede (persoonlijke) code invoeren
3.) het serienummer van mijn apparaat invoeren
4.) applikatie #1 bevestigen
Hierna krijg ik een 6 cijfer code voor de transactie; deze code ingeven: dat rondt de transactie af.
Een betaling via internet en browser mbv een VISA kaart gaat als volgt:
A.) ik krijg in de browser een scherm waarin een 8 cijferig getal staat
Allereerst stappen 1, 2, 3 uitvoeren
B.) applicatie #2 bevestigen
C.) het getal van A.) ingeven
D.) Het resultaat (8 cijfers) in de browser intypen

Alles wat ik hierboven schreef wisten jullie natuurlijk al lang maar dat is vanzelfsprekend niet goed genoeg voor een Nederlandse bank

Dit werkt perfekt hier, is erg eebvoudig en veilig. Zelfs de Belgen kunnen ermee omgaan. Ik denk dat het geouwehoer in Nederland (gezien de voorgaande reakties) voortkomt uit onkunde, beterweterigheid of onwil. Het zou beter zijn om deze onzin te stoppen in de vorm zoals dat hier plaatsvindt en iets nuttigs te doen
Gegroet vanuit het land van bier, frites en mosselen.
Jan

@Briolet: dank voor jouw reacties!

Zo te zien klopt mijn vermoeden:
1) SPF is OK omdat het domein van het "Return-path" suncoastbbqservices.com luidt, en er voor dat domein een SPF record bestaat dat vermeldt dat 142.93.158.89 namens suncoastbbqservices.com mail mag verzenden (zie https://mxtoolbox.com/SuperTool.aspx?action=spf%3asuncoastbbqservices.com&run=toolpage);

2) suncoastbbqservices.com heeft een geldige DKIM-signature toegevoegd, maar is natuurlijk geen betrouwbare partij in deze;

3) Het in een deel van de e-mail clients zichtbare From: e-mail adres heeft icscards.com als domein. Hoewel de eigenaar van dat domein, kennelijk de echte icscards.nl, wel een DMARC record heeft gepubliceerd maar dat -onbegrijpelijkerwijs- niet als "verplicht" heeft geconfigureerd, werd deze phishingmail niet geblokkeerd.

Als phishingmails (zoals Briolet ontving) niet zouden werken, zouden criminelen niet zoveel moeite doen om ze te versturen (waaronder speuren naar onjuist geconfigureerde DMARC records en SPF+DKIM records registreren voor hun nepdomein).

Doordat de e-mail ontvanger als afzenderdomein icscards.com ziet (i.p.v. de gebruikelijke "icscards.nl") zal een deel van de ontvangers hier wel intrappen. Als die ontvanger op de link in de mail klikt, en niet opmerkt dat het domein van de getoonde webpagina alldoplayweb.com/ luidt (ongetwijfeld voorafgegaan door "https://" met geldig domain-validated certificaat) in plaats van https://icscards.nl/, maar de inhoud van de pagina herkent als van de echte site en inlogt, is hij of zij de pineut.

Als de criminelen algemeen beschikbare software als Modlishka inzetten, helpen SMS-2FA en zelfs jouw kastje niet om te voorkomen dat die criminelen, namens jou en met jouw authenticatiegegevens, onmiddellijk nadat jij jouw gegevens hebt ingevoerd op hun nepsite, inloggen op de echte site.

Het gebruik van jouw kastje zou je daarentegen wel kunnen waarschuwen zodra er (veel) geld word overgemaakt, maar dan moet je wel heel goed opletten. Uit wat je schrijft maak ik niet op dat jou dit kan helpen, maar bijvoorbeeld bij de Nederlandse Triodos bank werkt het als volgt. Zodra je met één of meer transacties geld overmaakt, is een van de getallen die je op het kastje moet invoeren (om de akkoord-code te berekenen) het totale bedrag van alle transacties (afgerond op hele Euro's). Maar dat het hier om een bedrag gaat (en niet een of ander willekeurig getal) heb ik nooit ergens gelezen, dus ook op dit punt kunnen mensen -evt. met enige social engineering- vermoedelijk voor de gek worden gehouden.

Ik vind het niet heel eenvoudig klinken. Qua veiligheid - uit je omschrijving blijkt dat er heel veel zekerheid is dat de rekeninghouder/bezitter van het apparaat "de" transactie bevestigd.
Ik schrijf "" om 'de transactie' omdat nergens uit je beschrijving blijkt dat de rekeninghouder enig idee heeft _welke_ transactie hij werkelijk bevestigd.

Eén van de problemen met malware/banking trojans/phishing sites is dat hetgeen de rekeninghouder op z'n scherm ziet als betaling- (zeker als dat een desktop PC is) heel anders kan zijn dan de betaling of autorisatie die werkelijk aan de bank aangeboden wordt [door de malware] .

De waarschuwing die je de laatste tijd ziet voor '1 cent betalingen' zijn vanwege dit probleem . Mensen worden verleid om, naar ze denken' een 1 cent betaling te doen (zogenaamd om rekening nummer te bevestigen) maar gaan feitelijk naar een phishing site, en de transactie die ze werkelijk bevestigen is het koppelen van een bank-applicatie van de phisher aan hun rekening.

Dat is een moeilijk probleem , om op een betrouwbare manier , buiten een manipuleerbare desktop om , de rekeninghouder te vertellen _wat de bank ontvangen heeft als opdracht_ en dat hij die opdracht moet authoriseren.
De TAN-via-SMS van ING bevatte een paar gegevens, maar is om andere redenen niet meer zo geschikt.
De Rabo calculator liet de gebruiker iets intikken van de transactie, maar dat die set "extra cijfers van het scherm" te maken hadden met de transactie was 99% van de gebruikers volkomen onduidelijk - ze tikten in wat de trojan zei in te tikken.

Misschien overigens is het ook jouw bank die dat zo doet bij de VISA betaling - en dat dat '8 cijferige getal' dat je overtikt feitelijk het bedrag + cijfers van de bestemmingsrekening zijn .
Mocht dat zo zijn, dan heb je precies geillustreerd wat er mis is met die stijl van 'bevestiging' - de gebruiker tikt gewoon blind over wat er in de browser staat, en is zich niet bewust dat wat er staat bedoeld is als controle van welk transactiebedrag+bestemming de bank gaat uitvoeren na bevestiging.

De ABN's nieuwe e.dentifier kan gekoppeld worden met de computer en laat dan op het scherm van de e.dentifier de transactie zien . De e.dentifier wordt dan beschouwd als het trusted en niet-manipuleerbaar endpoint om de gebruiker te vertellen wat hij _werkelijk_ gaat authoriseren.

Ook al heb je een DMARC policy van Quarantine of Reject, de ontvangende server mag de gepubliceerde DMARC policy negeren en de mail toch afleveren. Dat staat gewoon in de RFC. Het is de verantwoordelijkheid van de verzender om zaken als SPF, DKIM, DMARC, ARC etc. te regelen, zodat de ontvanger in staat te bepalen welke mail authentiek is of niet. Maar mag dus gewoon de mail in de mailbox van de geaddresseerde afleveren als deze alle/een deel van de checks faalt. Het is dan aan de ontvangende kant om de lezer te waarschuwen.

https://eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money/regulatory-technical-standards-on-strong-customer-authentication-and-secure-communication-under-psd2
https://eba.europa.eu/single-rule-book-qa/-/qna/view/publicId/2018_4039

"Paragraph 35 of the EBA opinion on the implementation of the Commission Delegated Regulation (EU) 2018/389 (RTS on Strong customer authentication and secure communication) clarifies that “For a device to be considered possession, there needs to be a reliable means to confirm possession through the generation or receipt of a dynamic validation element on the device”.
In this context, a one-time password sent via SMS would constitute a possession element and should therefore comply with the requirements under Article 7 of these RTS, provided that its use is ‘subject to measures designed to prevent replication of the elements’, as required under Article 7(2) of these RTS. The possession element would not be the SMS itself, but rather, typically, the SIM-card associated with the respective mobile number."

Als een domein een advies geeft om het zelf maar uit te zoeken wat je er mee doet als er een fail is op de afzender, waarom accepteer je dat dan zelf en leg je de schuld bij een ander? Het is een advies, geen verplichting. Als je van mening bent dat bij een fail er een afwijzing moet zijn dan ben je met je eigen ontvangende mailserver de eerste die er een beslissing in kan maken.

Vertel dan maar eens wanneer de laatste plundering van een bankrekening plaats had doordat Android gebruikt werd.

Indenficatie , communicatie, fraude meldingen?
Ik denk meer dan voldoende redenen, waarbij SMS er ook nu nog 1 is. Ik zie geen problemen met de verwerkingen van je telefoon nummer

Is er een kartel? Immers men moet gewoon volgens de wet de beveiliging verhoren.

Misschien.... Als men geen internet toegang geeft? Data verbruik is nog niet overal mogelijk, zeker buiten Europa.
Daarnaast is webauthn ook een stuk lastiger en complexer en minder gebruikers vriendelijk, nog afgezien slechte controle.

Zijn niet echt lastige punten.

Onzin, hangt er allemaal vanaf hoe je iets gebruikt. Er zijn veel meer eisen waaraan niets moet voldoen. Controle is daar oa een onderdeel van. Open standaard is geen vereiste. Het kan natuurlijk wel gebruikt worden, maar het hoeft niet de oplossing te zijn.

Bijna alle banken doen dit. Daarnaast, je kunt wel verhaal halen, maar je zal voornamelijk uitgelachen worden door ze.
Techniek is maar een heel klein onderdeel in dit soort ketens.

Je zou natuurlijk altijd kunnen solliciteren bij deze bedrijven, gewoon in je CV zetten dat ze een waardeloos implementatie gedaan hebben, en jij het veel beter weet. Misschien wordt je wel uitgenodigd om langs te komen.

En een webbrowser is veel gemakkelijk te manipuleren.

Een simpele webbrowser, zoals curl, misschien niet.
Maar wel al die webbrowsers waar het meerendeel van de gebruikers net zo gemakkelijk allerlei apps en extensis in installeren.

Peter

Klopt, en PSD2 is ook zo 1999

Zo fijn ook van ICS dat ze echte mails ook vrolijk sturen met "klik deze link om in te loggen".
Dat geeft je echt makkelijk het vermogen om onderscheid te maken tussen echte en valse mails - NOT.
En aangezien een papieren afschrift er ook niet meer af kan is het knap lastig om een beetje veilig gevoel te hebben bij deze credit card maatschappij.
Aangezien banken hun credotcards maar al te graag aan ICS doorschuiven, zitten we straks met een soort monopolist die, inderdaad, qua beveiliging toch wel aangekomen lijkt te zijn in de 21ste eeuw maar met moeite.