Door RichieB: Door Anoniem: Ha, weer een security architect op het forum.
Verkeerd gegokt, maar bedankt voor het compliment.
Grijns. Het was natuurlijk een hint dat beste-nerds-staat aan de wal makkelijk praten is
Doe je best, beschrijf eens een van die talloos veiligere manieren.
Het What-You-See-Is-What-You-Sign systeem wat ABN-Amro aanbiedt met het USB token kan door de huidige malware niet worden gemanipuleerd. Het token maakt namelijk een end-to-end versleutelde verbinding met de ABN-Amro server. Daardoor zie je altijd in het LCD scherm van het USB token waarvoor je toestemming verleent. Natuurlijk moet ABN-Amro dan wel alle andere niet-USB tokens niet meer toestaan, maar dat vinden ze eng.
Best mogelijk dat ABNAmro ook kijkt waar bezoekers vandaan komen, en als tablets (ipad) daar een behoorlijk deel van zijn maken ze klant niet blij met "kan niet vanaf de iPad".
Security is een _middel_ geen doel .
Dan heb je ook nog kantoor gebruikers. Voor e.dentifier2 moet software geinstalleerd worden op de computer.
(voor windows en mac. Jammer met je ultra locked down OpenBSD bankier pc ... )
Dat mensen op kantoor soms even wat prive zaken regelen is meestal wel geaccepteerd. Software installeren op de kantoor pc is een stuk minder gebruikelijk.
Wel is het een forse stap vooruit ten opzichte van de reguliere bank tokens.
Het algemene doel is om via een trusted pad de transactie *die de bank ontvangen heeft* terug te melden naar de gebruiker, en de gebruiker die transactie te laten goedkeuren.
En dan ook zo duidelijk dat de gebruiker snapt dat dat is wat er gebeurt, niet zomaar "overtikken van wat getallen" .
Bij normale banktokens is dat 'trusted kanaal' van bijzonder lage bandbreedte; Een scherm voor een paar karakters, en de "input" is wat je een gebruiker nog kunt vragen om in te tikken. Waarbij de gebruiker moet begrijpen dat hij feitelijk z'n transactie deels (over) tikt in het token om aan te geven dat dat echt is wat hij wil.
Het SMS-Tan model van ING heeft wat dat betreft een stuk hogere bandbreedte in het beschrijven van de belangrijke delen van de transactie.
Ik kan niet direct vinden hoeveel informatie op het e.dentifier2 scherm past, en wat er meegegeven wordt.
Als de bestemming (doelrekening) niet goed genoeg zichtbaar is, kan een malicious host waarschijnlijk die wijzigen zonder dat de gebruiker dat direct ziet.
Of als de batch transacties wat groter is dan goed in het scherm past.
Nu had ik het even druk om meteen te reageren , en prompt een hack van e.dentifier2 . Zucht.
Uit goede bron hoorde ik (je blijft je verbazen...) dat mensen zelfs in het SMS model een transactie nog authoriseren , hoewel de SMS dus andere data meldde dan wat ze wilden overmaken.
Gewoon routine, bankieren, en echt blindelings de tan uit de sms overtikken zonder die sms nog verder te lezen.
Echte security is gewoon _echt_ moeilijk. Security die technisch correct is en waarmee je naar iemand kunt wijzen bij falen "had je maar ..." wil eventueel nog wel lukken, maar het falen blijft.
Een ander heel voor de hand liggende oplossing is alleen overschrijvingen toestaan vanaf een bekend veilig OS, bijvoorbeeld door USB drives of DVDs uit te delen. De gebruikers moeten daarvan booten zodat de eventueel op de harde schijf aanwezige malware buiten spel wordt gezet.
Om er voor te zorgen dat hierdoor niet meteen een grote groep gebruikers afhaakt omdat die vinden dat dit te lastig is kan er ook een knip worden gelegd, kleine bedragen (tot 500 euro ofzo) kan onveilig, voor meer moet je een veilige methode gebruiken. Je zou er dan zelfs voor kunnen kiezen om voor de fraude die via de onveilige methode wordt gepleegd een eigen risico in te stellen. Wil je dat als klant niet? Gebruik dan de veilige methode die wel 100% door de bank wordt gedekt.
Er is wat proof of concept research aan hypervisor en bios malware, die eventueel een 'cold' boot kan ondervangen.
Vanuit de malware community is er natuurlijk nu geen noodzaak om daar actief aan te werken.
Verder zou malware gewoon een secure OS kunnen faken (hoe moeilijk kan het zijn, als er een paar miljoen in het veld zitten), transactie prepareren, en daarna de gebruiker die laten authoriseren.
De huidige social engineering, zelfs per telefoon blijkt ruim voldoende succesvol.
Dat er een transactie bezig is gedaan te worden hoeft de gebruiker niet eens te zien of te weten, als de authenticatie maar geleverd wordt. Opgebeld worden door een 'loterij van uw bank, kunt u even uw calculator pakken dan kunt u winnen' ?
Banken hebben al apps die zonder calculator kleinere transacties naar bekende [eerder gebruikte] rekeningen overboeken.
Ik denk dat dat een goede ontwikkeling is feitelijk.
Routine en alertheid staan haaks op elkaar. Als bekende, kleine en 'in het patroon passende' transacties zonder speciale handelingen verlopen, kan de gebruiker geen "onnadenkende" routine opbouwen in het overtikken van "een paar getallen" om "gewoon even de bankzaken te doen".
Dan wordt een TAN sms (of token display) hopelijk wel goed gelezen en wordt er nagedacht bij authorisatie.
Uiteindelijk moet het doel zijn om fraude terug te dringen, niet om de schuld te kunnen afschuiven naar de ander.