Sichere Online-Zahlungen aus Admin-Sicht: Zwei-Faktor-Login, Tokenisierung und was PayPal technisch anders macht

Einsteiger Praxis Veröffentlicht am 6. Oktober 2026 von Gunter Herdrich
Illustration: Bankkarte, die über einen Pfeil zu einem Token wird, daneben ein Browserfenster mit Schloss und ein Hardware-Sicherheitsschlüssel

Wenn du Server verwaltest, siehst du Online-Zahlungen anders als die meisten Leute. Du siehst nicht den Knopf „Jetzt bezahlen“, sondern die Verbindung, die er aufbaut, die Daten, die er sendet, und die Stellen, an denen diese Daten gestohlen werden könnten: im Browser, auf dem Weg, beim Händler, beim Zahlungsdienst. Jede dieser Stellen hat in den letzten zwanzig Jahren ihre eigene Sicherheitstechnik bekommen, und es lohnt sich, sie zu verstehen, auch wenn du nur dein eigenes Geld schützen willst.

Dieser Beitrag geht die Kette einmal durch, vom Login bis zur Abbuchung, und erklärt, was Wallets wie PayPal technisch anders machen als eine direkt eingegebene Kreditkarte. Am Ende steht eine kurze Anleitung, wie du deine eigene Zahlungsumgebung unter Linux absicherst. Die Werkzeuge dafür kennst du aus der Übersicht der wichtigsten Linux-Befehle.

Stelle 1: Der Login und der zweite Faktor

Ein Passwort ist ein Geheimnis, das du kennst, und jedes Geheimnis, das du kennst, kann abgephisht werden. Der zweite Faktor ist etwas, das du hast: ein Gerät, das Codes erzeugt, oder ein Hardware-Schlüssel, der kryptografisch antwortet. Der Unterschied zwischen beiden ist für Admins interessant. Codes per SMS oder App lassen sich in Echtzeit abphishen, wenn der Angreifer eine gefälschte Seite betreibt, die den Code sofort weiterreicht. Ein FIDO2-Schlüssel antwortet nur auf die echte Domain und ist gegen diese Art Angriff immun. Für Konten, über die Geld fließt, ist ein phishing-resistenter Faktor die richtige Wahl. Viele große Zahlungsdienste bieten dafür inzwischen Passkeys an, die nach demselben FIDO-Prinzip arbeiten. Der Chaos Computer Club rät auf ccc.de seit Jahren von SMS als zweitem Faktor ab. Ein Grund ist das SIM-Swapping, bei dem Angreifer die Rufnummer auf eine eigene Karte übertragen lassen.

Stelle 2: Tokenisierung, oder warum der Händler deine Karte nie sieht

Beim klassischen Kartenkauf tippst du 16 Ziffern, Ablaufdatum und Prüfnummer in ein Formular des Händlers. Der Händler muss diese Daten verarbeiten, weiterleiten und darf sie unter strengen Auflagen speichern. Jeder Händler ist damit eine Angriffsfläche, und die großen Datenlecks der letzten Jahre waren fast immer Händlerdatenbanken mit Kartendaten. Die Tokenisierung löst das Problem an der Wurzel: Der Zahlungsdienst ersetzt die Kartennummer durch ein Token, eine Zufallszeichenfolge, die nur für diesen Händler oder dieses Gerät gültig ist. Wird das Token gestohlen, ist es anderswo wertlos. Wallets gehen noch einen Schritt weiter, weil der Händler nicht einmal das Token sieht, sondern nur eine Zahlungsbestätigung vom Dienst. Dazu kommt, dass Wallets ihre Händler aussuchen. Die Berliner Morgenpost beschreibt das in einem Vergleich zum Thema Online Casino PayPal: In Deutschland arbeitet PayPal dort nur mit Anbietern zusammen, die eine Lizenz der Gemeinsamen Glücksspielbehörde der Länder haben. Für die Sicherheit zählt am Ende vor allem eines: Ein Anbieter, der nur eine Zahlungsbestätigung bekommt, kann keine Kartendaten verlieren, die er nie hatte.

Stelle 3: Der Weg, oder was TLS kann und was nicht

Die Verbindung zwischen deinem Browser und dem Zahlungsdienst ist per TLS verschlüsselt, und das Schloss in der Adressleiste zeigt dir, dass sie es ist. Was das Schloss nicht zeigt, ist, mit wem du verschlüsselt sprichst. Eine Phishing-Seite hat ebenfalls ein gültiges Zertifikat, weil Zertifikate heute kostenlos und automatisch ausgestellt werden. TLS schützt also den Weg, nicht das Ziel. Das Ziel prüfst du über die Domain, und genau deshalb sind Hardware-Schlüssel so wirksam: Sie prüfen die Domain für dich, bevor sie antworten.

Was Wallets technisch vom Händler fernhalten

  • Kartendaten: Der Händler bekommt eine Bestätigung, keine Nummer. Ein Datenleck beim Händler enthält keine Zahlungsdaten.
  • Login-Daten: Die Anmeldung findet beim Zahlungsdienst statt, nicht beim Händler. Der Händler sieht kein Passwort und keinen Faktor.
  • Zahlungsvereinbarungen für Abos liegen beim Dienst und lassen sich dort zentral beenden, ohne dass der Händler zustimmen muss.
  • Freigabe: Auf dem Smartphone bestätigt die Biometrie jede Zahlung. Eine gestohlene Sitzung allein löst nichts aus.
  • Prüfung des Händlers: Der Dienst identifiziert den Händler, bevor er ihn zulässt. Das ersetzt keinen eigenen Blick auf den Shop, ist aber eine zusätzliche Hürde.

Deine eigene Zahlungsumgebung unter Linux

Für Zahlungen und Banking lohnt sich ein eigenes Browserprofil ohne Erweiterungen, denn Erweiterungen lesen jede Seite mit, auch das Zahlungsformular. Lege mit firefox -P ein Profil „Banking“ an, installiere dort nichts, und nutze es nur dafür. Halte das System aktuell, denn die meisten Angriffe nutzen bekannte Lücken, nicht neue. Nutze einen Passwortmanager, der Zugangsdaten nur auf der richtigen Domain ausfüllt, was Phishing-Seiten automatisch entlarvt. Und prüfe mit ss -tulpn gelegentlich, welche Dienste auf deinem Rechner lauschen, denn ein Fernwartungsdienst, den du vergessen hast, ist eine offene Tür. Dass bösartige Erweiterungen kein theoretisches Risiko sind, zeigen die Funde manipulierter Add-ons in den offiziellen Stores, über die Fachportale wie Security-Insider berichten.

Was du als Admin für andere tun kannst

Wenn du Rechner für Familie oder Verein betreust, richte den zweiten Faktor für alle Konten mit Geldbezug ein, bevorzugt mit Hardware-Schlüssel und einem Ersatzschlüssel im Safe. Erkläre, dass das Schloss in der Adressleiste nichts über die Echtheit der Seite sagt. Und empfiehl für unbekannte Händler die Wallet, nicht wegen des Komforts, sondern weil sie die Kartendaten dort behält, wo sie hingehören.

Fazit: Sicherheit liegt bei dem, der die Daten nicht hat

Zweiter Faktor gegen den gestohlenen Login, Token gegen das Datenleck beim Händler, Domainprüfung gegen das falsche Ziel, und ein sauberes Profil gegen die mitlesende Erweiterung: Das ist die Kette, die eine Online-Zahlung absichert. Das Prinzip dahinter ist das, das du von jedem Server kennst. Daten, die nicht gespeichert werden, können nicht gestohlen werden.