Token als kostengünstige und Phishing-sichere Lösung für Online-Geschäfte

Authentifizierung im E-Business

(04.12.05) - Die aktuelle Diskussion über die Folgen von Phishing-Angriffen und Schäden in Millionenhöhe ging durch alle Gazetten. Begriffe wie iTan, Digitale Signatur oder "Man in the Middle“ wurden dem Leser dadurch geläufig. Diverse Ansätze existieren seit längerem und reichen bis hin zur Nutzung eines zweiten Kommunikationskanals (z.B. Handy), die allerdings für Bank und Kunde teuer und gleichzeitig unhandlich sind.

Phishing ist auszuschließen, wenn sich Client (Kunde) und Server (Bank) eindeutig gegeneinander identifizieren und der so genannte "Man in the Middle" damit keine Chance hat. Mit dem "bi-Cube"-Token von iSM kann eine Bank für ihr Online-Geschäft eine Phishing-sichere Lösung bereitstellen. Das Prinzip des Token besteht in der zeitabhängigen Generierung eines Zufallspasswortes, das zusammen mit anderen Informationen Server-seitig wieder entschlüsselt und in den einzelnen Komponenten geprüft wird. Das Token wird lokal, auf dem PC des Kunden mittels des Software-Token-Generators erzeugt.

Das Verfahren zeichnet sich durch zwei Sicherheitsstufen aus. In der ersten Sicherheitsstufe wird durch eine duale Authentifikation die Identität des Bankkunden gesichert: Zunächst meldet sich der Nutzer mit seiner ID (Username) und Passwort an. Nach positiver Überprüfung wird dann das Token innerhalb eines vordefinierten Zeitraumes (z.B. 10 sec.) abgefragt und zusätzlich am ID-Server bei der Bank geprüft.

Mit dem Fadenkreuz kann das bi-Cube-Token in ein Feld einer Web-Seite übertragen werden. Das u.a. individuell erzeugte Token ist nur für 1 min (konfigurierbar) gültig.

In der zweiten Sicherheitsstufe werden durch einen Hash-Code die Überweisungs-relevanten Daten in das Token implementiert. Auch wenn der Phisher diesen Token erlangt, kann er ihn nicht mehr nutzen, sobald er diese Daten ändert (z.B. Kontonummer des Empfängers). Selbst wenn er in der Lage wäre, den Hash-Code seiner veränderten Daten zu bilden, kann er diesen nicht in das bi-Cube-Token einfügen. Prinzipiell würde sich bei diesem Verfahren auch die TAN einsparen lassen, da der Hash-Code diese Funktion noch besser übernehmen kann. (iSM: ra)