Vraag over de veiligheid van de "volksbank" browsercode

[addo2]

Ik vraag me af hoe de veiligheid van de SNS/ASN-/regiobank voor consumenten met een betaalrekening wordt geregeld. De opties die er worden gegeven zijn "Inloggen met browsercode" of met een app op de telefoon. Hoe werkt een "Browsercode" en hoe is deze zo veilig te krijgen dat het opzetten met de invoer van 5 getallen voldoende is? Zeker omdat dit om 10 brouwers/apparaten tegelijkertijd kan.

De afgelopen jaren is er veel aandacht geweest voor 2FA. Zodoende heb ik de voorkeur voor een combinatie van 2 eigenschappen van: iets dat je weet(wachtwoord), iets dat je hebt of iets dat je hebt. In dit geval met de browsercode is dit toch alleen maar "iets dat je weet" met 5 getallen?

Helaas is het opzoeken van de term "Browsercode" niet erg nuttig en ik vermoed dat ik nu nog niet de kennis heb om te snappen waarom dit zo veilig is. Ik hoop dat iemand dit aan mij kan uitleggen of mij kan uitleggen welke zoektermen ik kan gebruiken om te begrijpen waarom "een browsercode" veilig genoeg is.

[sOid]

Leuke vraag. Dit is een vorm van passwordless/passkey authenticatie. Al is dat volgens de strenge definitie volgens mij alleen van toepassing als de authenticatie van de dienst afhankelijk is van de (biometrische) authenticatie op het device. Dit wordt voor veel toepassingen als de toekomst van authenticatie gezien. Een goed voorbeeld is FaceID om op je iPhone in te loggen bij je bank.

Ik heb het stappenplan doorgelezen en je moet je device/browser heel bewust activeren. Hiermee kun je die browser vervolgens zien als de factor ‘wat je hebt’ en die browsercode ‘wat je weet’.

Een risico kan cookie hijacking zijn, maar daar kan afaik ook een extra beveiliging bij worden ingebouwd. Bijvoorbeeld dat het IP-adres moet matchen met IP-adres van de aanvraag.

Een ander risico is fysieke toegang tot je browser. Dus zorg vooral dat jij de enige bent die je laptop gebruikt en zorg voor een goed password/biometrische authenticatie op dat ding.

[ Voor 23% gewijzigd door sOid op 18-11-2024 18:45 ]

[laurens0619]

Vanuit een aanvallersperspectief zie je vaak mitm phishing methodes gebruikt worden.

Je logt daarmee in op een soort reverse proxy waarna ze je cookie stelen. Probleem is dat mfa hier ook niet tegen werkt want je mfa wordt door “geproxied”. Google: evilnginx

Een bestaande browsercode met sessie cookie krijg je niet gestolen dmv de mitm aanval, dat gaat namelijk over nieuwe sessies.

Je browser code stelen lukt wel via phishing maar de gekoppelde cookie die je er bij nodig hebt kun je maar op 1 manier bij: toegang tot de client of de server.

Als je als aanvaller toegang hebt tot de client is het sowieso gameover.

Door deze methode te kiezen kan een bank dus onderscheid maken tussen een “trusted”/bekend client en een malicious. Zonder deze code/sessie en enkel met mfa is dat lastiger

[sOid]

@laurens0619 Goede aanvulling. Mooi (/tragisch) recent voorbeeld is datalek bij de politie: https://www.politie.nl/ni...elen-datalek-politie.html

Vermoedelijk is er gebruikgemaakt van een zogenoemde ‘pass-the-cookie-aanval’. Het doel van zo’n aanval is om toegang te krijgen tot het account of de applicatie van een gebruiker zonder dat inloggen middels een wachtwoord opnieuw vereist is. Een succesvolle aanval zorgt ervoor dat de aanvaller een actieve sessie van een account overneemt met de daarbij behorende rechten. Het verkrijgen van de toegang kan op veel verschillende manieren gebeurd zijn, zoals bijvoorbeeld door phishing. Na een succesvolle aanval kan er malware worden geïnstalleerd die data zoals cookies doorstuurt naar een hacker waarmee toegang kan worden verkregen. In dit geval weten we dat het adresboek is buitgemaakt.

