Ook een Token beschermt je niet tegen een Trojan die een
lokale 'man in the middle attack' uitvoert. Je keurt het
doen van een transactie goed en niet de inhoud van de
transactie.

Zie oa dit filmpje waarin een 'proof of concept trojan' laat
zien dat een Token, zoals gebruikt door de Nederlandse
banken, niet voldoende is.:

http://www.rtl.nl/(channel=rtl4,progid=rtlnieuws,template=/actueel/rtlnieuws/video_template.html)/system/media/html/FFFFFF/actueel/rtlnieuws/miMedia/2005/week26/donderdag_800_internetbankieren.avi_plain.xml

Ik bel nog gewoon in bij de postbank om daar fijn te girotellen.
Ouderwets maar zeer effectief, en veilig.

Zover ik weet is de informatie niet versleuteld bij Girotel bij inbellen. De
website daarentegen is dat wel.

Ondanks dat de trojan mij niet zal lastig vallen (werk met
linux), doe ik toch om dit soort redenen niet aan internet
bankieren. De kans dat er iets mis gaat, is gewoon vele
malen groter dan met papier. Daarbij is het risico voor de
klant ... mij niet gezien dus ... laat de banken eerst maar
eens zoveel vertrouwen krijgen dat ze zelf het risico
dragen, misschien dat ik dan ga twijvelen.

Maar wel iets veilger. Niet iedereen zal even een
telefooncentrale hacken om een nummer om te leiden. Daarbij
heb je bij het inbellen een directe verbinding.

De man in de middle moet dan wel de versleutelde SSL in
flight kunnen op pakken en bewerken en dat nog binnen een
bepaalde transactie tijd... want een transactie timeout is
er zo...en dan moet je weer opnieuw en dan is al duidelijk
bij het banksysteem dat dit niet goed zat.....leuk loggie
eruit etc.
Een token is maar heel kort actief.
Dus dat zit wel goed met tokens hoor.....

Dan moet er toch een van de machines uit de top100 van de
wereld in de middle staan en dan nog......

btw.....voorgaande bericht...ik gebruik voor het bankieren
natuurlijk een Linux systeem....zodat een lokale trojan al
wat moeilijker wordt.

Van iemand de volgende oplossing gehoord.

De methode om deze man in the middle attack te omzeilen is een extra
eis te stellen welke weg precies de datatransmissie moet plaatsvinden.
Gaat het via een omweg dan kan men de transactie alsnog deleten indien
de Postbank server deze informatie via die omweg ontvangt.

Voor de specialisten onder ons: wie kan een goede oplossing bedenken?

Klopt inderdaad wel. Maar de postbank doet alles om mensen
van de girotel af te krijgen. Vanaf volgende maand kun je
geen beleggingen meer veranderen. Onder het mom van we weten
niet goed wie de gebruiker is en of hij wel zijn beleggings
risico profiel heeft ingevuld wordt deze optie gewoon voor
alle gebruikers uitgezet. Typisch geval van
klantvriendelijkheid.
Vooral de argumentatie is geweldig. U doet een
overschrijving en wij weten niet zeker of al uw detals
kloppen. Erg fijn dat een bank niet weet of alle details
bij een overschrijving kloppen. Geeft mij erg veel
vertrouwen als klant. En internet is veilig want er staat
een dicht slotje in je browser. (dat verzin k niet maar
stond in de brief waarin deze service verbetering werd mede
gedeeld)

en wat als er een aanpassing in het tussenliggende internet
plaats vind? alles maar wissen dan?

Heeft iemand wel eens geprobeert oude TAN codes van een
reeds vervangen TAN lijst te gebruiken..........? (100 TAN's
van de oude lijst waren opgebruikt)

Yep, die werken ook weer..................!

Zolang jouw PC nooit met het Internet verbonden wordt is dat
een veilige optie.

Een keylogger registreert alle toetsaanslagen dus ook de
gegevens die jij invoert om aan te loggen aan girotel. Het
is alleen wat lastiger om via girotel de transactie te laten
mislukken nadat jij de TAN code heb ingevoerd, maar
onmogelijk is dat niet.

De volgende keer dat je weer op internet zit kunnen de
gegevens naar de maker van de Trojan of zijn opdrachtgever
verstuurd worden.

Een PC is best veilig zolang hij stand-alone is en blijft.

