Passwordless Authentication-Methoden sind in aller Munde und generell ein sehr guter Ansatz, der auch nicht wirklich so neu ist. Mit einer Key-basierten Anmeldung bei SSH oder einer Zertifikats-basierten Anmeldung (Public-Key-basierten Verfahren) gibt es solche Verfahren schon sehr lange. Warum ist das nun so en vogue? Weil Kennwörter zu einfach sind, gehackt werden können und weil wir Passwörter nicht irgendwo ablegen sollten – also vor allem nicht in Clouds, in denen wir keine Kontrolle über die Security haben. Blindes Vertrauen gleicht hier dem Glauben an das Gute und das ist hier fehl am Platze. Paranoia, Schizophrenie passen hier besser – also der ganz normale IT-Wahnsinn.

Dazu ein kleiner Ausflug zum Thema Credential Theft. Wenn man auf seiner bevorzugten, Bäume pflanzenden Suchmaschine (sorry Schleichwerbung) die richtigen Suchworte eingibt, dann wird man mit Möglichkeiten überhäuft. Gerade aktuell “HiveNightmare” oder “How to get passwords with mimikatz?”.

Eine Variante:

i) Man erstelle ein Dump von dem lsass-Prozess via Task Manager

variante1

ii) Man nehme dieses File und analysiere es mit mimikatz

Quelle: https://go.beyondtrust.com/talks/day-3-cyber-challenge/, Screenshot vom 1.7.2021

Voilà! Im gesamten Output sieht man dann die Credentials aller Accounts. Click.

iii) Lesson learned for Administrators:

    • Bitte bei RDP Session oder sonst Admin Sessions abmelden!
    • Besonders sensitive Admin-Credentials nicht auf Systemen verwenden, die auch von anderen Admins verwendet werden (Domain Admins nur auf DCs).
    • Besser: Smart Card verwenden.

Warum zählen wir OTP / MFA nicht wirklich dazu?

Ein OneTimePassword (OTP) ist vom Namen her schon mal nicht in der Kategorie Passwordless. Spass bei Seite. Eine statische Passphrase oder auch PIN + Token Code ergeben klassischerweise den Passcode, wenn wir an so einen guten alten Hardware Token denken, die es auch heute noch gibt. Bei den Software-basierten Token, z.B. auf dem Phone, wird das gern zusammengeführt. Eingabe der Passphrase auf der App und das ergibt dann den Passcode. Leider sind mir die populären Apps von Microsoft und Google mit TOPT etwas zu einfach gestrickt. Denn hier gibt es immer eine Authentisierung mit UserID und Passwort und dann den Token Code. Also eher eine 2-Step-Authentication und nicht wirklich 2FA. Aber es gibt ja professionellere Lösungen, z.B. Thales: www.avantec.ch/loesungen/thales/

Beim PushOTP läuft die Kommunikation teilweise über Apple oder Google und das ist dann auch genau abzuwägen. Aber die eigentliche Bestätigung erfolgt auch hier vom IdP (Identity Provider) zum Gateway.

Letztendlich basiert ein Token Code oder auch der Passcode auf einem symmetrischen kryptografischen Verfahren und es wurde ein Seed, ein statischer Share Secret, zwischen Client und zentralen Authentication Server vereinbart.


Passwordless – Public Key (Certificate / Key-based Authentication)

Bei einem passwordless Authentication wird zwischen dem Client und dem Server kein Shared Secret oder irgendein Hash abgelegt, salted oder nicht, sondern der Public Key des Schlüsselpaars. Der Schutz bzw. die Bestätigung der Private Key Operation kann dabei sehr wohl mit einem PIN oder einer alphanumerischen Passphrase erfolgen, denn diese wird nicht mit dem Authentication Server oder IdP geteilt, sondern der Private Key verbleibt immer beim Anwender.