Hoop dat hier nog meer details over naar buiten komen, want ik begrijp begrijp 'm nog niet helemaal.

[BytePhantomX]

Ik heb het niet uitgezocht, maar ik kan me voorstellen dat ze een soort van fingerprint maken van jouw systeem. Browser, samen met windows versie, taal instellingen en mogelijk nog meer technieken. Daarbij zullen ze vast ook cookies plaatsen, en heel misschien ondersteunen deze browsers iets als een uniek id. De combinatie van fingerprint & cookie maak het waarschijnlijk dat je een cookie niet kan stelen en op een ander systeem kan hergebruiken.

Daarnaast maken banken ook gebruik van algoritmes om fraude tijdens het doen van een transactie te detecteren en te blokkeren. Bijvoorbeeld een oud product van Fox-IT: https://www.dataexpert.nl/detact/.

Alles bij elkaar zal het wel veilig genoeg maken, anders zou een bank dit niet snel doen. Gezien de zorgplicht zullen ze bij fraude namelijk snel moeten betalen als de oplossing die ze bieden onveilig is.

[CyBeR]

Vooropgesteld, ik heb geen ASN dus ik kan 't niet met zekerheid zeggen maar als ik die pagina lees krijg ik het idee dat die vijfcijferige code alleen maar een manier is om te verifieren dat jij het bent. Dwz, het is een soort pincode, en die wordt alleen lokaal in je browser gebruikt en niet verstuurd naar de servers van de bank.

