Zum Inhalt springen
Alle Insights KI gegen Betrug & Finanzkriminalität

Verhaltensbiometrie für kontinuierliche Authentifizierung

Ein Passwort beweist, wer sich angemeldet hat – nicht, wer gerade tippt. So nutzen wir Verhaltensbiometrie für eine kontinuierliche, datenschutzbewusste Authentifizierung.

4 Min. Lesezeit #Betrug#Authentifizierung#Session-Sicherheit
Fachleute aus dem Finanzsektor bei der Arbeit an einer KI-Initiative

Ein Passwort beweist, wer sich angemeldet hat. Es sagt nichts darüber aus, wer zehn Minuten später an der Tastatur sitzt – wenn das Session-Cookie gestohlen wurde oder ein Remote-Access-Tool die Bildschirmkontrolle übernommen hat. Verhaltensbiometrie schließt diese Lücke, indem sie kontinuierlich bewertet, wie eine Person tippt und sich durch einen Flow bewegt. So reagiert das System, wenn der Bediener mitten in der Session wechselt – und nicht erst an der Tür.

Warum das wichtig ist, ergibt sich aus dem Muster moderner Account-Übernahmen. Die Zugangsdaten sind längst nicht mehr das schwächste Glied; der Angreifer hat sie meist bereits. Was er nicht ohne Weiteres reproduzieren kann, ist die Muskelerinnerung des echten Nutzers: der Rhythmus zwischen den Tastenanschlägen und die Reihenfolge, in der jemand durch ein Formular tabbt, das er zwanzigmal am Tag ausfüllt. Diese Signale lassen sich schwer phishen und schwer in einem Forum kaufen, und sie bleiben über die gesamte Session hinweg bestehen – nicht nur in der ersten Sekunde.

Was die Signale tatsächlich sind

Der Rohstoff sind Timing und Bewegung, abgetastet aus Events, die der Browser oder die App ohnehin auslöst. Nichts davon ist der Inhalt dessen, was der Nutzer tippt.

  • Keystroke Dynamics: Dwell Time (wie lange eine Taste gehalten wird) und Flight Time (die Lücke zwischen dem Loslassen einer Taste und dem Drücken der nächsten). Digraph- und Trigraph-Latenzen für häufige Buchstabenpaare sind pro Person stabil und verschieben sich, wenn jemand anderes übernimmt.
  • Zeiger- und Touch-Verhalten: Geschwindigkeits- und Beschleunigungskurven, Click-to-Target-Overshoot, Scroll-Kadenz und – auf Mobilgeräten – Anpressdruck und Wischgeometrie.
  • Interaktionsstruktur: Navigationsreihenfolge durch einen bekannten Flow, Zögern vor Feldern mit hohem Wert, Copy-Paste-Muster und das Tempo einer wiederkehrenden Aufgabe, die ein echter Bediener in seinen Händen automatisiert hat.
  • Gerät und Kontext, getrennt gehalten: grobe Plattform, Zeitzone, Netzwerk. Das sind unterstützende Features, nicht das Kernsignal – und wir halten ihre Herkunft sauber getrennt, damit ein reiner Gerätewechsel sich nicht als Verhaltensänderung tarnt.

Ein Punkt, den man klar aussprechen sollte: Der Inhalt wird nicht benötigt und sollte nicht erfasst werden. Sie erfassen, dass ein Tastenereignis stattgefunden hat und wann – nicht, welches Zeichen es war. So bleibt das Feature-Set unter Artikel 9 der DSGVO verteidigbar, und der Audit-Trail bleibt sauber, wenn eine Aufsichtsbehörde fragt, was Sie gespeichert haben.

Aus Signalen eine Live-Entscheidung machen

Das Modell ist ein Verifikationsproblem pro Nutzer, kein Populationsklassifikator. Während des Enrolments bauen Sie aus den echten Sessions einer Person ein Profil auf und bewerten dann zur Inferenzzeit, wie weit die aktuelle Session von diesem Profil entfernt liegt. Ein über ein Zeitfenster steigender Anomalie-Score ist das Signal – nicht ein einzelner seltsamer Tastenanschlag.

Die technischen Fallstricke sind hier dieselben, die jedes Verhaltensmodell im Stillen ruinieren:

  • Leakage und Point-in-Time-Korrektheit. Enrolment-Sessions müssen zum Trainingszeitpunkt als bestätigt-echt gelten – nicht später umetikettiert werden, weil sich das Konto als betrügerisch herausstellte. Sickert eine Übernahme-Session in das Enrolment-Set, lernt das Profil den Angreifer. Versionieren Sie das Profil und führen Sie die Lineage über jede Session, die in es eingeflossen ist.
  • Cold Start. Neue Nutzer haben kein Profil, also bewerten frühe Sessions gegen eine Populationsbasislinie und bleiben in einem Zustand geringeren Vertrauens. Machen Sie explizit, dass das False-Positive-Budget in dieser Phase ein anderes ist, denn Reibung bei einem echten Neukunden ist teuer.
  • Drift. Das Tippen von Menschen ändert sich mit einer neuen Tastatur, einer Verletzung, dem Wechsel vom Desktop zum Laptop. Das Profil muss sich anpassen, ohne sich an einen Angreifer anzupassen – das bedeutet schrittweise Updates, die an andere Vertrauenssignale gekoppelt sind, und ein Hold-out-Evaluierungsset, das die Ablehnung echter Nutzer über die Zeit verfolgt.
  • Konzeptgrenzen zwischen Nutzern, die sich ein Gerät teilen. Familienkonten, gemeinsam genutzte Arbeitsplätze in einer Filiale, delegierter Zugriff. Die Entity Resolution muss entscheiden, ob zwei Verhaltens-Fingerabdrücke zwei Personen sind oder eine Person an zwei Rechnern.