Hier haben wir nun die schöne Seite der asymmetrischen Kryptografie. Einfach gesagt, unsere Identität mit unserem Private-Key-basierten Verfahren bestätigen und damit erhalten wir auch non-repudiation. Das basiert dann letztendlich auf Digital Signing. Siehe www.tec-bite.ch/smart-cards-what-happens-in-the-background/

Wenn es «nur» eine Key-based Authentication wie bei SSH, FIDO oder so ist, dann fehlt halt die Validierung der Gültigkeit des Zertifikats, aber die Verifizierung der Identität ist immer noch stark, wenn der Schutz des Private Keys gut ist.

Deshalb ist es eine gute Idee, den FIDO Key auf eine separates Device zu legen oder die Kombination mit einer echten Smart Card wie der IDPrime 3940 FIDO zu nutzen. Da kann man flexibel reagieren.


FIDO – Fast Identity Online

Wer FIDO noch nicht kennt, kann hier alles nachlesen: https://en.wikipedia.org/wiki/FIDO_Alliance. Seit 2015 also FIDO2, die Token sind FIDO U2F zertifiziert und das gesamte Framework ist dann FIDO UAF zertifiziert.

Das ist letztlich ein Public Key-based Verfahren, aber eben ohne Zertifikate. Es basiert am Ende des Tages auf Basis der Kryptografie der elliptischen Kurven und damit auf dem mathematischen Problem des diskreten Logarithmus (DLP).

Die Geräte werden via Key Attestation (spezielles Zertifikat auf den Devices) geprüft, sodass nur zertifizierte FIDO Devices FIDO machen. Das kann also nicht irgendein Gerät sein und erfüllt damit definierte Voraussetzung und gewährt die notwendige Sicherheit des privaten Schlüssels.

Bei der Registrierung wird nun das Gerät geprüft, ein Key Pair erzeugt und der Public Key beim Service Provider hinterlegt. Bei der späteren Authentisierung muss hier der Zugriff auf den Private Key via Fingerprint, Face Recognition, PIN, … bestätigt werden und die eigentlich Authentisierung folgt dann den Regeln der definierten Protokolle WebAuthn / CTAP. Es ist aber am Ende Digital Signing (ECDSA). Siehe auch: https://fidoalliance.org/how-fido-works/

  • Bei Windows Hello for Business greifen ein paar Komponenten ineinander, die eine besonders gute Usability bringen sollen. Abgesehen von der Komplexität der Infrastruktur für das Deployment mit den notwendigen ActiveDirectory Anpassungen, eigener MS CA, ADFS, MFA, … darf man sich zwischen Certificate und Key-based Verfahren entscheiden. Da kommt für mich nur Certificate based in Frage.
  • Das Certificate (oder der Private Key) kommt beim Enrolment auf den TPM (der User hat sich dafür beim IdP ADFS mit dem OTP/MFA stark authentisiert), damit gibt es aber keine Trennung von Authentication Device und Access Device, was nicht so schön ist.
  • Das Approval der Private Key Operation «Digital Signing» für die Authentication, kann dann mit verschiedenen Optionen bestätigt werden.
windowseinstellungen
Quelle: Windows Einstellungen – Account Settings, Screenshot vom 27.7.2021

Bei einer klassischen Smart Card ziehe ich meinen Schlüssel aus der Tür und habe sie in der Hand. Bei Angriffen auf den Rechner ist das auch ein deutlicher Unterschied zu einem TPM, denn auch da gibt es Challenges (CVE-2017-15361).


SAML Ansatz

Der Vorteil ist hier, dass wir auf unserem IdP definieren können, wer sich wie authentisiert. Im SAML Assertion sind keine Credentials enthalten und wenn ich diese SAML-Token für die Authentisierung am Service Provider verwende, dann ist das passwordless. Das Token selbst ist digital mit einem Zertifikat signiert und damit vertrauenswürdig und nicht veränderbar. Und nun sind wir auf der IdP Seite gefragt, dort die richtige Authentisierung für uns zu wählen. Beim ADFS ist Certificate based Athentication seit jeher dabei – es ist ja Windows. Bei anderen muss man das vielleicht genauer prüfen, aber heutzutage meist üblich.

