Volgens mij hebben al die token dingen de gemeenschappelijke zwakheid dat het kanaal
waarlangs de codes en antwoorden gaan gemeenschappelijk is met hetgene waar de opdrachten
ook langs gaan (de browser).
Dat betekent dat als de inbreker de browser in handen heeft, hij de codes die richting de
token generator moeten kan aanpassen aan de modificaties die hij in de transactie heeft
aangebracht. Het is dan aan de gebruiker om te merken dat een code die hij normaal intikt
en die altijd gelijk is aan het bedrag of het rekeningnummer of zo iets, ineens anders is. Maar
dat zal veel mensen niet opvallen omdat ze niet weten hoe het allemaal werkt. De gebruiker
signeert nu de aangepaste transactie met een correcte reply.
Bij "gekoppelde" apparaatjes zoals die van de ABN is dit probleem nog ernstiger, omdat de
gebruiker de codes helemaal niet hoeft in te tikken en dus niet merkt dat de computer heel
andere dingen signeert dan wat hij op zijn scherm heeft.

Nee, maar van deze vraag kan ik alleen erwtensoep maken

Leuke reactie, hoor, Zipper306, maar verder nogal nutteloos.
Ik hoop dat iemand ook nog inhoudelijk zal reageren, want het is een interessante vraag van Erwtensoep, vind ik.
Aanvulling:
Ah, om 12:06 had iemand al inhoudelijk gereageerd, zie ik nu, maar die reactie was om 14:40 nog niet zichtbaar (als bijdrage van een oningelogde gebruiker nog niet geplaatst).

Betalingssystemen waarbij het bedrag in de responsecode wordt verwerkt zijn in mijn opinie veiliger, omdat je zelf het bedrag kunt controleren. Mocht je sessie zijn gekaapt dan nog kan er niet meer overgemaakt worden dan het bedrag dat je van plan was te betalen.

Sinds kort heeft de ING een leuke extra beveiligingsmaatregel, waarbij je naast een TAN code ook een PAC code moet opgeven, indien je van een andere dan gebruikelijke locatie internetbankiert. Mocht je op een gebruikelijke locatie aan het bankieren zijn en je moet een PAC code opgeven dan weet je dat er iets mis is.
Uiteraard heb je altijd mensen die klakkeloos een dergelijke code zouden ingeven. Wanneer je TAN/PAC codes op je mobiel ontvangt staat of valt deze beveilingsmaatregel natuurlijk wel met de beveiliging van je mobiele telefoon. Dit geldt natuurlijk helemaal indien je ook nog vanaf je mobiel bankiert.

Dat je bij gekoppelde apparaten niet ziet waarvoor je OK kiest, klopt niet. De gekoppelde ABN token generator laat altijd het bedrag en rekening nummer waarvoor je ok kiest, op de generator zien. Het is dan ook dom om daar blind op OK te drukken. En alleen bij kleine bedragen het display controleren is natuurlijk ook fout, omdat je je moet vergewissen of de generator ook een klein bedrag fiatteert. Ik ga ervan uit dat die code uniek is voor de getoonde combinatie bedrag/rekening nummer.

En ik ga er nog steeds van uit dat de generator zo ontworpen is dat de software geen OK kan geven.

Browser hijacking heeft geen nut bij bijvoorbeeld de Rabobank, omdat het bedrag dat je overmaakt een van de codegenerators is, en onder water het bankrekeningnummer waarnaar je het geld overmaakt ook een van de codegeneratoren is.

Daar kan een booswicht dus niet mee knoeien, zodat je raboreader altijd een code teruggeeft die gebaseerd is op bedrag en rekeningnummer.

Een Raboreader heeft onderhand iedereen wel, en je kunt er zoveel codes op genereren als je wilt. Als de code die gegenereerd wordt ook nog eens afhankelijk is van jouw bankrekeningnummer, dan wordt het wel heel lastig om het algoritme te kraken, en zelfs als dat lukt, dan heb je nog niet veel. Rabo introduceert dan gewoon een 3e code op de site (waardoor de raboreader een ander algoritme gaat gebruiken) en de boef is weer terug bij af.

What you have: raboreader, and what you know (your PIN) altijd handig.

Als je het echt wil weten zal je wellicht een aantal van die dingen te pakken moeten zien te krijgen en er cryptanalysis op loslaten. Leuke hobby, daar niet van.

