Heißer Flamewar und Hot Takes in den Kommentaren

@masek ach, das gibt es auch noch? Lol.

@ljrk es ist ja am Ende egal warum es kaputt ist, es ist kaputt. Und schon die Option, dass es da es Wahlmöglichkeiten gibt und unterschiedliche Sorten Keys macht es kaputt. Was habe ich denn nun und welche Sorte Key ist die beste für mich?

Das sind fragen die sich niemals stellen dürfen, bei mir und beim Implementierer.

@isotopp Da stimmte ich dir zu, dass es (aktuell) kaputt ist. Nur Kuketz' Aspekte zum Warum waren halt... einfach nicht richtig, irreführend und am Ende schädigend. Wenn man schreibt – wie du – aktuell kann ich das für meine Eltern nicht einsetzen weil ... und nicht auch nach das Risiko von Phishing nebenbei unter den Tisch kehrt, dann stimme ich da voll zu.

Ah, und das wählst nicht du aus, sondern die Website. Also die bestimmt discoverable oder nicht. Und das ist eigentlich sinnvoll, um halt eine API für Soft-Tokens im Wallet zu haben als auch für Hard-Tokens als 2. Faktor, wie von mir beschrieben. Aber wie gesagt, alle Vendors machen ihren eigenen Shit. Und ja, mMn sollten Browser eine Warnung ausgeben, wenn man versucht discoverable Credentials auf FIDO2-Sticks zu packen, aus dem von dir angesprochenen Gründen.

Da ist unglaublich viel kaputt. Aber so wie Kuketz das formuliert ist das kein "wartet ab, nervt ggf Vendors" sondern ein "unnötige Technologie, am Besten nie nutzen". Und so sieht das auch seine Anhängerschaft incl. mehreren Leuten die ernsthaft meinen, Anti-Phishing brauchen sie ja nicht.

Und das ist der Schaden den er anrichtet. Dass Passkeys aktuell nicht breit nutzbar sind – wie gesagt, volle Zustimmung.

@isotopp Da stimmte ich dir zu, dass es (aktuell) kaputt ist. Nur Kuketz' Aspekte zum Warum waren halt... einfach nicht richtig, irreführend und am Ende schädigend. Wenn man schreibt – wie du – aktuell kann ich das für meine Eltern nicht einsetzen weil ... und nicht auch nach das Risiko von Phishing nebenbei unter den Tisch kehrt, dann stimme ich da voll zu.

Ah, und das wählst nicht du aus, sondern die Website. Also die bestimmt discoverable oder nicht. Und das ist eigentlich sinnvoll, um halt eine API für Soft-Tokens im Wallet zu haben als auch für Hard-Tokens als 2. Faktor, wie von mir beschrieben. Aber wie gesagt, alle Vendors machen ihren eigenen Shit. Und ja, mMn sollten Browser eine Warnung ausgeben, wenn man versucht discoverable Credentials auf FIDO2-Sticks zu packen, aus dem von dir angesprochenen Gründen.

Da ist unglaublich viel kaputt. Aber so wie Kuketz das formuliert ist das kein "wartet ab, nervt ggf Vendors" sondern ein "unnötige Technologie, am Besten nie nutzen". Und so sieht das auch seine Anhängerschaft incl. mehreren Leuten die ernsthaft meinen, Anti-Phishing brauchen sie ja nicht.

Und das ist der Schaden den er anrichtet. Dass Passkeys aktuell nicht breit nutzbar sind – wie gesagt, volle Zustimmung.

@mina @isotopp Ja, das haben wir den großen Gatekeepern zu verdanken, die massiv Druck gemacht haben den guten Standard L2 soweit zu verwässern, dass die das als Plattfom-Feature einbauen können.

Und ich vermute mal, dass das (bei technisch nicht so versierten Menschen) ziehen wird. Also ich rede von den Menschen, die eben kein Passwortmanager nutzen.

Dafür wird der Fuckup dann natürlich um so größer, wenn dritte an deren Apple/Google/Microsoft Account und die Keys da raus syncen können