Sinds wanneer is dat een directe verbinding dan?
Telefoon werkt met virtuele circuits alles behalve direct.
Tenzij jij een kabel getrokken hebt tot bij postbank.
Ik vertrouw meer op SSL dan op de ptt

Het ontgaat mij volledig hoe Schouwenberg kan beweren dat het token
veilig zou zijn en de TAN-code onveilig.
Idd is het token met de man-in-the-middle aanval ook te kraken conform
het eerste commentaar. Redelijk logisch omdat hetzelfde communicatie
kanaal (internet) gebruikt wordt.
Daarentegen gebruikt de TAN juist een ander kanaal. Derhalve alleen als
de aanvallers ook dit andere kanaal kunnen onderscheppen en
manipuleren kunnen zij een geslaagde aanval doen.

Vraag: zijn er voorbeelden van gekraakte TAN-transacties ?
Verwachting: nee
Vraag: wat is de waarde dan van een bewering als die van Schouwenaar
als evident is dat het niet klopt......
Vraag: wat is dan de waarde van andere beweringen die bij zijn bedrijf
vandaan komen?
Is het allemaal maar commercieel gereutel?

Frits

Kan iemand voor mij als leek die deze materie wil begrijpen
uitleggen:
-de token beveiliging is dat via een calculator zoals die
van de RABO/ING?
-wordt in die verificatie het transactiebedrag en rek.nr. vd
begunstigde meegenomen?
-indien de vorige vraag met ja beantwoord wordt: dan is het
toch veilig?
-indien die vraag met nee beantwoord wordt: waarom niet dan.

M.b.t. het sms'en van de postbank:
Ik moet er niet aan denken dat iemand mijn mobieltje vindt
en een tan-code in mijn sms-inbox vindt en dan op ideeen komt...

Als er een Tan-code in jouw sms-inbox staat, dan heb je die toch al
gebruikt? En dan is het antwoord dat ie niet meer geldig is. Je kunt er
natuurlijk voor je vakantie een stuk of wat aanvragen, maar of dat slim is, is
een tweede.
Daarbij komt dacht ik nog dat als je een transactie open laat staan, d.w.z.
de ontvangen TAN-code NIET invult, hij na een bepaalde periode ongeldig
wordt (vraag me niet hoe lang, dat weet de postbank wel).
Het verliezen van een TAN-code lijst (de ouderwetse manier), of het
verliezen van je telefoon EN de inbraak in je account tesamen is wel
gevaarlijk.
De aanvaller moet dan dus weten wie je bent, waar je woont en je je
telefoontje afhandig maken.

Over je andere vraag:
Ja, klopt, het is met de calculator. Het transactie bedrag heeft niets te
maken met de calculatie op het token, of het vermeld wordt is daarom niet
relevant.
En nee, het is niet veilig.
Iemand die namelijk precies in het midden zit, dus tussen jou en de bank
in, de zogenaamde Man-in-the-Middle, kan alles op jouw webbrowser
toveren wat hij wil en andere antwoorden geven naar de bank.
Dus jouw overboeking van het zakgeld naar je kinderen, wordt door de MitM
veranderd in een overboeking van bijvoorbeeld je hele salaris naar een
andere rekening. Vervolgens presenteert de MitM jou het verificatiescherm
van het zakgeld, maar door de code met het apparaatje uit te rekenen geef
je in feite dan toestemming voor het grotere (ik hoop tenminste voor jou dat
het groter is ;-) ) bedrag.
De MitM geeft dan de code weer door en het grote bedrag wordt afgeboekt,
maar dat zie jij niet. Pas als je de volgende keer weer kijkt en de MitM zit er
niet meer tussen (die holt hard weg met het bedrag) dan zie je ineens dat
je salaris vertrokken is.

Nee... volgens mij zit de Postbank helemaal niet zo slecht met die TAN-
code, de experts komen wel met commentaar maar niet met bewijzen.

bij het gebruik van AES zal de MitM attack aan de hacker
veel plezier bezorgen om het zaakje te decrypteren, als je
het risico op een MitM attack gaat berekenen is dit bij AES
nagenoeg onbestaande bij oudere ecnryptiesleutels is dt ook
slechts zelden gebleken en heeft men nog steeds duizenden
pc's nodig voor de decryptie.. Bij AES zullen ze er wel lang
aan bezig zijn met de decryptie.

