Phishers proberen token based beveiliging te omzeilen

Naar verluidt hebben phishers een nieuwe aanvalsmethode aangeboord om klanten te misleiden tijdens hun onlinebankieren. Ongeveer vijfendertig websites zouden opgezet zijn om zogenaamde 'man-in-the-middle'-aanvallen uit te voeren. Bij wijze van verdediging tegen de vele phishingpogingen, voerden veel banken een systeem in dat gebaseerd is op tokens en tijdelijke wachtwoorden. Hierbij wordt met behulp van een apparaatje een code gegenereerd als antwoord op de door de banksite voorgestelde code. Zolang het algoritme waarmee dat antwoord gegenereerd wordt geheim blijft, kan men niet inloggen op de beveiligde site. Door gebruik te maken van een doorgeefluik, zouden de phishers er echter alsnog in slagen de rekeningen van hun slachtoffers te plunderen.

Zij zetten namelijk een website online die er volledig uitziet zoals de site van de geviseerde bank. In plaats van de inloggegevens te verzamelen, worden deze echter onmiddellijk doorgegeven naar de echte banksite, inlusief de gegenereerde tijdelijke code. Zo slagen de phishers er alsnog in controle over de rekeningen van het slachtoffer te krijgen. Johannes Ullrich van het SANS-instituut benadrukt dat systemen die gebaseerd zijn op tokens efficiënt blijven tegen kwaadaardige software, waaronder trojaanse paarden. 'Bovendien worden gebruikers zich steeds bewuster van de gevaren van internet, wat de doelgroep van deze phishers verkleint', aldus Ullrich.

Reacties (89)

[I.R. Overclocked]

En hoe merk je dat dan? Alleen als er geen certificaat is, of hebben ze die ook nagemaakt?
En trouwens, voor overboekingen hebben ze opnieuw je code nodig, dus eigenlijk kunnen ze alleen je saldo bekijken...

[DynamicDreams]

De phising-site geeft gewoon de melding dat de code onjuist is (terwijl hij juist was) en vraagt opnieuw om een code. Die laatste code wordt vervolgens gebruikt om de betalingen te fiatteren.

[Verwijderd]

Volgens mij kan dat hier in Nederland niet of wel??
Ik zit bij de rabobank en moet een andere handeling doen om een code te krijgen voor betalingen als voor het inloggen op de site.
Is dat dan niet een ander algoritme?

[jp]

Bij de rabobank heb je voor inloggen nodig:

pasje in lezer
druk op I
voer pincode in
ok
voer code website in
ok
ok
voer code van lezer op website in

En voor signen betaling:
pasje in lezer
druk op S
voer pincode in
ok
voer code website in
ok
ok
voer code van lezer op website in


Daar wordt mee voorkomen dat de inlogcode gebruikt kan worden voor het goedkeuren van de betaling.

[DynamicDreams]

Ok, dan maak je voor de Rabobank een extra brug:
Nieuwe gebruiksvoorwaarden voor Internetbankieren die je moet ondertekenen (S) voordat je verder kan met "Internetbankieren".

[DynamicDreams]

Situatie bij ABN AMRO is zo:

1. Je logt in met de gegenereerde code
2. Je gaat naar het scherm voor overboekingen en maakt een opdracht voor een x-bedrag.
3. Je gaat naar het fiatteringsscherm, neemt de code over in de E-Dentifier, je krijgt een respons en die vul je in.
4. Betaling is klaar.

Via een phising site kan het zo:
1. Je logt op de phising site in met de gegenereerde code.
> Op de achtergrond logt de phising site in op de ABN AMRO-website met de door jou gegeneerde code
2. Jij krijgt een melding dat het "inloggen niet goed is gegaan".
> De phising site vult op de achtergrond het overboekingsscherm in
3. Jij probeer nog een keer in te loggen.
> De phising site fiatteert de overboeking met jouw 2e gegeneerde code.

En weg is je geld!

[DynamicDreams]