Das Hauptproblem ist in der Tat das Management, und da gibt es halt keine Erzählung. Bevor es die nicht gibt, gibt es keine Passkeys:

Angenommen, ich habe unseligerweise für Passkeys auf so einem Fido-Stick entschieden. Dann brauche ich offensichtlich ein Backup, und ich brauche eine Methode, den Stick zusammen mit dem Browser am Telefon zu verwenden.

Was ist die Story hier? Werden gleich zwei Passkeys angelegt und brauche ich also zum Account machen beide Sticks am Gerät? Kann der Stick mit meinem Telefon kommunizieren? Wie? NFC?

(Bei ssh habe ich ja einen Key für alle Sites, bei denen ich mich anmelde, da kann ich mir vorstellen, einen Key auf Hardware zu haben und ein Backup zu haben. Bei Passkeys habe ich offenbar einen Passkey pro Site, brauche das Backup also laufend an der Person. Das ist offensichtlich eine komplette Quatschidee und nicht realisierbar – diese Tatsache alleine macht "Passkey auf Hardware-Token" systematisch komplett kaputt).

Der Stick geht verloren oder wird zerstört und das Backup geht nicht. Wie liste ich die Accounts auf, für die ich Recovery machen muß? Ist der Recovery Flow bei jedem Anbieter anders oder einheitlich, oder gibt es gar eine zentrale Stelle, die das für mich macht.

Angenommen, ich war schlau und habe mich für "Keys werden in Software realisiert". Wie mache ich hier ein Backup der Keys, und wichtiger, ein Restore auf einem zweiten Gerät ohne Zugriff auf das erste haben zu müssen?

In Apple zum Beispiel, sind Passkeys in Time Machine bzw in der Account Migration auf ein neues Telefon, oder ist das eine der vielen Sachen, die ein Restore aus der iCloud nicht restauriert und ich bin mit einem Telefon gefickt? Wie kann ich mir vorher sicher sein, daß das funktioniert, ohne es auszuprobieren und dann im Arsch zu sein?

Wie liste ich alle Passkeys auf, die mein System kennt?

Angenommen, ich verwende Passkeys und habe die mit Safari eingerichtet und jetzt verwende ich Firefox, oder Brave. Kann ich mich noch einloggen und will ich das ausprobieren und riskieren, daß ich durch eine Recovery laufen muß?

Bei 2FA mit TOTP kann ich die Secrets archivieren (die QR-Codes als Screenshots managen) und kann so restaurieren ohne mich mit unterschiedlichen Recovery Flows unterschiedlicher Implementierungen auseinander setzen zu müssen. Wie mache ich das mit Passkeys?

Das sind alles Stories, die erzählt werden müssen, damit Passkeys vertrauenswürdig und MANAGEBAR werden.

Das ist kein technisches Problem, und kein Sicherheitsproblem, das ist ein Problem von Vertrauen, Managebarkeit und Ergonomie.

Stattdessen lese ich hier und beim Kuketz, daß

• Passkeys für manche Leute in 1/3 der Fälle schlicht nicht funkionieren
• Paypal auch bei Passkey noch 2FA mit OTP machen will (WTF?)

und ähnliche Stories.

Nein, da gehe ich mit der Kneifzange nicht ran, also nicht einmal um den Management-Flow auszuprobieren.

Das ist alles unreife und unterstandardisierte Tech. Da müssen statt Security-Leuten dringend ein paar UX Designer und Tester ran, und es braucht eine Standardisierung der Flows auf der Anbieter- und Clientseite, damit das akzeptabel wird.

Ich bin am Ende der Arsch, der das Menschen mit Geburtsjahr 1942 erklären muß und die umstellen muß, und die Zusammenfassung der Migrationsanleitung ist basically "Nein."

@isotopp also for the record: Ich rante regelmäßig und oft über den Stand von Passkeys und bin da total bei dir. Aber das Warum ist ja trotzdem wichtig um keine Totalablehnung zu generieren oder gar Widerstand. Wir haben hier die Möglichkeit endlich gute Auth zu bauen...