Im Zweifel kann man die Authentisierung auch mit einer Smart Card realisieren, obwohl die Ziel-Lösung das nicht bietet, aber eben SAML als Option unterstützt. Netter Nebeneffekt ist das allseits beliebte SSO. Weitere Infos zur SAML Authentication gibts in diesem Blog-Beitrag: www.tec-bite.ch/saml-authentication-praktische-anwendung-und-etwas-theoretischer-hintergrund/


HYPR

Ist ein Anbieter, der nun einige Dinge kombiniert, um FIDO für den Einsatz in Unternehmen zu optimieren. Dafür verwenden sie einen eigenen Authentication Service in der Cloud, auf dem man sich per Mobile Device oder anderen FIDO Authenticators anmelden kann. Die passwortlose Multi-Faktor-Anmeldung startet bereits mit dem Rechner (Windows, Mac) und ist dann eine andere zertifikatsbasierte Authentisierung und basiert wirklich auf einem internen Zertifikat und wird über das Smartphone gesteuert werden. Die Einbindung dieser passwortlosen Authentisierung kann über seperate IdPs oder für gewünschten Ressourcen (Webservices) via SAML direkt erfolgen. Damit hat ein Unternehmen die Benutzer via IdP unter Kontrolle und kann sie dort löschen, wenn sie das Unternehmen verlassen. Das heisst, das Phone wird zur Fernsteuerung der Desktop-Anmeldung und auch der -Abmeldung.

Im Vergleich zu Windows Hello for Business sind hier Access und Authentication Device getrennt, auch ein Recovery Prozess ist sinnvoll umgesetzt und es ist dann schon cool, alles mit dem Smartphone zu steuern. Das Gerät muss man heute wohl nicht extra Verteilen und lässt sich auch managen im Gegensatz zu allen anderen separaten Geräten. Aber man verlässt sich auf die Sicherheit von Apple und Google bzw. den Hersteller der Geräte. Leider ist dies aus der Vergangenheit auch mit ein paar Fragezeichen behaftet.

Es gibt natürlich weitere Kandidaten, aber die Lösung haben wir mal genauer beleuchtet und deshalb kann ich hier auch wirklich etwas dazu schreiben.

www.hypr.com


Fazit

Passwordless Authentication heisst Public/Private Key-basierte also asymmetrische kryptografische Verfahren verwenden. Damit ist die Ablage des öffentlichen Schlüssels auch beim Cloud Anbieter kein Problem mehr, auch wenn dieser die Informationen im Klartext speichert, denn den Public Key dürfen wir ja «über den Marktplatz rufen» oder am Bahnhof aushängen.

Die asymmetrischen Verfahren sind genau für die unverschlüsselte Kommunikation geschaffen worden und damit ist der Weg auch safe.

Der Key Logger könnte nun die PIN/Passphrase für die Initiierung der Private Key Operation mitlesen, aber den Private Key vom TPM oder der Smart Card exportieren ist dann ein ganz anderes Level – Hardware basierte Security. Selbst Private Key Operationen auslösen, darf das System bei einer Smart Card nicht. Jeder Prozess muss für den Zugriff vom User separat bestätigt werden. Das ist auch beim TPM so umsetzbar.