@MarcusKara:
Ik denk dat je mij niet helemaal begrijpt. De phising-website logt realtime in bij jouw bank met de code die jij de eerste keer hebt ingetikt. De phising-website gaat vervolgens alvast het betalingsscherm invullen en de overboeking klaarzetten. Vervolgens moet de betaling gefiatteerd worden en moet de phising-website een antwoord geven op de laatste validatiecode. Deze code stuurt de phising-website door naar het "slachtoffer" omdat het inloggen "niet gelukt" is. Het slachtoffer genereert een nieuwe code en vult deze in op de phising-website. De phising website gebruikt DIE code om de betaling te fiatteren. Zó kan het dus wel, toch? (of zie ik wat over het hoofd?)

[c.baas]

Je moet bij de Rabo een code van het scherm overnemen als je fiatteert. Dat doe je niet bij het inloggen. Dus die code kan niet voor beide handelingen gebruikt worden.

[Patriot]

Phishers vinden wel een andere reden om de gebruiker een S code in te laten vullen. Als het leuk klinkt zullen veel mensen het doen hoor.

[Darkprince1234]

Nou knappe visser die mij dat laat doen.

IEDEREEN die bij de rabobank zit weet dat je daarmee een betaalings opdracht bevestigd! ....ach ja oma....

[Verwijderd]

Bij de postbank kan je wel inloggen met username / password combo maar daar is het doen van transacties extra beveiligd. Zo kan je je overschrijving pas 'opsturen' als je een TAN-code invult die je of per sms ontvangt of van een A4 af moet halen die je per post hebt ontvangen. Het zou nog netter zijn om ook een soort sms TAN-code te introduceren bij het inloggen.

[martijnvanegdom]

SNS heeft het zeflde systeem, maar het is een 'koud' kunstje om ook DAT te kopieren..

[lunar]

Volgens mij, maar ik kan me vergissen, hebben ze bij de Rabo ook nog een beveiliging ingebouwd bij grote bedragen. Zodra het bedrag een bepaalde waarde overschrijdt, wordt het bedrag meegenomen in de code die op de site wordt gegenereerd en die je moet invoeren in je 'rekenmachine'. Mochten de phishers dan toch de mogelijkheid zien om er een betaling naar hun rekening tussen te zetten nadat jij de bevestigingscode hebt gegeven, dan zal de Rabo de code niet accepteren, want het bedrag dat overgemaakt moet worden komt niet overeen met het bedrag waarover de code is berekend.
Indien de phishers de overschrijving voordat je de code moet invoeren ertussen stoppen (en dus de code wordt gegenereerd over hte bedrag inclusief het te stelen geld), dan komt hij er bij het rijtje tussen te staan (als het goed is en de phishers dat er niet tussenuit filteren) en kun je dus zelf zien dat er een rare overschrijving tussen staat. Bij de Rabo ben ik dus niet zo bang dat er snel wat mis zal gaan.

[DynamicDreams]

@c.baas & lunar:
Bij de Rabo vang je de inlogcode af en log je als phisher onmiddelijk na het onderscheppen in.
De phisher vliegt naar het overboekingsscherm en maakt de overboeking.
Dan laat je het "slachtoffer" een code genereren middels het volgende:
>> U moet onderstaande "nieuwe voorwaarden" ondertekenen voordat u verder kunt op internetbankieren (Druk op S (bla bla)) (resultaat: een geldige code om de overboeking te ondertekenen).
Is het bedrag te hoog om met 1 code te ondertekenen, dan doe je alsof het "slachtoffer" de gegeneerde code onjuist heeft overgenomen. Het "slachtoffer" maakt nogmaals een code via de S-functie en vult deze in. De phisher vangt deze code ook af en ondertekend de betaling definitief.

[Verwijderd]

@4np: Lekker safe.... en hoe gaan die sms-jes door de lucht? right... in plain text. ok je moet in de buurt van de mast zijn waarmee ze verstuurd worden maar het is niet al te moeilijk dit te sniffen....

[Punksmurf]

Nu heb ik mijn vraagtekens bij het gemakkelijk te sniffen-deel, maar goed. Die code is iig gelinkt aan een bepaalde set overboekingen die je op je scherm hebt staan. In het sms'je staat ook het totaalbedrag van die overboekingen. Als dat dus niet klopt met wat je op je scherm hebt staan is het duidelijk dat er of iets fout gaat, of dat er iemand loopt te phishen.

[Verwijderd]

Elke internetbankierder weet wel dat je alleen de S knop en de 2e+3e invoer gebruikt worden om geld over te maken (ja toch?).