Latenz ist eine reale Einschränkung. Ein kontinuierlicher Score, der dreißig Sekunden nach der betrügerischen Überweisung eintrifft, ist ein forensisches Protokoll, keine Kontrolle. Der Scoring-Pfad läuft auf dem Event-Stream der Session und erzeugt alle paar Interaktionen einen aktualisierten Score – genau das erlaubt es der Entscheidungsschicht, einzugreifen, bevor Straight-Through-Processing eine Zahlung freigibt.

Entscheiden, was bei einem sinkenden Score zu tun ist

Ein Score ist keine Aktion. Der Wert liegt in der Eskalationsleiter, die Sie daran knüpfen – abgestimmt auf ein False-Positive-Budget, dem das Geschäft tatsächlich zugestimmt hat.

  • Geringe Anomalie: nichts tun, den Score für den Audit-Trail und die spätere Auswertung protokollieren.
  • Steigende Anomalie bei einer geringwertigen Aktion: Überwachung erhöhen, die Session in einem Zustand halten, in dem hochwertige Aktionen eine Re-Verifikation erfordern.
  • Hohe Anomalie bei einer hochwertigen Aktion: Step-up. Erneut nach einem Faktor fragen, die Transaktion verzögern oder in die Prüfung leiten, statt sie rundweg zu blockieren – denn eine falsche Blockade zum Quartalsende bei einem echten Treasury-Nutzer ist ihr eigener Vorfall.
  • Anhaltend hohe Anomalie mit bestätigenden Signalen: Session beenden und Re-Authentifizierung erzwingen.

Bestätigung ist die Disziplin, die verhindert, dass das Ganze zum Störgeräusch-Generator wird. Eine Verhaltensanomalie allein ist ein schwacher Beleg. Dieselbe Anomalie zusammen mit einem neuen Gerät, einem Impossible-Travel-Sprung oder einem Minuten zuvor hinzugefügten Begünstigten ist eine andere Geschichte, und die Fusionslogik sollte explizit machen, welche Kombinationen eskalieren. Halten Sie die Reason Codes lesbar: Wird eine Session hochgestuft oder beendet, sollte der Datensatz festhalten, welche Features sich bewegt haben und um wie viel – denn der Kunde wird anrufen, der Analyst wird ermitteln, und irgendwann wird jemand aus der Compliance Sie bitten, die Entscheidung zu erklären.

Die ehrliche Grenze der Technik ist, dass sie probabilistisch ist und sich verschlechtert. Profile veralten, Angreifer, die sich Zeit nehmen und beobachten, können das Tempo nachahmen, und Remote-Access-Betrug, bei dem der echte Nutzer zum Tippen angeleitet wird, erzeugt echte Verhaltenssignale, die an eine betrügerische Absicht geknüpft sind. Verhaltensbiometrie verengt das Zeitfenster, in dem ein Angreifer operiert, und macht die stille Übernahme teuer. Sie schließt das Fenster nicht – und jede Implementierung, die als Schließung verkauft wird, wird beim ersten angeleiteten Überweisungsfall mit einem sauberen Verhaltens-Score scheitern.

Häufige Fragen

Unterliegen verhaltensbiometrische Daten als biometrische Daten der DSGVO?

Tipp- und Zeigerdynamik, die zur eindeutigen Identifizierung einer Person verwendet wird, fällt unter die Verarbeitung besonderer Kategorien nach Artikel 9. Sie brauchen also eine Rechtsgrundlage und in der Regel eine DSFA. Wenn Sie abgeleitete Timing-Features und Vergleichsscores statt der Roh-Tastenanschläge speichern, verringert das die Exposition – die Einstufung verschwindet dadurch aber nicht.

Wie viele Daten braucht das Modell, bevor es eine Session bewerten kann?

Genug Enrolment, um ein stabiles Profil pro Nutzer aufzubauen – typischerweise eine Handvoll echter Sessions. Bis dahin wird die Session gegen eine Populationsbasislinie bewertet, und Sie halten das Konto in einem Zustand geringeren Vertrauens, der eher auf Step-up als auf stille Entscheidungen setzt.

Ersetzt das die Multi-Faktor-Authentifizierung?

Nein. Es sitzt hinter dem Login als zweite, dauerhaft aktive Schicht, die die Session überwacht, nachdem die MFA bereits bestanden wurde – also genau in dem Zeitfenster, in dem ein Cookie-Diebstahl oder ein Remote-Access-Angriff lebt.

Arbeiten Sie an etwas Ähnlichem?

Erzählen Sie uns von Ihren Daten und dem Workflow drumherum, und Sie bekommen eine ehrliche Einschätzung.

30-minütiges Erstgespräch buchen