In de cookie zet men vermoedelijk een cryptografische key die je ontsleutelt met de pincode. Daarom werkt het niet als de cookie kwijt raakt, en daarom is de browsercode device-specifiek. Mogelijk heeft die code ook wat info over het device en (op z'n minst) de browser aan boord zodat je ze niet zomaar uit een browser kunt lichten en in een andere browser zetten.

[DaFeliX]

laurens0619 schreef op maandag 18 november 2024 @ 18:17:
Vanuit een aanvallersperspectief zie je vaak mitm phishing methodes gebruikt worden.

Wat bedoel je hier mee, mitm of phising? Want dat zijn twee verschillende zaken volgens mij: mitim is wanneer iemand actief tussen jou en de bank zit; bij phising ga je als bezoeker naar een nep-ASN-website.

Een mitm-aanval komt niet zo heel veel voor, deze aanvallen zijn nl redelijk complex. Maar een mitm zou voor deze situatie volgens mij wel werken (althans, ik zie niet in waarom niet).
Phising is iets wat wel veel wordt gebruikt, en als men op die manier de gebruikersnaam/wachtwoord van je kan achterhalen is wat de TS noemt een mogelijke oplossing.

laurens0619 schreef op maandag 18 november 2024 @ 18:17:
Je logt daarmee in op een soort reverse proxy waarna ze je cookie stelen. Probleem is dat mfa hier ook niet tegen werkt want je mfa wordt door “geproxied”. Google: evilnginx

MFA kan prima tegen phising werken, alleen niet elke MFA doet dat. Het aantal factoren heeft geen invloed of zo'n aanval werkt, wel of de factoren die je gebruikt kunnen gereplayed worden. Dus een wachtwoord + TOTP is niet echt effectief (want de sessie moet in elk geval real-time worden uitgevoerd, anders is de TOTP niet geldig), maar bijvoorbeeld webauthn die de origin checkt werkt wel tegen zo'n aanval.

laurens0619 schreef op maandag 18 november 2024 @ 18:17:
[...]

Als je als aanvaller toegang hebt tot de client is het sowieso gameover.

Hier kan ik het alleen maar volledig mee eens zijn. Hoewel je de impact dan wel kunt verkleinen door bijvoorbeeld te werken met dingen zoals daglimiet.

[sOid]

DaFeliX schreef op dinsdag 19 november 2024 @ 07:29:
[...]


Wat bedoel je hier mee, mitm of phising? Want dat zijn twee verschillende zaken volgens mij: mitim is wanneer iemand actief tussen jou en de bank zit; bij phising ga je als bezoeker naar een nep-ASN-website.

Als je een phishing site opzet om een TOTP-code te stelen en die als aanvaller direct gebruikt om in te loggen, is dat dan niet een combinatie van phishing en MITM?

[laurens0619]

Exact dat

@DaFeliX
Met mitm phishing bedoel ik inderdaad de combinatie ipv traditionele phishing pagina

Super veel voordelen erbij, je hoeft niets na te maken, hij pakt de mfa mee.

Dat traditionele mitm aanvallen(iemand zit op de lijn) weinig voorkomen ben ik met je eens maar de truuk dat ze je naar een proxy sturen via phishing en dan mitm komt enorm veel voor. Veel vaker tegenwoordig dan losse phishing sites voor credentials. Ik noem die techniek idd mitm phishing

Mbt mfa heb je gelijk, ik was wat kort door de bocht en doelde op traditioneel mfa met een authenticator/code. Mfa kent inderdaad technieken die je niet door kan proxyen, sterker nog het verhaal uit TS is zon vorm van MFA

[ Voor 29% gewijzigd door laurens0619 op 19-11-2024 09:33 ]

[DaFeliX]

sOid schreef op dinsdag 19 november 2024 @ 08:57:
[...]

Als je een phishing site opzet om een TOTP-code te stelen en die als aanvaller direct gebruikt om in te loggen, is dat dan niet een combinatie van phishing en MITM?

MITM is volgens mij dat een ongewilde op de verbinding tussen jou en jouw bank zit. Dus echt op netwerkniveau.
Er is volgens mij geen sprake van MITM als jij naar een andere server dan jouw bank verbind. Jij zou nl in je browserbalk kunnen zien dat jij op ikbenheusdeechtdeasnbank.nl zit; en niet met asnbank.nl verbonden bent. En je komt op de ikbenheusdeechtdeasnbank.nl dmv phising omdat je een linkje toegestuurd krijgt.

Ik zou overigens wel van MITM willen spreken als iemand de DNS aangepast heeft van asnbank.nl en al het verkeer via een andere server laat lopen.

[CyBeR]

MITM betekent inderdaad echt dat iemand tussen jou en de legitieme server zit en het geheel op z'n minst kan afluisteren (en mogelijk aanpassen), waar phishing betekent dat iemand je naar een nepsite lokt om je inloggegevens af te troggelen.

Als de browsercode werkt zoals ik denk dan kan zowel een mitm als phishing daar niks mee; bij mitm krijgt de aanvaller alleen een signature mee zonder de betreffende keys te kennen, terwijl bij phishing men alleen je pincode krijgt.

Iemand die echter het endpoint (dwz jouw browser) aangevallen heeft, bijvoorbeeld met een malafide browserextensie of een andere app op je computer, zou zowel de cookie als je pincode (en natuurlijk je inlognaam en wachtwoord) kunnen ontfutselen, en ik weet zo even niet wat ASN daar tegen zou kunnen doen.

Om dit soort redenen is overigens de veiligste manier van internetbankieren middels de app van de bank ipv de browser op je computer. Die apps doen allerlei dingen om te zorgen dat 't veilig is, waaronder certificate pinning waardoor mitm'en al direct heel moeilijk wordt.

[ Voor 15% gewijzigd door CyBeR op 19-11-2024 09:58 ]

[laurens0619]

Het is een beetje een definitie discussie, sommige noemen het ook AiTM. Adveresary in the Middle
https://www.blueshielditn...ferences-and-staying-safe

An Adversary-in-the-Middle (AitM) attack is a variant of the well-known Man-in-the-Middle (MitM) attack. It is a form of data eavesdropping and theft where an attacker intercepts data from a sender to the recipient, and then from the recipient back to the sender.

Als je een proxy opzet en je lokt daar mensen naartoe om via die site in te loggen dan is dat een combinatie van phishing (het lokkken van invoeren credentials/mfa op een site) en MiTM/AiTM (het kunnen lezen/maniupuleren van de data tussen het slachtoffer en server).

De browsercode staat waarschijnlijk in een cookie opgeslagen. Omdat het domein inderdaad afwijkt zal deze cookie niet naar de server gestuurd worden en zal het als nieuwe sessie worden gezien.

Dit type aanval komt tegenwoordig echt heel erg vaak voor dus ik denk slimme zet van volksbank om hier wat tegen te verzinnen als de browsercode. De vraag is alleen hoe initieel de browsercode wordt ingesteld, vaak is dat een zwakke schakel

https://abnormalsecurity....inals-evilginx-mfa-bypass

[addo2]

Bedankt voor alle antwoorden! Ik denk dat ik nu voldoende begrijp wat het product "browsercode" is. Voor het gemak vat ik het technische deel samen en daarna doe ik een zijstap naar de gedachte die bij me opkwam toen ik het technische risico aan het samenvatten was.

Als ik de technische probleemstelling samenvat:

• Op dit moment is het risico serieus aanwezig op "phishing" aanvallen in combinatie met "man in the middle"(incl. "Adversary-in-the-Middle") technieken.
• De methode "browsercode" is een browser specifieke cooky is die over langere tijd probeert te garanderen dat de verbinding tussen de pc en de bank te vertrouwen blijft.
• Het vermoeden is dat de cooky onder andere eigenschappen van de omgeving van het systeem moet meenemen omdat het anders gevoelig is voor het kapen/kopieren van de cookies en dat deze op een andere computer ook kunnen worden ge/misbruikt.
• Het vermoeden is dat er door de methode "browsercode" het risico aanpast van "elke keer dat je naar de site gaat" naar alleen het moment waarop de handshake/kennismaking plaats vind.

Als ik het goed begrijp is dit dus een relatief nieuwe methode die technisch inhoudelijk (in ieder geval qua communicatie) op dit moment vooral op "security through obscurity" leunt. Dit natuurlijk met de kanttekening dat we mogen aannemen dat een bank geen roekeloos risico wilt lopen. Als ik eerlijk ben denk ik dat de methode van een browsercode vast technisch goed is uitgedacht en het correct zal werken.

Gezien dat er hier een andere werkwijze (≠2FA) en daarmee "normaal" wordt geschapen is de initiële opmerking van @sOid denk ik ook belangrijk: het risico op toegang tot de browser.

Een ander risico is fysieke toegang tot je browser. Dus zorg vooral dat jij de enige bent die je laptop gebruikt en zorg voor een goed password/biometrische authenticatie op dat ding.

Omdat het hier juist voor persoonlijk gebruik (onderstaande is een quote van de ASNbank) wordt toegepast bij mensen die geen mobiele app gebruiken...:

De browsercode is een persoonlijke code waarmee je kunt inloggen en ondertekenen in ASN Online Bankieren als je een betaalrekening hebt. Dit is handig als je geen mobiele telefoon hebt en/of geen gebruik kan maken van de ASN-app.

Mijn gevoel zegt echter dat het hebben van een "Time-based one-time password" of een apparaat dat tekstueel kan bevestigen wat de betaling gaat worden (zoals een Rabo Scanner) juist extra belangrijk is voor deze doelgroep. Mensen zonder telefoon kunnen mogelijk juist extra risico lopen omdat ze vaker ouder/armer(gedeelde computer)/technisch minder onderlegd zijn...

(edit: 3e punt tussengevoegd n.a.v. "pass-the-cookie-aanval" welke ik vergat te benoemen

[ Voor 5% gewijzigd door addo2 op 19-11-2024 13:47 ]