Wat ik in de discussies van de afgelopen dagen mis: blijkbaar wordt de
Trojan vanaf cracksites geinstalleerd. Wat doe je dan ook op dergelijks
sites, behalve dan om illegaal te downloaden? En is het dan gek om te
zien dat figuren van twijfelachtig allooi proberen mee te liften met
twijfelachtig gedrag?

Betekent dit dat alle verkeer van mijn PC altijd via MitM
loopt als die er is?
En kun je die niet detecteren dan?
En wat is nog het nut van SSL?

Des te meer blijkt dus weer: GRATIS bestaat NIET>...............
En voor "dieven" geen respect.

Ja.
Als er een MitM is en die weet bijvoorbeeld het IP-adres van de Postbank te
stelen door het om te leiden in de DNS-service en hij biedt jou een Nep-
Postbank site aan, dan kun je het verschil niet zien.
Echter tijdens het leggen de SSL-verbinding laat hij het certificaat zien.
Normaal gesproken heb je het "echte" Postbank certificaat al eerder gezien
en is die opgeslagen in je browser. Het certificaat van de Nep-site kent je
browser niet dus presenteert hij die.
Als je nu goed oplet zie je dat dat een ander certificaat is en stop je de
sessie, de praktijk zal echter zijn dat de meeste mensen dit certificaat
klakkeloos accepteren omdat ze in het verleden bij andere SSL-sites
gemerkt hebben dat je dat moet doen omdat je anders niet verder kunt.
Op het moment dat je Accepteert zit de MitM ertussen. Daar helpt ook geen
super-AES meer aan omdat die bij SSL encrypt van point tot point.
M.a.w. Er is een SSL-AES-encryptie van jou naar de MitM en van de MitM
naar de Postbank. Bij de MitM is het echter klare tekst, en bij de Postbank
natuurlijk ook. Alleen het transport is encrypt. De hacker hoeft dus
helemaal niets te decrypten omdat hij je voor het lapje gehouden heeft.

Echter omdat de TAN-code buitenom komt, over je mobieltje, kan de MitM
de transactie die je doet niet veranderen, want de TAN is namelijk
verbonden met de specifieke transactie, dus de TAN komt aan op je
mobiel, en daar zie je ineens dat je i.p.v. 15 euro naar je kind, 15.000 euro
naar een vreemde gaat overmaken, dat staat namelijk in dat smsje, dus
daar ruik je onraad en vul je de TAN natuurlijk niet in maar bel je de
Postbank op of ze nou helemaal gek geworden zijn.
hihi, het lijkt wel of ik aandelen heb, maar dat is niet zo, ik probeer het
alleen maar allemaal door te redeneren en dat doende ziet het er redelijk
goed uit.

Het nut van SSL overigens is dat als je een goed certificaat hebt, b.v. je
verbindt met je provider naar WEBMAIL via SSL, dat verder niemand kan
meelezen en dat is een stuk veiliger dan het gewoon maar versturen van
een mailtje.

Correct. Dat zou de MitM dan gedaan moeten hebben in de communicatie
vlak voordat om een TAN-code gevraagd wordt. De 15,30 euro zakgeld
wordt dan naar een ander nummer overgemaakt. Niet echt een
indrukwekkende en schokkende kraak.
Er staat mij overigens bij dat als het over te maken bedrag boven een
bepaalde grens komt, dat dan de laatste 4 cijfers van het doel gironummer
getoond worden in de sms. Maar dat weet ik niet zeker.

gecodeerde UDP pakketten....UDP heeft geen vaste sessie
route dus kan het volgende pakket en gaat ook vaak via een
andere weg....
en je kunt inplaats van TCP of UDP ook nog andere
protocollen nemen hoor.
Je kunt op IP een Niet standaard layer set maken....
Dus...dat gaan ze ook doen .
En die lagen worden niet openbaar.

Ik begrijp niet dat developers van de banken niet goed het
OSI model op school geleerd hebben, anders zouden ze die
kennis zo over kunnen zetten op ARPANET spullen. Het is niet
nodig alle communicatie standaarden te gebruiken maar wel de
modellen en daarmee kun je dus Na IP alles , zelfs een
complete GELD stack erop zetten.
Dus de transport layers kunnen anders zijn etc etc.....
no open source !!!!!! hahahaha no open protocols....hahahahaa
En dan maar hacken in die lagen!!!