@ljrk

Ah, und das wählst nicht du aus, sondern die Website. Also die bestimmt discoverable oder nicht.

eine Website hat mir nicht vorzuschreiben wie ich meine Keys mache, verwalte oder speichere. Websites sind nie vertrauenswürdig. Keine

@isotopp Wie archiviert man am besten die QR codes? (Ich drucke sie derzeit zweimal aus, einmal für zuhause, einmal off-site). Bessere Vorschläge jemand?

@ljrk nope. That ship has sailed.

Das Hauptproblem ist in der Tat das Management, und da gibt es halt keine Erzählung. Bevor es die nicht gibt, gibt es keine Passkeys:

Angenommen, ich habe unseligerweise für Passkeys auf so einem Fido-Stick entschieden. Dann brauche ich offensichtlich ein Backup, und ich brauche eine Methode, den Stick zusammen mit dem Browser am Telefon zu verwenden.

Was ist die Story hier? Werden gleich zwei Passkeys angelegt und brauche ich also zum Account machen beide Sticks am Gerät? Kann der Stick mit meinem Telefon kommunizieren? Wie? NFC?

(Bei ssh habe ich ja einen Key für alle Sites, bei denen ich mich anmelde, da kann ich mir vorstellen, einen Key auf Hardware zu haben und ein Backup zu haben. Bei Passkeys habe ich offenbar einen Passkey pro Site, brauche das Backup also laufend an der Person. Das ist offensichtlich eine komplette Quatschidee und nicht realisierbar – diese Tatsache alleine macht "Passkey auf Hardware-Token" systematisch komplett kaputt).

Der Stick geht verloren oder wird zerstört und das Backup geht nicht. Wie liste ich die Accounts auf, für die ich Recovery machen muß? Ist der Recovery Flow bei jedem Anbieter anders oder einheitlich, oder gibt es gar eine zentrale Stelle, die das für mich macht.

Angenommen, ich war schlau und habe mich für "Keys werden in Software realisiert". Wie mache ich hier ein Backup der Keys, und wichtiger, ein Restore auf einem zweiten Gerät ohne Zugriff auf das erste haben zu müssen?

In Apple zum Beispiel, sind Passkeys in Time Machine bzw in der Account Migration auf ein neues Telefon, oder ist das eine der vielen Sachen, die ein Restore aus der iCloud nicht restauriert und ich bin mit einem Telefon gefickt? Wie kann ich mir vorher sicher sein, daß das funktioniert, ohne es auszuprobieren und dann im Arsch zu sein?

Wie liste ich alle Passkeys auf, die mein System kennt?

Angenommen, ich verwende Passkeys und habe die mit Safari eingerichtet und jetzt verwende ich Firefox, oder Brave. Kann ich mich noch einloggen und will ich das ausprobieren und riskieren, daß ich durch eine Recovery laufen muß?

Bei 2FA mit TOTP kann ich die Secrets archivieren (die QR-Codes als Screenshots managen) und kann so restaurieren ohne mich mit unterschiedlichen Recovery Flows unterschiedlicher Implementierungen auseinander setzen zu müssen. Wie mache ich das mit Passkeys?

Das sind alles Stories, die erzählt werden müssen, damit Passkeys vertrauenswürdig und MANAGEBAR werden.

Das ist kein technisches Problem, und kein Sicherheitsproblem, das ist ein Problem von Vertrauen, Managebarkeit und Ergonomie.

Stattdessen lese ich hier und beim Kuketz, daß

• Passkeys für manche Leute in 1/3 der Fälle schlicht nicht funkionieren
• Paypal auch bei Passkey noch 2FA mit OTP machen will (WTF?)

und ähnliche Stories.

Nein, da gehe ich mit der Kneifzange nicht ran, also nicht einmal um den Management-Flow auszuprobieren.