Bij Man-in-the-Browser aanvallen helpen zowiezo de meeste token generators niet, waar de algorithmes ook op gebaseerd zijn, omdat je zelf de overboeking signeert. Bijv. je wil 50 euro naar het rekeningnummer van bol.com overmaken, je vult deze waardes(het bedrag en het rekeningnummer) dan in en drukt op Ok of verzenden. Net voordat ze verzonden zijn past de malware die op je systeem actief is deze waardes dan aan naar bijv. 1000 euro en een rekeningnummer in Afrika. De bank stuurt dan deze waardes weer terug samen met de code die je in je token generator moet invoeren en mogelijk gebaseerd is op rekeningnummers en bedragen. Voordat de browser dan dit weergeeft wordt het bedrag en het nummer dan weer aangepast zodat het slachtoffer niks doorheeft en de transactie signeert met de code die de token generator genereert op basis van de ingevoerde code. De criminelen kunnen dus niet naar wens allemaal transacties doen, maar ze kunnen wel elke transactie die door het slachtoffer gemaakt wordt naar wens aanpassen. De Rabobank heeft dan sinds kort dat er nog een 2e code moet worden ingevoerd voor het signeren, namelijk het bedrag. Als de criminelen dit dan aanpassen om geen argwaan te wekken werkt het dus niet meer omdat er dan een verkeerde code uit de token generator komt. Dus kunnen ze alleen maar het echte bedrag laten zien en is er een zeer grote kans dat het slachtoffer dit opmerkt aangezien hij/zij het zelf van het scherm moet aflezen en invoeren i.t.t. oplossingen die een kabel gebruiken. De criminelen zouden natuurlijk nog wel de bedragen ongemoeid kunnen laten en alleen bij elke overboeking het rekeningnummer kunnen aanpassen, maar dan zijn de inkomsten voor hen een stuk lager.

Waar ik wel benieuwd naar ben is het verschil tussen een token generator waarbij de bankpas moet worden ingevoerd en een waarbij dat niet moet zoals de Digipass.

Je illustreert iets wat een zwak punt van is van de token modellen, en (in principe) een sterk punt van het TAN via SMS model.

Je moet de bancaire tokens (abn e-denitifier, rabo random reader e.d.) zien als een tweede secure channel, met (helaas) een extreem lage bitrate .
De bankpas erin maakt het een per-klant uniek token, zonder dat het stukje hardware uniek hoeft te zijn.
Je kunt dus makkelijk even iemand z'n random reader/e-dentifier lenen op kantoor als je wilt internet bankieren.

De digipassen moeten zorgvuldig aan de klant gekoppeld worden, en authenticeren slechts de klant, niet de transactie die door een compromised systeem naar de bank gestuurd wordt.

De bedoeling van dat tweede kanaal is *de transactie* *die de bank ontvangen heeft* bevestigen.
En het lastige is, dat de gebruiker liefst de hele transactie via dat tweede kanaal zou moeten bevestigen, handmatig, en zodanig dat de gebruiker snapt dat het om de transactie gaat.

De bank zou natuurlijk een hash van de hele transactie kunnen sturen, maar de gebruiker kan die niet zelf genereren, (want je kunt nu juist niet vertrouwen op de desktop computer).
Dus moet je de gebruiker een paar getallen, waaronder dan het bedrag wat de gebruiker denkt over te maken , laten intoetsen en daarmee genereer je een uitkomst die dienst doet als shared secret tussen gebruiker en bank.

Nu is het aantal getallen wat je kunt laten intoetsen erg beperkt, en het uitleggen dat het echt om het bedrag gaat en niet blindelings overtypen wat het scherm zegt is heel lastig.
Nog lastiger als een 'telefonische helpdesk' mensen 'door de storing heen praat' .

Het nieuwere ABN token, wat je via USB aan de computer koppelt kan in het display meer gegevens van de transactie laten zien.
Daarmee is de bitrate van het secure channel met de bank een stukje hoger geworden. Het is natuurlijk wel zaak dat het token dan ook echt een 'trusted component' vormt, en niet gecompromitteerd kan worden om een andere transactie te laten zien dan dat er getekent wordt.

De TAN vis SMS systemen hebben als voordeel dat ze (maar liefst) 160 karakters kunnen gebruiken om te vertellen welk(e) bedragen waar naar toe gaan. Heel wat meer dan je kunt laten intypen [zonder al je klanten kwijt te raken].
(het aanvalsmodel hier zit in compromised smart phones, en gewijzigde telefoonnummers bij de bank).
Maar zelfs dan zijn er nog steeds mensen die blindelings een transactie bevestigen ook al zegt de SMS dat er een ander bedrag ergens naar toe gaat.
Banken kijken dan ook naar afwijkende patronen, en denken over modellen waarbij 'standaard' transcties meteen doorgaan, en alleen afwijkende via SMS bevestigd moeten worden. De gedachte is dat als de TAN-uit-SMS inkloppen geen blinde routine is, de SMS beter gelezen wordt.
(lezers van Bruce Schneier, en Ross Anderson weten al langer dat de psychologische component van security [cq human interface, workflow, ] gewoon heel erg belangrijk is. Security falen hangt zelden echt op de cryptografie; En 'de gebruiker de schuld geven' is mischien lekker voor security experts, maar de faal is er, en de schuld geven of verschuiven doet daar niet aan af ).

