Passwordless Authentication or normal IT Madness

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.

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.

• Im Falle der Biometrie habe ich meine üblichen Bauchschmerzen. Siehe auch hier:
  https://t3n.de/news/windows-hello-gesichtserkennung-hacker-webcam-1392407/
• Recovery ist dann gleich Re-Enrolment. Im Falle des Wechsels des Rechners muss man also die Credentials neu erstellen.

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).

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/

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.

• 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.

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.