Passkey – Mehr Sicherheit für einen unklaren Preis

szegedi.info unterstützt Passkeys.

Technisch gibt es daran wenig auszusetzen. Passkeys ermöglichen eine sehr starke Form der Authentifizierung, ohne dass der Benutzer der Plattform dafür ein Geheimnis anvertrauen muss.

Der private Schlüssel bleibt auf der Seite des Benutzers. szegedi.info erhält lediglich den öffentlichen Schlüssel und kann damit später überprüfen, dass sich tatsächlich jemand mit dem zugehörigen privaten Schlüssel authentifiziert.

Eigentlich eine bemerkenswert schöne Konstruktion:

Um sich gegenüber szegedi.info zu authentifizieren, muss ein Benutzer nicht einmal szegedi.info seinen Schlüssel anvertrauen.

Genau deshalb wollte ich Passkeys auf dieser Plattform anbieten.

Bei der Umsetzung bin ich allerdings auf einen Preis gestoßen, der mit dieser technischen Eigenschaft erstaunlich wenig zu tun hat.

Wo ist der private Schlüssel?

Irgendwo muss er natürlich sein.

Auf einem Smartphone. Auf einem Computer. Auf einem Security Key. Vielleicht auf mehreren Geräten.

Die Passkey-Spezifikation schreibt nicht vor, dass dafür eine zentrale Infrastruktur notwendig ist. Sie ermöglicht unterschiedliche Arten von Authenticators und unterschiedliche Modelle für den Umgang mit den dabei entstehenden Schlüsseln.

In der Praxis sieht die Welt für normale Benutzer anders aus.

Wer heute auf einem gewöhnlichen Computer oder Smartphone einen Passkey anlegt, wird sehr schnell in die Credential-Infrastruktur seines Betriebssystems oder Browsers geführt.

Apple bietet seine Infrastruktur an. Google seine. Microsoft seine. Daneben gibt es Passwort- und Credential-Manager anderer Anbieter.

Das funktioniert komfortabel und meistens ausgesprochen gut.

Aber damit ist etwas passiert, das die Passkey-Spezifikation selbst nicht verlangt:

Aus einer Authentifizierung, die keine zusätzliche Vertrauensbeziehung benötigt, ist eine Authentifizierung geworden, bei der der Benutzer in der Praxis häufig einen weiteren Anbieter benötigt, dem er die Verwaltung seines Schlüssels anvertraut.

Der Benutzer hat das nicht entschieden

Man könnte nun fordern, Benutzer müssten eben besser darüber informiert werden.

Das greift zu kurz.

Ein normaler Benutzer sollte sich nicht mit der Frage beschäftigen müssen, welche Teile einer Passkey-Spezifikation sein Browser wie implementiert, welche Art von Credential gerade erzeugt wird und wer dessen privaten Schlüssel anschließend verwaltet.

Er sollte auch keine Expertenentscheidung darüber treffen müssen, ob er einen synchronisierten oder gerätegebundenen Passkey benötigt.

Das eigentlich Bemerkenswerte ist vielmehr, dass diese Entscheidung überhaupt notwendig geworden ist.

Ein naheliegender Standardfall könnte sehr einfach sein:

Ein Benutzer möchte sich gegenüber szegedi.info authentifizieren. Sein Gerät erzeugt dafür einen Schlüssel. Der private Schlüssel bleibt unter seiner Kontrolle auf seinem Gerät.

Fertig.

Keine weitere Partei muss beteiligt sein.

Keine zusätzliche Vertrauensbeziehung muss entstehen.

Und vor allem muss der Benutzer nichts darüber wissen.

Genau diese Einfachheit ist erstaunlich schwer anzubieten

Gerätegebundene Schlüssel sind technisch keineswegs exotisch. Entsprechende Authentifizierungsmodelle existieren und werden insbesondere in professionellen und Enterprise-Umgebungen eingesetzt.

Aber eine gewöhnliche Website kann ihren gewöhnlichen Benutzern nicht einfach eine entsprechend selbstverständliche Erfahrung anbieten.

szegedi.info kann die standardisierten Web-Schnittstellen verwenden und die notwendigen Optionen angeben.

Was daraus für den Benutzer wird, bestimmen anschließend wesentlich Browser, Betriebssystem und die dort verfügbaren Credential-Provider.

Und hier entsteht eine eigentümliche Situation.

Die Unternehmen, deren Produkte diese Entscheidungen treffen, sind gleichzeitig diejenigen Unternehmen, deren Infrastruktur als Lösung angeboten wird.