Het idee achter zo'n token-ding is dat je wat moet weten (je password om in te loggen) en wat moet hebben (token). Hetzelfde idee als je PIN en de pas waar die bij hoort. Dat token is uniek voor jou. Dat 'uniek' maken kan op een aantal manieren. Verder voeren vrijwel alle tokens een vorm van versleuteling / hashing uit op de aangeboden data. Ergens wordt er 'jouw geheime nummer' bij betrokken om het voor 'anderen' onmogelijk te maken om dezelfde bewerking te doen.

Het heeft dus - in deze context niet zo heel veel met browser hacking ofzo te maken, behalve dat 'meekijken' een password bloot legt.

Een manier om een token uniek te maken is je bankpas erin stoppen. Alle tokens zijn voor die bank dus gelijk, het 'geheim' staat op je bankpas (en het zou zelfs kunnen dat de bankpas ook de bewerking doet - token is dan alleen een stel knopjes en een display om met je bankpas te communiceren). Dat heeft voor de bank vooral een logistiek voordeel: als je token stuk is, kun je die van de buren pakken en men hoeft niet bij te houden wie welk token heeft (en voor de pas moest dat toch al bijgehouden worden...)
Een andere manier is om 'het geheim' in het token te stoppen. Dan zul je vaak zien dat ook het token een vorm van PIN heeft. Voordeel daarvan is dat iemand die PIN + pas heeft nog niet kan overmaken. Voor de bank wel wat meer logistiek.

Een aantal banken stopt nu het totaal bedrag ook in zo'n token-actie. Dat is een op zich goede poging om niet alleen de transactie maar ook het bedrag te authoriseren. Als er een MitM aanval plaats vindt, dan kan de aanvaller dit niet aanpassen zonder ook het antwoord aan te passen - en als de crypto fatsoenlijk in elkaar zit, gaat dat laatste 'm niet lukken.

Wat ING nou precies wil met die PAC ontgaat me volkomen. Hoe gaan zij constateren of ik 'op de gebruikelijke computer' inlog? Cookies? Die gaan na elke sessie naar /dev/null. IP address? Elke dag een ander. User agent string? Ik speel er regelmatig mee. Ik ben wel benieuwd om te achterhalen hoe ze zoiets menen te kunnen detecteren. Daar gaan we de komende weken ongetwijfeld meer over horen - ik vrees vooral in negatieve zin. Maar je weet nooit...

Hoe komt het toch dat security nerds alleen vanuit zichzelf denken ?
Hoe normaal is het dat iemand met een user agent string zit te spelen ?
Op hoeveel verschillende IP adressen werk je nu echt?

Hoeveel van die miljoenen ING klanten bankieren nu via TOR ?

Als JIJ security architect was, en als werk had om het _zo goed mogelijk_ te doen, ga je iets dan NIET doen omdat een nul komma niks percentage klanten een extreem ongebruikelijk patroon heeft waarbij een aanpak vals alarm geeft of niet bijdraagt ?

Ik denk dat kijken naar 'normale patronen' voor een klant een prima methode is die bij BIJNA ALLE klanten een heel standaard beeld geeft, en waar een hack of compromised access meteen uitspringt.
Er is vast wel eens iemand die in de lounge op schiphol bankiert, en een paar uur laten ook bankiert in Boekarest.
Maar get real, voor vrijwel alle klanten is een access vanuit NL en daarna .RO een enorme red flag, en terecht.

Kijk eens naar wat 'normale mensen' , vraag waar ze internet bankieren, en dan kom je gegarandeerd op een heel beperkt patroon van thuis, kantoor, mobiel device (ook een behoorlijk stabiel ip) en wellicht een patroon van een paar IPs die van pubieke horeca wifi zijn. En misschien twee keer per jaar (zomer en winter) access vanuit de zon of ski gebieden.
Daar kun je dus prima afwijkingen uit halen, en speciaal behandelen.

Dit soort dingen zijn prima ideeen. Je moet ze niet verkopen als 100% sluitend, maar ze _afdoen_ vanwege 0.001% niet passend is pas echt dom.

Bedankt voor de reacties :)