Was sind die Hürden?

  • Gewohnheit
    • Das ging doch auch bisher gut so.
  • Aufwand
    • Komplexere Infrastruktur, zusätzliche Devices, … werden wir so lange vermeiden, bis der wirkliche Need da ist.
  • Verständnis
    • Wie nun eine gute salted Passwort-Speicherung funktioniert und die Verifizierung eines Passworts auf Basis eines Hashes mit Abhängigkeit der Zeit ist schon ein Thema für sich.
    • Beim munteren Austausch der Restklassenelemente einer endlichen Menge zwischen Alice und Bob muss man halt etwas mitrechnen, das schreckt schon mal ab.
    • Oder das Problem der Primfaktorenzerlegung.
    • Oder gar die Schönheit einer elliptischen Kurve (mathematisch) erschliesst sich nicht jedem User und damit auch nicht die Vorteile, auch wenn das am Ende wieder quasi das diskrete Logarithmus Problem ist.
  • Regularien
    • So lange es keine klaren Regeln/Vorgaben gibt, werden wir Menschen das Notwendige umsetzten, es sei denn, wir sehen in den anderen Varianten Vorteile und wir sind dann doch mal einsichtig.

Um sich nun ein Bild davon zu machen, versuche ich das mal so auf zwei Dimensionen herunterzubrechen. Aufwand, Kosten und andere Aspekte bleiben dabei auf der Strecke. Und jede schöne vereinfachte Darstellung ist natürlich hervorragend streitbar.

darstellung

Bitte nicht vergessen, nur mit asymmetrischen Algorithmen bekommen wir Non-Repudiation – Nicht-Abstreitbarkeit. Also eine wirkliche gute Identifikation des Clients.

Ich höre bei OTP-Lösungen oft das Argument, das ist doch besser als UserID und Passwort. Das kommt schon gut. Nun ja, besser JA aber auch good enough? Das hängt von der Risikobewertung und den eigenen Ansprüchen ab. Passwordless ist der nächste Schritt und vor allem im Kontext aller Clouds, die so in den Himmel steigen, sinnvoll oder sogar notwendig.

Gerade bei OTP mit einem definierten Seed, der ja auch schon mal ausgenutzt wurde – und das bei RSA – ergeben sich Risiken. Muss eine Firma nach dem Cloud Act diese Seeds rausrücken?
Auch auf der App-Seite gerade auf den Mobile Devices wurde der Passcode schon per Malware (via Screenshot) «weitergeben» – siehe hier: www.zdnet.com/article/android-malware-can-steal-google-authenticator-2fa-codes/.

OTP ist halt symmetrisch …

So lange die Quanten-Computer noch nicht so verfügbar sind, brauchen wir vor Peter Shor’s Algorithmus keine Angst haben. 1994 hat Peter W. Shor gezeigt, wie man mit Quantencomputern das Faktorisierungsproblem für RSA und das diskrete Logarithmusproblem für Diffie-Hellmann Verfahren oder auch ECC lösen kann. Das Problem besteht nicht nur für verschlüsselte Daten, die heute aufgezeichnet werden, um sie dann eventuell entschlüsseln zu können, oder digital signierte Dokumente, die man dann manipulieren kann. Dies betrifft dann auch die Public Keys, die wir heute bei verschiedenen Anbietern hinterlegen. Bei Zertifikaten können wir diese wenigstens durch die Revocation für ungültig erklären. Deshalb gehen wir heute in Richtung von RSA 4096 Bit Key Length und verwenden gute elliptische Kurven. Es gibt Prognosen, die zeigen, dass es ab 2025 so weit sein kann. Dann werden wir uns den Post Quantum Algorithmen wohl stellen müssen und alle Verfahren und Schlüssel ersetzen müssen.

Lasst uns also eine schöne feine Phobie gegen die Ablage von Informationen – vor allem Credentials – an Orten aufbauen, die wir nicht selbst kontrollieren.


mephisto

mephisto ist Security-Spezialist und langjähriger Mitarbeiter bei AVANTEC. Am liebsten beschäftigt er sich mit Authentication, Encryption und echtem Schutz gegen Malware. mephisto streitet sich gern, um die Lösungen richtig zu verstehen, denn: "Ich bin ein Teil von jener Kraft, die stets das Böse will und stets das Gute schafft."

Privacy Preference Center