e4ea schreef:Maar als ik het goed begrijp zijn de versleutelde gegevens van een https verbinding niet te achterhalen, ook niet wanneer ze worden onderschept en achteraf worden bekeken?
Kost idd erg veel moeite. Maar waarom moeilijk doen als-tie-makkelijk kan?
Veel makkelijker is niet door afluisteren de zaak flessen, maar door een MITM (man-in-the-middle) aanslag te plegen. En dat is nou waar het misgaat met internet bankieren.
Je route alle verkeer van een door jou gehackte ADSL/WLAN router (ik leg dit om begrijpelijke redenen verder niet uit) naar jouw
internet-zelf-verrijkings-paradijs (rusland?) door. Voor HTTP(S) requests naar de bank van het slachtoffer zet je een eigen HTTPS server in met een goed gelijkende pagina's. Je biedt natuurlijk ook zelf een DNS server aan die de zaak flest. De gebruiker krijgt gewoon zijn
alles-is-veilig-slotje te zien, en ook leuk, met een URL die echt helemaal lijkt te kloppen.
De gebruiker gaat trouw inloggen, en dan heb je in ieder geval het login + password te pakken. Echter het afvangen van codes of TANs is nog niet genoeg, want die zijn echt gekoppeld aan de transactie, en dat omzijlen lijkt me geen sinecure. (ik denk dat de banken brute-force pogingen direct detecteren en afkappen) Je moet dus zelf transacties kunnen initieeren, en dat lijkt me alleen eenvoudig te doen bij banken die geen TAN of code-generators gebruiken... En gelukkig zijn dat soort banken echt uitzonderingen...
Overigens ligt de saldo informatie dan al wel op straat... Niet leuk dus, en daar zeggen de banken dus niets over, of schuiven het af naar de gebruiker. (zoals gebruikelijk)
Edit:
een mogelijk zwak punt is dan evt nog de (kleine) mogelijkheid dat je de transactie zelf real-time aanpast (bijv. een extra opdracht toevoegen) en dan hoef je zelf geen codes aan te maken of te ondervangen. Alleen moet je de gebruiker dan ook wel een aangepast salso laten zien om vroegtijdige ontdekking te voorkomen. Phoeh, too much work for me...