En het valt toch op bij rabobank dat er vanaf 1 IP opeens met honderden bankrekeningen tegelijk wordt ingelogd en geld wordt overgemaakt.
De rabobank zal waarschijnlijk indien mogelijk alle overboekingen vanaf dat IP ongedaan maken.

[Ge Someone]

Bij Postbank kun je meer dan 1 betaling doen met 1 TAN code. De phisher zou dus er eentje kunnen toevoegen (is al eerder vertoond met spyware-achtige malware, maar die moest eerst op PC van gebruiker actief worden.)

[Verwijderd]

Er wordt toch geen rekening nummer bij die TAN code verzonden?

Zonder rekening nummer heb je niks aan die code (doet me trouwens denken aan stuk uit van davinci code, bij de zwitserse bank).

[Verwijderd]

@Dynamicdreams: Heel leuk bedacht dat werkt niet. Niet zozeer met Rabobank of ABN-Amro. Rabobank gebruikt idd andere handeling dan ABN/SNS etc.
Maar de code wordt pas geactiveerd als de site 'm opvraagd.

Als de eerste "mislukt" is zoals je zegt en die bewaard is er geen garantie dat de ECHTE bank site die eerste code vraagt en dus de eerste antwoord verwacht. De site verwacht maar 1 code terug. En dat kan nooit dezelfde zijn dan de identify code. (Waarom dan nog een keer code intikken voor signen). Kun je net zo goed code bewaren in sessie/cookie etc.

Op jou manier zou je altijd 1 code combinatie kunnen gebruiken tenzij hij door tijd niet meer geldig is. Gelukkig zit het stuk beter in elkaar. Door altijd te valideren kom je heel stuk verder. Oude codes uitschakelen totdat je rondje hebt gemaakt en je er weer bent...

[Verwijderd]

ik denk dat daar genoeg mensen in trappen ja.

[OverSoft]

@Ge Someone:

Ja, dat klopt, maar er staat ook een bedrag in die SMS.
Als dat bedrag in een keer 10000 euro hoger is, valt dat nogal op

[Verwijderd]

Je vergeeft dat een deel van de code het bankrekening nummer is waarnaar je wilt overboeken. En voor sommige banken ook het bedrag

Als de phisher die wijzigt klopt de code niet meer....

John

[Zwatelaar]

Bij ABN-AMRO gaat die vlieger niet helemaal op (heb geen ervaring met andere banken).
De codes die je voor het inloggen en fiatteren gebruikt zijn niet even lang. Ze kunnen dus met een inlog-response-code niet een betaling fiatteren.

Komt nog eens bij dat een gegenereerde code zeer beperkt houdbaar is (ongeveer halve minuut). In de algoritme zit namelijk de tijd en datum verwerkt.

Probeer maar eens paar keer achter elkaar een code te genereren met dezelfde invoercode. Je krijgt op een gegeven moment een hele andere code als response.

[berend_engelbrecht]

Alleen als je op de rekenmachine naast een code ook een totaalbedrag zou moeten invullen ben je redelijk veilig voor dit soort phishers. De truuk is dat het mislukken van de transactie of het tonen van niet-standaard webpagina's (zoals hierboven een paar keer verondersteld wordt) helemaal niet nodig is. De transactie mag gewoon slagen, de phisher vult achterliggend alleen een ander bedrag en ander rekeningnummer in. Waarom zou het hem iets kunnen schelen of de werkelijke begunstigde al dan niet z'n geld krijgt? Op die manier ziet de site er precies hetzelfde uit als normaal en is ook het gedrag exact dat wat je gewend bent. Dat is natuurlijk veel beter om geen argwaan te wekken.

Trouwens... als je het bedrag op je rekenmachine moet invullen, denk ik dat er nog wel phishers zijn die met hetzelfde bedrag dat jij probeert over te boeken ook wel tevreden zijn. Vele kleintjes maken immers 1 grote.

De bank kan zelf trouwens wel wat doen aan man-in-the-middle attacks. Op het moment dat je site vlak na elkaar van verschillende rekeninghouders validatieverzoeken ontvangt waarbij steeds hetzelfde IP-adres gebruikt wordt, kan je aan de serverkant weten dat er iets mis is. Zeker als blijkt dat dat IP-adres een bekende "anonymous" proxy is (daar kan je gewoon op googelen, voorbeeld).

