Heißer Flamewar und Hot Takes in den Kommentaren
-
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 Amen! Passkeys sind im Moment extrem unausgereift. Ich möchte sie weder privat noch im Unternehmenskontext sehen.
-
@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ückschrittAber dann muss die Wahl irgendwo geschehen... und die ist eben folgende: Möchte man einen Login-1F haben? Discoverbale. Einen 2F per Stick? Undiscoverable.
-
@isotopp Stimmt nur zT (ich habe sie da), aber ja, mir ist sehr bewusst, dass PayPal eine sehr kaputte Implementierung nutzt. Bin ja selbst leidtragend.
Nochmal: Dagegen habe ich nie argumentiert. Ich weiß nicht was du mir mit diesem Hinweis sagen möchtest. Ich bin mir der Probleme bewusst, und rante regelmäßig dagegen.
-
@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.
-
-
-
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 Bitte sag', dass du nicht wirklich 2FA als Screenshots archivierst.
-
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 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 Andrerseits hatten wir bei KeePassXC anfänglich noch eine Disskussion, dass Relying Parties unsere AAGUID blocken könnten, weil wir das Exportieren der Passkeys erlauben. Das ist bisher (soweit ich weiß) nicht eingetreten, wäre aber eine Methode, das Ökosystem komplett kaputt zu machen.
-
@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 ich bin völlig bei Dir. Aber das Thema Backup/Recovery habe ich ansatzweise dadurch gelöst, dass ich meine (wenigen) Passkeys in Vaultwarden verwalte. System- und browserübergreifend und mit dem ohnehin nötigen Backup.
@fehrnetzt @isotopp Hier auch so. Ich nutze Vaultwarden (lokales Bitwarden) und habe somit komplett Systemübergeifend Zugriff auf meine Passkeys.
-
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 Entkräftet Deinen Rant nicht, aber FYI: Bei Apple sind die passkeys in der keychain und syncronisiert. Wenn der passkey auf dem Mac und dem iPhone auftaucht, kann man gut ausgehen, dass er das auf nem neuen iPhone/iPad tun wird.
Ist der einzige Ort, wo Passkeys nicht weh tun, ich hab auch seit Jahren mehrere yubikeys und keine Ahnung, ob im Ernstfall ein Backup-Key komplett ist und funktionieren wird. (Wenn die Dienste überhaupt mehrere PK zulassen.) -
@isotopp Bitte sag', dass du nicht wirklich 2FA als Screenshots archivierst.
@larsmb Selbstverständlich tu ich das, und das würde ich auch jedem anderen empfehlen:
Wenn das 2FA QR auftaucht, Screenshot wegspeichern auf dem Archiv-Stick und zwei Handies einlernen.
Dadurch wird man von kaputten Recovery Flows komplett unabhängig und kann neue Geräte auf eine leicht verständliche Weise einlernen.
-
@larsmb Selbstverständlich tu ich das, und das würde ich auch jedem anderen empfehlen:
Wenn das 2FA QR auftaucht, Screenshot wegspeichern auf dem Archiv-Stick und zwei Handies einlernen.
Dadurch wird man von kaputten Recovery Flows komplett unabhängig und kann neue Geräte auf eine leicht verständliche Weise einlernen.
Kleines shell script:
flo@p5:~$ cat bin/qrscreen
#!/bin/sh
gnome-screenshot -f /tmp/screen.png >/dev/null 2>&1 \
&& zbarimg -q /tmp/screen.png | sed -e 's/^QR-Code://'Und anschliesend das ganze in "gopass" speichern - Der kann die totps erzeugen (Auch im browser)
flo@p5:~$ gopass totp zz/*redacted*
952267
([q] to stop. -o flag to avoid.) This OTP password still lasts for:Und da kann man es ggfs auch wieder exportieren als qrcode damit man mobiles anlernen kann.
Und natürlich - gopass - git + gpg - kann man einfach in sein eigenes gitlab pushen oder was auch immer.
-
@larsmb Selbstverständlich tu ich das, und das würde ich auch jedem anderen empfehlen:
Wenn das 2FA QR auftaucht, Screenshot wegspeichern auf dem Archiv-Stick und zwei Handies einlernen.
Dadurch wird man von kaputten Recovery Flows komplett unabhängig und kann neue Geräte auf eine leicht verständliche Weise einlernen.
-
@larsmb Selbstverständlich tu ich das, und das würde ich auch jedem anderen empfehlen:
Wenn das 2FA QR auftaucht, Screenshot wegspeichern auf dem Archiv-Stick und zwei Handies einlernen.
Dadurch wird man von kaputten Recovery Flows komplett unabhängig und kann neue Geräte auf eine leicht verständliche Weise einlernen.
@isotopp Huh. Ich hab' halt einfach Backups des Passwort-Managers.

-
@larsmb Selbstverständlich tu ich das, und das würde ich auch jedem anderen empfehlen:
Wenn das 2FA QR auftaucht, Screenshot wegspeichern auf dem Archiv-Stick und zwei Handies einlernen.
Dadurch wird man von kaputten Recovery Flows komplett unabhängig und kann neue Geräte auf eine leicht verständliche Weise einlernen.
-
RE: https://social.tchncs.de/@kuketzblog/116034644267703808
Heißer Flamewar und Hot Takes in den Kommentaren
In der Theorie sollten Passkeys so wie SSH-Keys für das Web funktionieren und schneller, bequemer und sicherer als Paßworte sein.
In der Praxis ist das alles komplett fucked, es ist unklar, was wann von wem wo gespeichert wird und wie man es wiederherstellt, und wie man es portiert, wenn man Geräte wechselt. Oder wie der Recovery-Flow aussieht und ob der sicher ist.
Ich habe daher auf allen meinen Geräten Passkeys blockiert und warte noch fünf bis zehn Jahre ab. Bis dahein Bitwarden gegen Vaultwarden und OTP. Und ich archiviere die QR-Codes zur Initialisierung der OTP-Generatoren für jede Site, sodaß ich dem Recovery-Flow der jeweiligen Sites geflissentlich fern bleiben kann – ich lerne einfach ein neues Gerät nacheinander mit den Screenshots der archivierten Codes an.
Mein Rat an jeden der mich fragt ist: Macht halt Passkeys, wenn ihr glaubt, daß ihr wisst ob und wie es funktioniert und ihr das managen könnt.
Für mich lösen sie keine Probleme und schaffen nur neue, funktionieren unzuverlässig und das Management ist unklar.
@isotopp
Ja, wobei ich nicht den QR-Code archiviere sondern den Seed als String (kann man eigentlich überall alternativ anfordern). -
RE: https://social.tchncs.de/@kuketzblog/116034644267703808
Heißer Flamewar und Hot Takes in den Kommentaren
In der Theorie sollten Passkeys so wie SSH-Keys für das Web funktionieren und schneller, bequemer und sicherer als Paßworte sein.
In der Praxis ist das alles komplett fucked, es ist unklar, was wann von wem wo gespeichert wird und wie man es wiederherstellt, und wie man es portiert, wenn man Geräte wechselt. Oder wie der Recovery-Flow aussieht und ob der sicher ist.
Ich habe daher auf allen meinen Geräten Passkeys blockiert und warte noch fünf bis zehn Jahre ab. Bis dahein Bitwarden gegen Vaultwarden und OTP. Und ich archiviere die QR-Codes zur Initialisierung der OTP-Generatoren für jede Site, sodaß ich dem Recovery-Flow der jeweiligen Sites geflissentlich fern bleiben kann – ich lerne einfach ein neues Gerät nacheinander mit den Screenshots der archivierten Codes an.
Mein Rat an jeden der mich fragt ist: Macht halt Passkeys, wenn ihr glaubt, daß ihr wisst ob und wie es funktioniert und ihr das managen könnt.
Für mich lösen sie keine Probleme und schaffen nur neue, funktionieren unzuverlässig und das Management ist unklar.
@isotopp Passkeys auf den eigenen Geräten blockieren geht wie genau? Ich bin zusehends genervt davon, dass mir das als "klick mal schnell hier und dann ist anmelden viel einfacher" von diversen Diensten reingedrückt wird ...
-
RE: https://social.tchncs.de/@kuketzblog/116034644267703808
Heißer Flamewar und Hot Takes in den Kommentaren
In der Theorie sollten Passkeys so wie SSH-Keys für das Web funktionieren und schneller, bequemer und sicherer als Paßworte sein.
In der Praxis ist das alles komplett fucked, es ist unklar, was wann von wem wo gespeichert wird und wie man es wiederherstellt, und wie man es portiert, wenn man Geräte wechselt. Oder wie der Recovery-Flow aussieht und ob der sicher ist.
Ich habe daher auf allen meinen Geräten Passkeys blockiert und warte noch fünf bis zehn Jahre ab. Bis dahein Bitwarden gegen Vaultwarden und OTP. Und ich archiviere die QR-Codes zur Initialisierung der OTP-Generatoren für jede Site, sodaß ich dem Recovery-Flow der jeweiligen Sites geflissentlich fern bleiben kann – ich lerne einfach ein neues Gerät nacheinander mit den Screenshots der archivierten Codes an.
Mein Rat an jeden der mich fragt ist: Macht halt Passkeys, wenn ihr glaubt, daß ihr wisst ob und wie es funktioniert und ihr das managen könnt.
Für mich lösen sie keine Probleme und schaffen nur neue, funktionieren unzuverlässig und das Management ist unklar.
@isotopp
https://opensourcesecuritypodcast.libsyn.com/wtf-is-a-passkey-with-william-brown has a nice background