Das ist alles unreife und unterstandardisierte Tech. Da müssen statt Security-Leuten dringend ein paar UX Designer und Tester ran, und es braucht eine Standardisierung der Flows auf der Anbieter- und Clientseite, damit das akzeptabel wird.

Ich bin am Ende der Arsch, der das Menschen mit Geburtsjahr 1942 erklären muß und die umstellen muß, und die Zusammenfassung der Migrationsanleitung ist basically "Nein."

@isotopp Ich glaube da verrennen wir uns gerade und das ist nicht einfach per Text zu erklären. Ich sehe deinen Punkt, aber das ist anders gedacht:

In einer idealen Welt bietet die Website discoverable WebAuthn als primäres Verfahren an und schreibt das vor – du darfst den trotzdem auf einem Hardware-Token schreiben, das ist gar nicht die Debatte, aber hat halt die von dir genannten Nachteile. Du solltest aber zusätzlich einen nicht-discoverable als 2. Faktor enrollen können. Also ja, die Website soll das kontrollieren, aber du bedienst die Website und steuerst, ob du einen 2. Faktor-Token haben möchtest.

In einem UX-Mockup wäre das auch genau so deklariert, dass das erste eben die Credential in der Wallet wäre, das 2. die Credential auf dem Stick.

Natürlich kann man auch eine Website bauen, wo man das als User komplett frei einstellen kann – aber dann hat man ein ganz großes UX Problem. Ich weiß nicht welchen Pfad aus deiner Sicht dann der richtige wäre:

1. User die Wahl geben ist überfordernd (stimme ich dir zu)
2. Hardware-Tokens per se auszuschließen (und damit die Wahlmöglichkeit) wäre ein Rückschritt

Aber dann muss die Wahl irgendwo geschehen... und die ist eben folgende: Möchte man einen Login-1F haben? Discoverbale. Einen 2F per Stick? Undiscoverable.

@ljrk https://infosec.exchange/@masek/116039484798840800

@isotopp Passkeys von Paypal kann man z.B. nicht in Bitwarden speichern.

EDIT: Anscheinend, siehe Screenshot in den Replies, lässt Paypal das jetzt zu. Das war vorher eine explizite Einstellung, dass sich der Passkey nur in Hardware speicher liess.

@isotopp @hikhvar Nee, das ist ja das coole. Man kann sowohl QR-Codes für einzelne Codes ausgeben, als auch eine Google-Authentication-Kompatible Riesen-QR-Serie, als quasi-Standardformat für optischen OTP-Secret-Transfer.

@masek @isotopp Kann man nicht?

Das Hauptproblem ist in der Tat das Management, und da gibt es halt keine Erzählung. Bevor es die nicht gibt, gibt es keine Passkeys:

Angenommen, ich habe unseligerweise für Passkeys auf so einem Fido-Stick entschieden. Dann brauche ich offensichtlich ein Backup, und ich brauche eine Methode, den Stick zusammen mit dem Browser am Telefon zu verwenden.

Was ist die Story hier? Werden gleich zwei Passkeys angelegt und brauche ich also zum Account machen beide Sticks am Gerät? Kann der Stick mit meinem Telefon kommunizieren? Wie? NFC?

(Bei ssh habe ich ja einen Key für alle Sites, bei denen ich mich anmelde, da kann ich mir vorstellen, einen Key auf Hardware zu haben und ein Backup zu haben. Bei Passkeys habe ich offenbar einen Passkey pro Site, brauche das Backup also laufend an der Person. Das ist offensichtlich eine komplette Quatschidee und nicht realisierbar – diese Tatsache alleine macht "Passkey auf Hardware-Token" systematisch komplett kaputt).

Der Stick geht verloren oder wird zerstört und das Backup geht nicht. Wie liste ich die Accounts auf, für die ich Recovery machen muß? Ist der Recovery Flow bei jedem Anbieter anders oder einheitlich, oder gibt es gar eine zentrale Stelle, die das für mich macht.

Angenommen, ich war schlau und habe mich für "Keys werden in Software realisiert". Wie mache ich hier ein Backup der Keys, und wichtiger, ein Restore auf einem zweiten Gerät ohne Zugriff auf das erste haben zu müssen?