Ik heb enige tijd een webshop gehad en wij deden een dergelijke controle omdat we niet tevreden waren met het percentage fake betalingen dat er bij onze credit card payment provider doorglipte. Het was soms wonderlijk te zien hoe snel een IP-adres door de wereld reisde . Ik vemoed echter dat voor een online banking site het moeilijk is om opeenvolgende validatieverzoeken op IP te vergelijken vanwege het volume van de betalingen in het algemeen en het feit dat ze een serverfarm gebruiken om dat volume te verwerken.

[DynamicDreams]

@Zwatelaar:
Ik heb er eerlijk gezegd nooit op gelet of die lengte van de code anders is. Maar zoals de eerder gegeven mogelijkheid: laat de gebruiker "nieuwe gebruikersvoorwaarden" ondertekenen en je hebt alsnog een geldige code.

[TERW_DAN]

Wat je daar zegt klopt niet.

de codes om in te loggen en om te fiatteren zijn beide even lang (6 karakters) en daarbij is de code altijd hetzelfde (als je dezelfde invoer gebruikt).
Je e-dentifier weet echt niet hoe laat het is, en als die code continu verschillend is, hoe weet de site dan dat ik de juiste inrammel?

[Zwatelaar]

@ trew_dan
Het zal toch niet zo zijn dat de bank die jou de e-dentifier geeft het algoritme heeft en hetzelfde doet om jouw code te checken. Nee, het zal wel veel simpeler zijn dan dat

[TERW_DAN]

Jawel, zowel het inloggen als dingen bevestigen gaan via het algoritme van de e-dentifier.
Dus ze checken dat wel (anders zou het natuurlijk erg onveilig zijn).

[Reobedr]

edit: @Dynamicdreams

Toch gaat het verhaal zoals jij dat noemt niet helemaal op. Je moet namelijk bij het signeren het volgende doen:
druk op S
pincode
signeercode overnemen in random reader
ok
ok
dan code invullen op rabo site.

Als het om groot bedrag gaat moet je na de 1e keer ok een tweede code invullen en krijg je dan pas je signeercode.

2x het "s-menu" doorlopen is dus niet voldoende om een groot bedrag over te maken.

Doorgeven dat de code onjuist is overgenomen heeft dus geen zin...

[Countess]

ander webaddres is meestal het duidelijks te zien.

en ja precies dat zat ik net ook te bedenken.
maar in america is het on-line bank systeem een stukje minder veilig.
niet zo heel lang geleden was het voor een aantal banken enkel beveiliged met een user/password combie, en was je binnen kon je alles doen.

[Verwijderd]

bij beleggingssites kun je iemands portefeuille vernaggelen.

[GekkeKoe]

Het adres is nog altijd ietsjes anders. Gewoon nooit via een link in een email naar je bank site gaan, maar zelf intypen of via een bookmark, en dan NOG de URL checken voor je gevoelige gegevens invoert.

[Standeman]

Totdat ze m.b.v. een trojan je /hosts hebben aangepast

[TD-er]

Je hosts-file aanpassen is inderdaad makkelijk mogelijk en gelukkig ook makkelijk te controleren.
Maar hoe weet je zeker dat de DNS-informatie die je van je provider krijgt, klopt?
Die vragen het ook maar weer aan een andere server.
Kortom als je als phisher een grote slag in een keer wilt slaan, pak je ook de DNS van een NLse provider aan en maak je een NLse bank-site na.
Zoiets hoeft maar een uurtje te werken om erg veel geld binnen te halen en als phisher hoef je in principe maar 1 persoon over te halen de DNS-cache aan te passen van 1 site van 1 grote provider.

[GekkeKoe]

Een anti-virus/anti-spyware die trojans blokkeert én de HOSTS file controleert is dan ook geen overbodige luxe meer tegenwoordig.

[Gerco]

En hoe merk je dat dan? Alleen als er geen certificaat is, of hebben ze die ook nagemaakt?