Apple entwickelt nicht nur ein Betriebssystem und einen Browser, über die Passkeys verwendet werden. Apple bietet auch die Infrastruktur an, in der diese Credentials verwaltet und synchronisiert werden können.

Bei Google und Microsoft finden sich vergleichbare Konstellationen.

Das allein beweist keine Absicht.

Aber es schafft eine Struktur, die man zumindest wahrnehmen sollte.

Wo endet szegedi.info?

Für den Benutzer ist diese Grenze kaum sichtbar.

Er befindet sich auf szegedi.info und klickt beispielsweise auf „Passkey hinzufügen“.

Dann übernimmt der Browser.

Das Betriebssystem erscheint.

Ein Credential-Provider wird angeboten.

Vielleicht wird ein Smartphone eingebunden, vielleicht eine Cloud-Synchronisation, vielleicht ein anderer Mechanismus.

Ein technisch versierter Mensch kann ungefähr erkennen, welche Komponente gerade welche Entscheidung trifft.

Die meisten Benutzer müssen das nicht können.

Und genau deshalb ist es problematisch.

Denn aus ihrer Perspektive geschieht all das weiterhin bei szegedi.info.

Tatsächlich hat szegedi.info an einem bestimmten Punkt die Kontrolle über den Vorgang weitgehend abgegeben.

Nicht freiwillig.

Sondern weil das Web genau an dieser Stelle auf Browser und Betriebssystem angewiesen ist.

Mehr Sicherheit gegen weniger Autonomie?

Auch diese Beschreibung wäre falsch.

Denn es gibt keinen notwendigen Tausch.

Die Passkey-Spezifikation verlangt die zusätzliche Vertrauensbeziehung nicht.

Die zusätzliche Abhängigkeit ist auch nicht der Preis, den wir kryptographisch für die höhere Sicherheit bezahlen müssen.

Sie entsteht erst durch die konkrete Umsetzung der Spezifikation in den Produkten, die zwischen einer Website und ihrem Benutzer stehen.

Und genau diese Produkte stammen überwiegend von einigen der größten Plattformanbieter der Welt.

Das macht den Preis so schwer erkennbar.

Die zusätzliche Abhängigkeit erscheint nicht als zusätzliche Abhängigkeit.

Sie erscheint als Komfort.

Als Synchronisation.

Als Recovery.

Als Sicherheit.

Für jedes dieser Dinge gibt es gute Argumente.

Nur beantwortet keines davon die Frage, warum aus einer technischen Möglichkeit eine Architektur werden musste, in der zusätzliche zentrale Vertrauensbeziehungen für normale Benutzer praktisch zum Standard werden.

Warum unterstützt szegedi.info Passkeys trotzdem?

Weil die Technik gut ist.

Passkeys ermöglichen eine Form der Authentifizierung, bei der szegedi.info keinen privaten Schlüssel kennen muss und auch keinen kennen sollte.

Diese Möglichkeit möchte ich den Benutzern dieser Plattform anbieten.

Aber ich kann ihnen derzeit nicht gleichzeitig garantieren, dass daraus keine weitere Vertrauensbeziehung entsteht.

Und noch etwas kann ich nicht:

Ich kann die Grenze für sie nicht vollständig sichtbar machen.

Der Dialog, der nach einem Klick auf „Passkey hinzufügen“ erscheint, gehört möglicherweise nicht mehr zu szegedi.info. Seine Gestaltung, seine Empfehlungen und teilweise auch die dadurch entstehenden Abhängigkeiten liegen außerhalb der Kontrolle dieser Plattform.

Deshalb steht dieser Text hier.

Nicht als Warnung vor Passkeys.

Sondern als Hinweis darauf, dass selbst ein offener technischer Standard in der Realität nicht allein durch seine Spezifikation bestimmt wird.

Zwischen einem offenen Standard und einem Menschen stehen Produkte.

Und die Hersteller dieser Produkte können damit erheblichen Einfluss darauf nehmen, wie offen sich ein offener Standard am Ende tatsächlich anfühlt.

Passkeys machen die Anmeldung auf szegedi.info sicherer.

Das ist der Grund, warum es sie hier gibt.

Der zusätzliche Preis ist nicht notwendig.

Aber derzeit kann ich verhindern, dass Sie ihn bezahlen, ebenso wenig wie ich zuverlässig erkennen kann, wie hoch er für Sie einmal sein wird.

Deshalb nenne ich ihn:

unklar.