Ist TOTP auf demselben Laptop wirklich ein zweiter Faktor?
Ein Codegenerator auf dem VPN-Laptop ist ein Besitzfaktor innerhalb derselben Kompromittierungsgrenze. Verfolgen Sie zuerst den Seed und die Sitzung.
Melden Sie sich bei einem VPN-Client an, der erst ein Passwort und dann einen sechsstelligen Code verlangt, und zwei Aufforderungen wirken wie zwei unabhängige Hürden. Nach Faktortyp gezählt sind sie das: Das Passwort ist etwas, das Sie wissen, der Code ist etwas, das Sie besitzen. Nach dem gezählt, was ein einzelner kompromittierter Laptop preisgibt, können sie zu einer Grenze zusammenfallen, denn das, was Sie besitzen, ist eine Datei auf der Maschine, in die Sie tippen. Die Lücke zwischen diesen beiden Zählungen ist das Thema dieses Durchgangs.
Verfolgen Sie eine Anmeldung vom Passwortfeld bis zum Codefeld
Beobachten Sie die Reihenfolge, nicht die Bezeichnungen. Der Client sendet das Passwort, der Server antwortet, dass ein zweiter Nachweis nötig ist, und der Client öffnet ein Feld für sechs oder acht Ziffern. Hinter diesem Feld sitzt eine Generatoranwendung mit einem geteilten Geheimnis und einer Uhr. Sie berechnet einen Wert aus dem Geheimnis und dem aktuellen Zeitschritt, und der Server berechnet denselben Wert aus seiner Kopie des Geheimnisses neu.
Beide Seiten halten dasselbe Schlüsselmaterial. Diese Symmetrie ist der Teil, den Menschen übersehen, wenn sie den Code als Geheimnis beschreiben: Der Anbieter kann Ihre Codes ebenfalls erzeugen, deshalb ist der Seed mehr wert als jede einzelne Ausgabe. Ein Code, der abfließt, ist ein Einmalwert; der Seed, der ihn erzeugte, ist ein dauerhaftes Zugangsmittel, das weiterhin gültige Werte erzeugt, bis es ausgetauscht wird.
Die Aktivierung ist die andere Hälfte des Ablaufs. Ein Generator, der sich mit einem Gerätecode, einer biometrischen Aufforderung oder einem verschlüsselten Container entsperrt, weist einen Besitznachweis plus etwas anderes vor. Einer, der unverschlüsselt läuft und sich mit der Betriebssystem-Sitzung entsperrt, weist nur die Datei vor. Dieselbe Anwendung kann beide Anordnungen bieten, je nachdem, wie die Registrierung erfolgt ist, also liegt die Bereitstellungsentscheidung in diesem Schritt und nicht auf der Marketingseite der App.
Entscheiden Sie, was der Code tatsächlich beweist
Die Sprache der Standards ist hier ungewöhnlich klar und verdient direktes Lesen. NISTs Leitfaden zu Authentifikatoren führt softwarebasierte OTP-Generatoren als Authentifikatoren auf, unterscheidet Ein-Faktor-OTP von Mehr-Faktor-OTP mit einem Aktivierungsfaktor und stellt fest, dass OTP-Authentifizierung nicht phishing-resistent ist. Jede dieser drei Aussagen ändert, was Sie über die Aufforderung behaupten können.
Nicht phishing-resistent zu sein ist die schärfste Kante. Ein Code, der in ein Feld getippt wird, kann in Echtzeit in das Feld einer anderen Person getippt werden, von jemandem, der dazu überredet wurde. Das Zeitfenster ist kurz, was die Zahl der brauchbaren Versuche verringert, die Technik aber nicht schließt. Wenn Ihre Anforderung den Widerstand dagegen einschließt, ist OTP der falsche Grundbaustein, egal wo der Generator läuft.
Ein-Faktor gegenüber Mehr-Faktor ist die zweite Unterscheidung. Ein Code, der ohne Aktivierungsschritt erscheint, beweist den Besitz einer Datei und sonst nichts, und die Datei ist nur so stark wie das Konto, das sie lesen kann. Fügen Sie einen Aktivierungsfaktor hinzu, und die Behauptung wird besser, obwohl sie noch immer den bei der Anmeldung vorgelegten Nachweis beschreibt und nicht die Isolation der Maschine, die ihn erzeugt.
Sehen Sie, was ein kompromittierter Laptop erreichen kann
Ein Angreifer mit Codeausführung auf der Arbeitsstation ist nicht darauf beschränkt, das Feld zu lesen, in das Sie tippen. Die nach einer erfolgreichen Anmeldung aufgebaute Sitzung ist meist ein Token oder ein Cookie, und ein Token lässt sich von einer anderen Maschine ganz ohne Code verwenden. Wenn das die Fähigkeit ist, gegen die Sie sich verteidigen, ändert eine zweite Aufforderung bei der Anmeldung die Zahl der Schritte im Angriff, nicht das Ergebnis.
| Arrangement | What it adds at login | What it leaves inside the laptop boundary |
|---|---|---|
| Password plus TOTP app on the same machine | A possession proof the password alone does not supply | The seed, the unlock step and the authenticated session |
| TOTP app on a separate phone | Seed storage outside the workstation | Session cookies, the typed password and any prompt that can be proxied |
| Hardware key with a signed challenge | A per-login signature bound to the origin | Whatever the browser and the workstation are already trusted to do |
Lesen Sie die dritte Spalte als die ehrliche. Jede Anordnung oben hinterlässt etwas innerhalb der Vertrauensgrenze der Arbeitsstation, denn dort wird die Sitzung genutzt. Was sich ändert, ist, ob das langlebige Geheimnis mit dieser Grenze reist oder außerhalb bleibt, und ob der Nachweis an einen bestimmten Ursprung gebunden ist, sodass eine nachgeahmte Seite ihn nicht weiterleiten kann.
Zwei kleinere Details gehören in dasselbe Bild. Ein Code bleibt für sein Annahmefenster gültig, oft dreißig Sekunden plus einer Toleranz für Uhrabweichung, sodass ein abgefangener Wert innerhalb dieses Fensters wiedergegeben werden kann, sofern der Prüfer die Wiederverwendung nicht verweigert. Und das Installieren eines neuen Generators beendet keine Sitzungen, die bereits authentifiziert wurden, sodass eine veraltete Sitzung den Wechsel der Anmeldeinformationen überlebt, der den Vorfall hätte eindämmen sollen.
Verschieben Sie den Generator nur dorthin, wo Trennung hilft
Den Codegenerator auf ein Telefon zu legen ist eine echte Verbesserung für einen bestimmten Fehler: Ein gestohlener Laptop trägt nicht mehr beide Nachweise. Es hilft nichts gegen eine Sitzungsübernahme auf dem Laptop, nichts gegen einen Nutzer, der einen Code in eine Phishing-Seite tippt, und nichts gegen die Wiederherstellungscodes, die einmal gedruckt und in einer Notizen-App fotografiert wurden.
Schreiben Sie die Anforderung also, bevor Sie das Werkzeug wählen. Ist das Ziel ein zusätzlicher Nachweis gegen ein durchgesickertes Passwort, sagen Sie das klar, und die App auf demselben Gerät liefert ihn bereits. Ist das Ziel Widerstandsfähigkeit gegen die Kompromittierung der VPN-Arbeitsstation, benennen Sie diese Angreiferfähigkeit und wählen Sie eine dafür bewertete Anordnung, wobei die Phishing-Anforderung getrennt genannt statt vorausgesetzt wird.
Dann behandeln Sie die betriebliche Hälfte, die entscheidet, ob irgendetwas davon den Kontakt mit einem Vorfall übersteht. Geräteverlust braucht einen dokumentierten Ersatzweg, der Wechsel von Anmeldeinformationen muss aktive Sitzungen widerrufen, und das Registrierungsmaterial braucht denselben Schutz wie der Seed, da eine ungeschützte Registrierungskopie einem Angreifer dieselben künftigen Codes auf einem kürzeren Weg liefert. Diese vier Punkte aufzuzählen ist nützlicher, als darüber zu streiten, ob Token auf demselben Gerät gut oder wertlos sind.