Zwei Passwortabfragen sind kein MFA: Was eine VPN-Anmeldung prüft

Die Anmeldeseite fordert ein Passwort an, dann ein zweites Geheimnis, und schon wird die Bereitstellung als multifaktoriell beschrieben. Manchmal stimmt das. Häufig ist es ein einzelner Faktor, zweimal erhoben, denn beide Werte sind Wissen, das dieselbe Person aus demselben Gedächtnis oder derselben Notiz eingetippt hat. Eine starke Tunnelverschlüsselung ändert daran nichts, und das Wort „sicher“ im Produktnamen ebenso wenig.

Die Behauptung vom Mechanismus zu trennen erfordert nur eine Frage: Was belegt jeder Schritt, und wem gegenüber?

Ein Faktor ist ein Beweis, kein Feld

Multifaktor-Authentifizierung bedeutet, dass mehr als eine unterschiedliche Art von Nachweis für dasselbe Konto geprüft wird: etwas, das der Nutzer weiß, etwas, das er besitzt, etwas, das er ist. Zwei Felder, die beide eine erinnerte Zeichenfolge abfragen, sind eine Art von Nachweis, zweimal verlangt. Das kann eine nützliche Kontrolle sein, da zwei unabhängige Geheimnisse schwerer zu erraten sind als eines, aber es ist nicht das, was der Begriff beschreibt, und sollte in einer Risikobewertung nicht als solches gezählt werden.

Die Prüfseite ist genauso wichtig wie die Erhebungsseite. Ein auf einem Gerät erzeugter Code belegt nur dann die Kontrolle über dieses Gerät, wenn der Server ihn gegen ein an dieses Konto gebundenes Geheimnis prüft und Wiederholungen zurückweist. Ein gemeinsamer Code, der für alle funktioniert, ein Code ohne Ratenbegrenzung oder eine auf einem Gerät bestätigte Abfrage, die nie anzeigt, was bestätigt wird, sind alle schwächer, als die Bezeichnung vermuten lässt.

Wenn also jemand fragt, ob das VPN MFA hat, fragen Sie, was der zweite Schritt belegt und wie der Server ihn bindet. Wenn die Antwort „ein zweites Passwort aus demselben Verzeichnis“ lautet, haben Sie einen Faktor und ein Richtliniengespräch, keinen zweiten Faktor.

Der Zertifikatsfall will gelesen, nicht angenommen werden

Ein Client-Zertifikat plus ein Passwort sieht nach zwei Faktoren aus, und das kann es sein: Das Zertifikat liegt in einem Speicher oder auf einem Token, und das Passwort wird erinnert. Es kann auch einer sein, wenn die Zertifikatsdatei ungeschützt im selben Profilverzeichnis wie das gespeicherte Passwort liegt oder wenn das Zertifikat für ein Gerät ausgestellt wurde, das mehrere Personen ohne individuelle Rechenschaft teilen.

Zu klären ist, wen oder was das Zertifikat identifiziert. Ein Gerätezertifikat belegt, dass ein verwalteter Rechner vorhanden ist. Ein Nutzerzertifikat belegt eine Identität. Wenn die Bereitstellung ein Zertifikat pro Laptop ausstellt und sein Vorhandensein dann als Beweis für die Person behandelt, ist der zweite Faktor stillschweigend zu einer Eigenschaft der Hardware geworden, die jeder erbt, der den Laptop in der Hand hat.

Nichts davon macht Zertifikate zu einer schlechten Idee. Es macht den Unterschied zwischen Geräteabsicherung und Nutzerabsicherung festhaltenswert, weil die beiden unterschiedliche Fragen beantworten und eine Compliance-Tabelle, die sie als eines zählt, überzeichnen wird, was geschützt ist.

Gateway-Vertrauen und Nutzervertrauen sind getrennte Probleme

Ein zweiter Faktor macht es nicht sicher, Anmeldedaten in einen Endpunkt einzutippen, den Sie nicht geprüft haben. Der Client muss das beabsichtigte Gateway erkennen, und dafür sind das Serverzertifikat und die Vertrauenskonfiguration des Clients da. Phishing funktioniert, indem es die Anmeldung auf einen Server verlagert, den der Angreifer kontrolliert, und ein dort eingegebenes korrektes Einmalpasswort wird einfach in Echtzeit an den echten Dienst weitergeleitet.

Darum ändert die Methodenwahl das Ergebnis stärker als die Formulierung der Abfrage. Von einer Person eingetippte Codes kann jeder weiterleiten, der eine überzeugende Seite zeigen kann, während kryptografische Verfahren, die die Authentifizierung an den konkreten Ursprung und die Sitzung binden, diese Weiterleitung konstruktionsbedingt abwehren. Welches von beidem vorliegt, ist eine Eigenschaft der Methode, nicht der Anzahl der Schritte im Dialog.

Folgen Sie dem unterstützten Registrierungs- und Client-Ablauf des Anbieters, statt eine zusätzliche Abfrage an ein Passwortfeld zu schrauben. Ein selbstgebauter zweiter Schritt landet meist irgendwo dazwischen und fügt Reibung hinzu, ohne die Bindung, die den Faktor aussagekräftig macht.

Die Wiederherstellung ist die zweite Vordertür

Jede starke Anmeldung hat einen Weg zurück, wenn der Authenticator verloren geht, und dieser Pfad ist meist die schwächste Stelle des Designs. Wenn ein Support-Mitarbeiter den zweiten Faktor nach einem Anruf bei einer hinterlegten Nummer zurücksetzen kann, ist die billigste Route des Angreifers der Helpdesk, nicht die Anmeldeseite.

Fragen Sie, wie der Ersatz funktioniert, wer ihn genehmigt und welche Nachweise verlangt werden. Prüfen Sie dann, dass Wiederherstellungsmaterial wie Backup-Codes getrennt vom primären Zugangsnachweis aufbewahrt wird, damit eine Kompromittierung nicht beide preisgibt. Die Leitlinie zur digitalen Identität von NIST behandelt die Verifier-Bindung und den Lebenszyklus von Authenticatoren als Teil der Anforderung und nicht als betrieblichen Nachtrag.

Was in die Bewertung gehört

Beschreiben Sie die Faktoren nach Art, benennen Sie, was jeder belegt, und geben Sie an, wie er an das Konto gebunden ist. Vermerken Sie, ob die Methode Weiterleitung abwehrt, und beschreiben Sie den Wiederherstellungspfad mit derselben Sorgfalt wie die Anmeldung.

Sagen Sie dann klar, ob die Bereitstellung nach dieser Definition multifaktoriell ist. „Zwei Passwörter und ein Maschinenzertifikat“ ist ein ehrlicher Satz, und er sagt einem Leser weit mehr als ein Kontrollkästchen, das Ja sagt.