In Apple zum Beispiel, sind Passkeys in Time Machine bzw in der Account Migration auf ein neues Telefon, oder ist das eine der vielen Sachen, die ein Restore aus der iCloud nicht restauriert und ich bin mit einem Telefon gefickt? Wie kann ich mir vorher sicher sein, daß das funktioniert, ohne es auszuprobieren und dann im Arsch zu sein?

Wie liste ich alle Passkeys auf, die mein System kennt?

Angenommen, ich verwende Passkeys und habe die mit Safari eingerichtet und jetzt verwende ich Firefox, oder Brave. Kann ich mich noch einloggen und will ich das ausprobieren und riskieren, daß ich durch eine Recovery laufen muß?

Bei 2FA mit TOTP kann ich die Secrets archivieren (die QR-Codes als Screenshots managen) und kann so restaurieren ohne mich mit unterschiedlichen Recovery Flows unterschiedlicher Implementierungen auseinander setzen zu müssen. Wie mache ich das mit Passkeys?

Das sind alles Stories, die erzählt werden müssen, damit Passkeys vertrauenswürdig und MANAGEBAR werden.

Das ist kein technisches Problem, und kein Sicherheitsproblem, das ist ein Problem von Vertrauen, Managebarkeit und Ergonomie.

Stattdessen lese ich hier und beim Kuketz, daß

• Passkeys für manche Leute in 1/3 der Fälle schlicht nicht funkionieren
• Paypal auch bei Passkey noch 2FA mit OTP machen will (WTF?)

und ähnliche Stories.

Nein, da gehe ich mit der Kneifzange nicht ran, also nicht einmal um den Management-Flow auszuprobieren.

Das ist alles unreife und unterstandardisierte Tech. Da müssen statt Security-Leuten dringend ein paar UX Designer und Tester ran, und es braucht eine Standardisierung der Flows auf der Anbieter- und Clientseite, damit das akzeptabel wird.

Ich bin am Ende der Arsch, der das Menschen mit Geburtsjahr 1942 erklären muß und die umstellen muß, und die Zusammenfassung der Migrationsanleitung ist basically "Nein."

Das Hauptproblem ist in der Tat das Management, und da gibt es halt keine Erzählung. Bevor es die nicht gibt, gibt es keine Passkeys:

Angenommen, ich habe unseligerweise für Passkeys auf so einem Fido-Stick entschieden. Dann brauche ich offensichtlich ein Backup, und ich brauche eine Methode, den Stick zusammen mit dem Browser am Telefon zu verwenden.

Was ist die Story hier? Werden gleich zwei Passkeys angelegt und brauche ich also zum Account machen beide Sticks am Gerät? Kann der Stick mit meinem Telefon kommunizieren? Wie? NFC?

(Bei ssh habe ich ja einen Key für alle Sites, bei denen ich mich anmelde, da kann ich mir vorstellen, einen Key auf Hardware zu haben und ein Backup zu haben. Bei Passkeys habe ich offenbar einen Passkey pro Site, brauche das Backup also laufend an der Person. Das ist offensichtlich eine komplette Quatschidee und nicht realisierbar – diese Tatsache alleine macht "Passkey auf Hardware-Token" systematisch komplett kaputt).

Der Stick geht verloren oder wird zerstört und das Backup geht nicht. Wie liste ich die Accounts auf, für die ich Recovery machen muß? Ist der Recovery Flow bei jedem Anbieter anders oder einheitlich, oder gibt es gar eine zentrale Stelle, die das für mich macht.

Angenommen, ich war schlau und habe mich für "Keys werden in Software realisiert". Wie mache ich hier ein Backup der Keys, und wichtiger, ein Restore auf einem zweiten Gerät ohne Zugriff auf das erste haben zu müssen?