Certificaat hoeven ze niet na te maken. Het enige wat ze moeten doen is een NIET SSL site neer te zetten. Als mensen een certificaat warning krijgen, krijgen sommigen argwaan (al zullen dat er heel erg weinig zijn).

Krijgen ze geen error (dus bij een kloppend certificaat of GEEN certificaat), is alles koek en ei en zullen de gebruikers niets in de gaten hebben.

[n4m3l355]

Certificaat kun je zelfs zo aanvragen, er wordt pas nagekeken of er misbruik van deze wordt gemaakt zodra er klachten over komen. Was nog onlangs op tweakers en slashdot. Maw certificaten zijn op zich doeltreffend echter laten nog steeds een mogelijkheid open tot misbruik.

[kozue]

Als je de site 100% nabouwt kun je natuurlijk de gebruiker op jouw fake site transacties uit laten voeren, en weer opnieuw de code aan de echte site vragen.

Ook is een certificaat aan te maken die heel erg lijkt op het origineel. Als het certificaat klopt voor de nepsite, zal de browser er niet moeilijk over doen, en de meeste gebruikers lezen waarschuwingen over certificaten toch niet, want daar snappen ze niks van.

[Wilke]

En hoe merk je dat dan? Alleen als er geen certificaat is, of hebben ze die ook nagemaakt?

Doordat de URL anders is, maar dat is dankzij unicode en (in dit opzicht) "brakke" fonts niet altijd goed (of uberhaupt) te zien.

Certificaten zijn in principe niet na te maken (dat is tenslotte het hele idee), tenzij je het wachtwoord van de betreffende certificate authority (CA) weet.

