Kritische Aktionen: warum manche Vorgänge erneut beide Geräte verlangen
Du bist angemeldet. Du hast eine Admin-Rolle. Du klickst auf „Mitglied entfernen“ — und SSP bittet dich, mit beiden Geräten zu signieren, genau so, als würdest du dich von Grund auf neu anmelden.
Das ist keine Reibung um ihrer selbst willen. Es ist eine bewusst gezogene Linie zwischen Vorgängen, die ein Session-Token autorisieren können sollte, und solchen, die es nicht können sollte — und die Überlegung hinter dieser Linie lohnt sich zu verstehen, ob du SSP nutzt oder nicht.
Sessions sind für Bequemlichkeit da, nicht für Konsequenzen
Ein Session-Token ist eine Inhaber-Berechtigung. Wer sie hält, ist du, soweit es den Server angeht. Genau das macht Sessions bequem — du authentifizierst dich einmal und handelst dann frei — und genau das macht sie zu einer schlechten Grundlage für unumkehrbare Entscheidungen.
Sessions werden gestohlen. Durch einen Cross-Site-Scripting-Fehler, einen unversperrten Laptop, Schadsoftware, ein geleaktes Backup oder schlicht einen offen gelassenen Browser im Großraumbüro. Die Leitlinie zum Session-Management von OWASP behandelt Session-Diebstahl als erwartbaren Zustand und nicht als Randfall, und jedes Design, das etwas anderes annimmt, ist optimistisch.
Für die meisten Aktionen ist das ein hinnehmbares Risiko, weil die meisten Aktionen umkehrbar sind. Einen Vault umbenennen, einen Viewer hinzufügen, eine Benachrichtigungseinstellung anpassen — tut ein Angreifer mit gestohlener Session das, machst du es rückgängig.
Manche Aktionen sind nicht so. Das Eigentum an einer Organisation zu übertragen gibt die Kontrolle an jemand anderen. Ein Mitglied zu entfernen schneidet dessen Zugang ab. Eine Organisation zu löschen ist endgültig. Für diese verlangt SSP den Nachweis, dass die handelnde Person jetzt gerade noch beide Geräte hat — nicht, dass sie sie irgendwann früher am Tag hatte.
Die dreizehn Aktionen
Dreizehn Vorgänge verlangen ein erneutes Signieren. Sie fallen in vier Gruppen.
Organisationskontrolle
- Eigentum übertragen
- Organisation löschen
Mitgliedschaft und Rollen
- Ein Mitglied entfernen
- Ein Mitglied zum Admin befördern
- Einen Admin herabstufen
Konto-Identität
- Die Unternehmens-E-Mail ändern
- Die Unternehmens-E-Mail entfernen
Vault-Lebenszyklus und -Verwaltung
- Einen Vault archivieren und wieder entarchivieren
- Einen Vault einfrieren und wieder freigeben
- Einen Vault-Admin befördern und herabstufen
Was sie eint, ist nicht, dass sie Geld bewegen — keine tut das, und keine kann es, weil nur Signierende Mittel bewegen können. Was sie eint, ist, dass sie ändern, wer danach etwas tun kann. Es sind die Vorgänge, die ein Angreifer möchte, um Zugang zu verfestigen, die echten Eigentümer auszusperren oder still einen späteren Diebstahl vorzubereiten.
Bemerkenswert: Die E-Mail-bezogenen Aktionen stehen auf der Liste. Die Unternehmens-E-Mail eines Kontos zu ändern sieht administrativ aus, ist aber der klassische Eröffnungszug einer Kontoübernahme: den Wiederherstellungskanal umleiten und dann in Ruhe arbeiten. Beide Geräte dafür zu verlangen schließt diesen Weg.
Warum der Server die Challenge schreibt
Der Mechanismus zählt so viel wie die Anforderung, und eine Entwurfsentscheidung leistet den größten Teil der Arbeit.
Der Server erzeugt die Nachricht, die du signierst. Der Client niemals.
Würde der Client seine eigene Challenge verfassen, könnte ein kompromittierter Client eine bequeme verfassen — eine Nachricht, die eine harmlose Aktion beschreibt, signiert von jemandem, der glaubte, etwas Harmloses zu tun, und dann gegen einen gefährlichen Endpunkt eingespielt. Dass der Server die Nachricht verfasst, bedeutet: Was du signierst, ist das, was ausgeführt wird, denn der Server prüft die Signatur gegen die Nachricht, die er ausgegeben hat, und gegen keine andere.
Es ist dasselbe Muster, das SSP beim Login nutzt, und dasselbe Muster, das signaturbasierte Authentifizierung generell sicher macht: signiere nie etwas, das du nicht von der Partei erhalten hast, die es prüfen wird.
Woran die Challenge gebunden ist
Die Nachricht ist kein allgemeines „Ja“. Sie ist eine konkrete Zeichenkette mit vier Bestandteilen, die zusammen eine abgefangene Signatur andernorts nutzlos machen.
Die genaue Aktion. remove_member und transfer_ownership erzeugen verschiedene Nachrichten. Eine Signatur für die eine kann die andere nicht autorisieren.
Das genaue Ziel. Die Organisation, gegebenenfalls der Vault und die betroffene Person werden in der Nachricht benannt. Vault-bezogene Aktionen enthalten ausdrücklich die Vault-ID, damit eine Signatur zum Einfrieren eines Vaults nicht zum Einfrieren eines anderen eingespielt werden kann.
Ein Zeitstempel. Er belegt die ersten dreizehn Zeichen der Nachricht — eine feste Position, weil SSP Wallet dieses Format prüft, bevor überhaupt etwas angezeigt wird. Challenges verfallen nach fünfzehn Minuten.
Ein zufälliger Nonce. Zwölf Byte kryptografischer Zufall, wodurch jede Challenge einzigartig ist, selbst bei identischer Aktion gegen identisches Ziel in derselben Sekunde.
Und die Challenge ist einmalig. Beim Einlösen markiert der Server sie in derselben atomaren Operation als verwendet, die sie validiert — eine eingespielte Signatur wird also mit „bereits verwendet“ abgewiesen statt still ein zweites Mal zu wirken. Abgelaufene Challenges räumt ein TTL-Index automatisch weg.
Jeder Versuch wird festgehalten, auch die gescheiterten
Kritische Aktionen werden in ein dauerhaftes Protokoll geschrieben, und hier steckt ein Detail, das man leicht überliest: der Protokolleintrag entsteht, wenn die Challenge angefordert wird, nicht erst, wenn die Aktion abgeschlossen ist.
Das heißt, das Protokoll umfasst abgebrochene Versuche, Versuche mit fehlgeschlagenem Signieren und abgewiesene Versuche. Eine einzelne gescheiterte kritische Aktion ist meist jemand, der es sich anders überlegt hat. Eine Häufung davon um 3 Uhr morgens ist eine Geschichte.
Wie der übrige Prüfpfad von SSP haben diese Einträge kein Ablaufdatum und keinen Aufräumjob. Der Wert eines Prüfprotokolls lebt vollständig in den Teilen, deren Bedarf niemand vorhergesehen hat.
Wie sich das in der Praxis anfühlt
Habe beide Geräte dabei, bevor du anfängst. Kritische Aktionen lassen sich mit einem Gerät nicht abschließen, und die Challenge verfällt in fünfzehn Minuten. Liegt dein Telefon im anderen Raum, hol es zuerst.
Lies die Aktion auf dem Telefon, nicht nur im Dashboard. Die Nachricht, die deine Geräte anzeigen, benennt Aktion und Ziel. Das ist deine Gelegenheit zu bemerken, dass das Ziel nicht das erwartete ist — dieselbe Gewohnheit, die dich beim Prüfen einer Transaktion schützt. Phishing-Angriffe auf Krypto-Nutzer erklärt, warum der zweite Blick auf das zweite Gerät die Sekunden wert ist.
Bündle sie nicht. Jede kritische Aktion bekommt ihre eigene Challenge und ihre eigene Signatur. Entfernst du drei ausscheidende Mitarbeitende, sind das drei Signiervorgänge. Das ist Absicht: Bündeln hieße, eine Signatur autorisiert mehrere Änderungen — genau die Eigenschaft, die wir vermeiden wollen.
Erwarte sie zu den ungünstigsten Zeitpunkten. Kritische Aktionen häufen sich genau dann, wenn jemand geht, ein Konto kompromittiert ist oder ein Vault eingefroren werden muss — also in Momenten, in denen Menschen unter Druck stehen und schnell handeln wollen. Vorher zu wissen, dass diese beide Geräte brauchen, macht aus einer Überraschung einen Arbeitsschritt.
Das größere Bild, was was durchsetzt — und warum erneutes Signieren in der mittleren und nicht in der stärksten Schicht sitzt —, steht in was eine Transaktion wirklich aufhält. Wie Organisation und Vaults zusammenpassen, beginnt bei SSP Enterprise: Multisig-Vaults für Teams.