In Apple zum Beispiel, sind Passkeys in Time Machine bzw in der Account Migration auf ein neues Telefon, oder ist das eine der vielen Sachen, die ein Restore aus der iCloud nicht restauriert und ich bin mit einem Telefon gefickt? Wie kann ich mir vorher sicher sein, daß das funktioniert, ohne es auszuprobieren und dann im Arsch zu sein?

Wie liste ich alle Passkeys auf, die mein System kennt?

Angenommen, ich verwende Passkeys und habe die mit Safari eingerichtet und jetzt verwende ich Firefox, oder Brave. Kann ich mich noch einloggen und will ich das ausprobieren und riskieren, daß ich durch eine Recovery laufen muß?

Bei 2FA mit TOTP kann ich die Secrets archivieren (die QR-Codes als Screenshots managen) und kann so restaurieren ohne mich mit unterschiedlichen Recovery Flows unterschiedlicher Implementierungen auseinander setzen zu müssen. Wie mache ich das mit Passkeys?

Das sind alles Stories, die erzählt werden müssen, damit Passkeys vertrauenswürdig und MANAGEBAR werden.

Das ist kein technisches Problem, und kein Sicherheitsproblem, das ist ein Problem von Vertrauen, Managebarkeit und Ergonomie.

Stattdessen lese ich hier und beim Kuketz, daß

• Passkeys für manche Leute in 1/3 der Fälle schlicht nicht funkionieren
• Paypal auch bei Passkey noch 2FA mit OTP machen will (WTF?)

und ähnliche Stories.

Nein, da gehe ich mit der Kneifzange nicht ran, also nicht einmal um den Management-Flow auszuprobieren.

Das ist alles unreife und unterstandardisierte Tech. Da müssen statt Security-Leuten dringend ein paar UX Designer und Tester ran, und es braucht eine Standardisierung der Flows auf der Anbieter- und Clientseite, damit das akzeptabel wird.

Ich bin am Ende der Arsch, der das Menschen mit Geburtsjahr 1942 erklären muß und die umstellen muß, und die Zusammenfassung der Migrationsanleitung ist basically "Nein."

@isotopp Passkeys im OS oder Browser nutze ich tatsächlich nicht aus genau den genannten Gründen. Mit Passwortmanager, der Passkeys spricht (KeePassXC) halte ich das Problem aber für annehmbar gelöst. Und bzgl. Hardwarekeys habe ich grundsätzlich immer zwei oder drei. Hier mache ich also kein Backup vom Key, sondern füge einfach immer mehrere Keys zu meinem Account hinzu, das geht ja zum Glück (außer bei Paypal WTF).

@isotopp Da stimmte ich dir zu, dass es (aktuell) kaputt ist. Nur Kuketz' Aspekte zum Warum waren halt... einfach nicht richtig, irreführend und am Ende schädigend. Wenn man schreibt – wie du – aktuell kann ich das für meine Eltern nicht einsetzen weil ... und nicht auch nach das Risiko von Phishing nebenbei unter den Tisch kehrt, dann stimme ich da voll zu.

Ah, und das wählst nicht du aus, sondern die Website. Also die bestimmt discoverable oder nicht. Und das ist eigentlich sinnvoll, um halt eine API für Soft-Tokens im Wallet zu haben als auch für Hard-Tokens als 2. Faktor, wie von mir beschrieben. Aber wie gesagt, alle Vendors machen ihren eigenen Shit. Und ja, mMn sollten Browser eine Warnung ausgeben, wenn man versucht discoverable Credentials auf FIDO2-Sticks zu packen, aus dem von dir angesprochenen Gründen.

Da ist unglaublich viel kaputt. Aber so wie Kuketz das formuliert ist das kein "wartet ab, nervt ggf Vendors" sondern ein "unnötige Technologie, am Besten nie nutzen". Und so sieht das auch seine Anhängerschaft incl. mehreren Leuten die ernsthaft meinen, Anti-Phishing brauchen sie ja nicht.

Und das ist der Schaden den er anrichtet. Dass Passkeys aktuell nicht breit nutzbar sind – wie gesagt, volle Zustimmung.