Dit neemt natuurlijk niet weg dat er altijd "domme" mensen zijn die elke waarschuwing (en met name die over niet kloppende certificaten, die komen immers zo vaak voor dankzij "self-signed" CA's die veel webhosters gebruiken) wegklikken.

Wat hierbij natuurlijk ook niet helpt is dat banken hier ook nog wel eens fouten bij maken, door certificaten domweg te laten verlopen en dergelijke. Ik heb dit bij m'n pa wel eens zien gebeuren, de postbank had toen het certificaat dat ze gebruikten om hun Java-applet te signen laten verlopen. Het gewone certificaat voor de website was wel verlengd. Beetje knullig want dan krijg je dus alsnog waarschuwingen - tenminste, als het goed is! (d.w.z. in IE dus niet, misschien omdat ze daar een ActiveX component gebruiken dat met een andere key is gesigned, of omdat IE zuigt en dit gewoon negeert, of weet ik precies waarom).

In ieder geval heb ik m'n ouders redelijk afgericht om in dat soort gevallen eerst mij te bellen, maar zelfs mij koste het 5 minuten om te achterhalen of het nou echt wel goed zat...

[Rekcor]

Hier de (onvermijdelijke ) Wikipedialink: http://en.wikipedia.org/wiki/Man_in_the_middle_attack

[Quacka]

Nu zit ik gelijk aan Ideal te denken (nieuws: Consumenten betalen nog nauwelijks met iDeal).

Je koopt op een site een nieuwe cd/dvd/weet ik veel wat. Je krijgt een betaalscherm van Ideal, maar deze is vervalst op deze manier.
Hoe kan ik dan zien dat het vervalst is? Want de betaling doe ik via de site van bedrijf X en niet via mijn normale snelkoppeling naar rabobank/abn of wat voor bank dan ook.

@Maikelvu: maar als er dan maar een klein verschil is (zoals ergens hierboven vermeld anb-amro ipv abn-amro), dan is hier snel overheen gekeken. Plus het feit dat veel mensen hier dus echt niet naar gaan kijken.

[Maikelvu]

Bij een Ideal betaling wordt je altijd doogestuurd naar de site van je bank. Je kan dus gewoon aan het adres zien of het wel echt de site van je bank is.

[Verwijderd]

"To avoid man in the middle attacks, A and B need to ensure that the public keys they receive from each other are genuine. One way to do this is for each principal to disseminate a hash of her public key using a higher intergrity channel."
Bron: Security for ubiquitious computing, door Frank Stejano.

Om dit te bewerkstelligen kunnen banken via de post of mensen via hun visitekaartjes deze hash code verspreiden, ervanuitgaand dat deze kanalen een hogere integriteit bevatten.

[justice strike]

hier gaat men ervan uit dat alles gencrypt is met de public keys.

In het geval van banken is dit niet het geval Het bedrag en de rekeningnummers vul je namelijk op de site in. Enkel en alleen de hash key moet je met de public/private key genereren.

Ik wist al vanaf het begin af aan dat internet bankieren hiervoor gevoelig was. en een tikfout is ook snel gemaakt (anb-amro.nl?)

postbank is overigens nog onveiliger. aangezien het vaste code's zijn die vooraf gedefinieerd zijn ipv hashes

Er is volgens mij niet echt een manier om een website hiertegen te beveiligen. Simpelweg omdat het er niet voor bedoelt was

[- peter -]

Lang leve het Postbank SMS systeem.

Bij elke transactie krijg je via sms de TAN code die je moet invoeren + het bedrag dat bij die transactie behoort.

Op die manier kan je dus altijd er zeker van zijn dat alleen transacties die door jou zijn uitgevoerd geauthoriseerd worden.

[Verwijderd]

Bij de postbank kun je zelfs met het SMS TAN systeem nog wel overboekingen van gebruikers naar andere rekeningen websluizen met een man in the middle attack.
Doordat de bankrekeningnummers niet zichtbaar zijn in de SMS is dat niet detecteerbaar door de gebruiker.

Een minder voordelige manier omdat je erg afhankelijk bent van wat de klanten willen overmaken.

[[NUT]]

dat is niet geheel waar trouwens: je krijgt een overzicht van de betalingen voor je naar de tan-request gaat: hier kan je de laatste check op bedrag en rekeningnummers doen. Hier kan echter NIETS aangepast worden.

[Milky Way]

In de SMS staan de laatste vier cijfers van de rekening waarnaar de grootste overschrijving gaat

[Ramzzz]

En dat gaat goed zolang die TAN-code niet onderschept wordt terwijl je bezig bent met overboeken en iemand je voor is, hetgeen bijzonder onwaarschijnlijk is. Een TAN-code is slechts éénmalig geldig, en je voert 'm in ter bevestiging van je overboeking, dus je hebt 'm pas een paar seconden voor afronding van je transactie. Ik wis 'm altijd direct na verificatie van de bevestiging van overboeking.

[miw]

Een eindgebruiker kan die TAN code niet verifieren. De man in het midden geeft de eindgebruiker de TAN code van een andere transactie (met het juiste bedrag).
Als phishing werkt, kan een goede phishing website alle bestaande Nederlandse internetbankiermethodes zonder probleem aanvallen met de beschreven onderscheppingstechniek.

[Verwijderd]

Op zich zou de postbak de SMS TAN code kunnen matchen met het over tere maken bedragen en eventueel de bankrekeningnummers.
Dan heeft het geen zin om de code te onderscheppen want de TAN code is dan uniek voor een specifieke transactie en je kunt er geen andere transactie mee uitvoeren. (overigens wordt de Postbank SMS TAN code vermoedelijk nog niet op die manier gematched)

[[NUT]]

Waarom phishing op de postbank site niet zondermeer lukt:

- De tan code word inclusief het te transporteren bedrag (met het grootste bedrag uitgesplitst indien dit groter dan 500euro is) naar je toe ge-SMS't
- daarnaast kent de TAN code een volgnummer.
- De SMS komt van de POSTBANK en niet van een telefoonnummer.
- Het totaal bedrag en volgnummer zijn terug te vinden op de website waar je de TANcode invoert
- Voer je een betaling in en vraag je een TAN code aan, en je maakt vervolgens NOG een betaling aan en je wil de eerste TAN code gebruiken, dat kan, maar niet voor de laatst ingevoerde betaling: deze is gekoppelt aan de betalingen die klaar stonden op het moment van aanvragen; de nieuwe betaal opdracht behoeft een nieuwe TANcode.

Het enige wat je heel fout kan doen is inderdaad iemand je login/password geven of laten ontfrutsellen... dan kan iemand het mobiele nummer veranderen. Maar ik geloof dat de mobiele telefoon die word 'afgemeld' dan ook een SMS ter bevestiging krijgt... wat natuurlijk meteen opvalt als jij de aanvrager van de aanpassing niet bent

[freaky]

Inderdaad, ze hadden hierboven niet goed gelezen want in de post hierboven stond ook al vermeld dat het TOTAAL bedrag vernoemd werd...

Naast dat dit systeem dus nog eens veiliger is, is het ook nog eens vele malen gebruiksvriendelijker. Word helemaal gestoord van die codes die je over en weer moet typen bij de rabo. Gebruiksvriendelijkheid hebben ze nog niet van gehoord geloof ik.

[DiedX]

Dit is iets wat iedereen zelf had kunnen bedenken. Wat wel van belang is is dat je gewoon bekijkt bij opdrachten WELKE bedragen je overmaakt. Maar dat is iets wat je zowiezo moet bekijken!

[SilverMane]

De phising site toont gewoon het gewenste bedrag. Terwijl "zij" een ander bedrag zien.

[kamerplant]

De Postbank TANCode SMS zend ook het bedrag mee. Indien een pishing website een extra bedrag wil overmaken naar een eigen rekening zal dit alsnog opvallen. Indien de pishingwebsite het bedrag onveranderd laat, maar enkel het rekeningnummer veranderd valt dit helaas niet op.

Het Postbank systeem is opzich behoorlijk veilig. Het lijkt me zelfs veiliger dan een cardreader (like Rabo). Indien het algoritme van zo'n cardreader wordt gekraakt moet iedere cardreader worden vervangen, de Postbank hoeft enkel een stuk code op hun servers te veranderen .

[mrdr]

volgens mij is het allemaal niet zomoeilijk. De phishers vult gewoon een extra betaling in, die zie je niet (de rest van de door jouw ingevoerde gegevens zie je wel) daarmee wordt een bedrag naar zijn/haar rekening overgemaakt en ben je de klos.
Alleen een systeem dat via een andere weg (niet via het de internetverbinding met je bank, maar via telefoon/sms, waarschijnlijk email) het over te maken bedrag meestuurd (zoals de sms van de postbank) geeft de gebruiker voldoende mogelijkheid te controleren of het goed gaat. Natuurlijk werkt dat alleen zolang de phisers niet tegelijk ook tussen de andere communicatie mogelijkheden zitten.

[Terracotta]

Wat ik me nog altijd afvraag is hoe ze er eigenlijk in slagen om in de adresbalk het echte adres van de bank te krijgen? Wordt er een (foute) kopie gestuurd naar de adresbalk of hoe werkt dat dan?

[Verwijderd]

Ik denk dat ze alleen maar een adres in de balk krijgen dat erg veel op het goede adres lijkt. En dat adres heb je zelf aangeklikt in bijvoorbeeld een mailtje dat je van je 'bank' hebt ontvangen.

[Joshua]

Gewoon je /hosts aanpassen door middel van een trojan horse

[bredend]

Op zich zou je met een soort proxy de html van de bankpagina kunnen aanpassen waardoor er automatisch een opdracht word aangemaakt, maar dat die steeds verborgen blijft. Met Virtualisatie technieken gaat dat nog makkelijker. Of een greasemonkey script natuurlijk

[Verwijderd]

Toch snap ik het niet hoe men op een dergelijke site komt als men een eigen bookmark gebruikt.

Volgens mij is het dan toch niet mogelijk, of men moet routers gaan hacken e.d., maar dan ben ik als gebruiker altijd de pisang.

Mensen moeten er volgens mij goed van doordrongen worden altijd de iegen bookmark te gebruiken en niet anders. Dan is de mogelijkheid van een nepsite het kleinste (denk ik).

Maar als ik het mis heb hoor ik het graag.

[Quacka]

nogmaals: "Ideal"
Zo kan je op zo'n site komen. Je gaat direct betalen, maar betaalt ipv 20 euro voor een dvd 10.000 euro voor diezelfde dvd..
Hoe langer ik erover nadenk hoe meer ik denk dat het klopt. Dit gedoe maakt Ideal direct onbetrouwbaar.

[Remus]

Met iDeal wordt je doorgestuurd naar de website van je bank. Je kan dus op de normale manieren verifiëren of je met de juiste site bent verbonden.

[Nightcrawler28]

doe dan ook de NL link naar wikipedia:

http://nl.wikipedia.org/wiki/Man-in-the-middle-aanval