Elon Musk’s X botched its security key switchover, locking users out
Leute, wenn ihr für eure Liebsten sinnvolle #Weihnachtsgeschenke sucht, dann überlegt euch, #FIDO2-USB-Tokens zu schenken:
https://karl-voit.at/FIDO2-vs-Passkeys/
Es gibt aktuell keine andere Methode, um sich garantiert #Phishing-geschützt anzumelden. #Passkeys haben leider inzwischen auch ein Einfallstor für Phishing bekommen (siehe entsprechende Sektion im Artikel).
#Yubikey als Produkt kann ich nicht mehr voll und ganz empfehlen: siehe FAQs.
#publicvoit #Sicherheit #security #Geschenkidee #Geschenkideen #Geschenke #Yubikeys
Passwortlose Logins mit #PassKey
[23. #Kielux 2025]
https://tube.tchncs.de/w/6jX5woe3UC1DodHeDSZuMh
Bei der Einrichtung des #Fairphones hatte ich Probleme mit 3 #yubikeys. Ich habe bei #1password meine Accounts entsprechend abgesichert und egal ob via USB-C oder NFC hat es bei 1Password nicht funktioniert
Allerdings bei der #Yubico Authenificator App schon
#Ubuntu24 verweigerte heute nach einem Reboot die Nutzung meines #Yubikeys.
Ich konnte mich als mit #pkcs11 nicht mehr an meinen Servern per ssh anmelden.
Eine hängengebliebene Filesystem-Action eines Remote-Filesystems verhinderte offenbar, dass Linux meinen Laptop nicht schlafen schicken konnte... Totem ließ sich nicht beenden vom Kernel... aber das ist eine andere Geschichte. Jedenfalls schaltete sich mein Laptop nicht ab bis der Akku leer war.
In einem Anfall seniler Bettflucht hab ich meinen Laptop hergenommen und wollte checken, warum Friendica nur mehr blurred Vorschaubilder anzeigt (Spoiler, das Debuglog eines anderen Services füllte mir die Platte an...) und mein ssh-agent verweigerte das Hinzufügen des Yubikeys. Standhaft.
Ein Blick ins Journal ergab dann folgende Seltsamkeit:
Dave Wood 🇨🇦
TechCrunch | Startup and Technology News
Karl Voit 
C.H.
Malte 
jakob 🇦🇹 ✅Sep 12 04:34:02 AET-1931 pcscd[24807]: 99999999 auth.c:143:IsClientAuthorized() Process 36310 (user: 2000) is NOT authorized for action: access_pcsc
Sep 12 04:34:02 AET-1931 pcscd[24807]: 00000197 winscard_svc.c:355:ContextThread() Rejected unauthorized PC/SC clientEin Restart von pcscd brachte keine Erlösung.
Ein Reboot übrigens auch nicht.
Also weitersuchen. Aufgrund der Recherchen einmal
opensc-tool --list-readers
No smart card readers found.Shice... und was sagt gpg?
gpg --card-status
gpg: selecting card failed: Kein passendes Gerät gefunden
gpg: OpenPGP Karte ist nicht vorhanden: Kein passendes Gerät gefundenDas Journal dazu befragt... scdaemon erkennt meine Smartcards, aber pcscd verweigert meinem User den Zugriff.
Also mal als Root... ja, da liefert opensc-tool meine Smartcards.
Dann eine noch seltsamere Erkenntnis...
In tmux ausgeführt, verweigert pcscd die Abfrage mit opensc-tool, in der normalen Bash gibts aber ein Ergebnis... meine Token sind da.
Dann hab ich meinen SafeNet eToken ausprobiert... der ließ sich wunderbar zum ssh-agent hinzufügen... gut, der nutzt aber auch den scdaemon bzw. pcscd nicht (extra Ausnahme in der Config).
Schließlich wurde ich auf bugs.debian.org/cgi-bin/bugrep… fündig. Offenbar wurden bei Polkit Rules entfernt, die es Usern erlauben, pcscd/Smartcards zu nutzen... am 8. September beim Update wurde /usr/share/polkit-1/rules.d/sssd-pcsc.rules so geändert, dass die Rule nur mehr für Root zieht. Da wurde das File zumindest aktualisert.
Und heut erst wurde die Änderung durch den Zwangsreboot schlagend...
Die Lösung war auf jeden Fall folgende:
Ich hab ein File /etc/polkit-1/rules.d/40-allow-pcscd.rules
# cat 40-allow-pcscd.rules
polkit.addRule(function(action, subject) {
if (
subject.isInGroup("plugdev")
&& (
action.id === "org.debian.pcsc-lite.access_pcsc"
|| action.id === "org.debian.pcsc-lite.access_card"
)
) {
return polkit.Result.YES;
}
return polkit.Result.NOT_HANDLED;
});Aber warum gpg am Yubikey nicht mehr funktioniert... bleibt mir auch ein Rätsel.
Ich habe gerade einen Designfehler als schwere #Sicherheitslücke bei Androids mit #Passkeys auf externen Token wie z.B. #Yubikeys mit #FIDO2 entdeckt...
Aber bevor ich einen Murdsbahö mache, würd ich gerne mal rückfragen, ob jene die sich mit #Security hier befassen, das auch so sehen.
Folgendes Szenario:
Ich habe #keycloak als Authentifikations-Service vor div. Services bei mir im Einsatz.
Dort habe ich einen Authentication-Flow der mir "Passwortlose" Authentifizierung erlaubt. Also der einen Passkey verwenden kann.
Als Passkey habe ich einen Yubikey 5C mit NFC im Einsatz.
Wenn ich diese Authentifikation am Laptop wähle, so muss der Yubikey eingesteckt sein. Ich gebe meinen Benutzernamen ein. Dann fragt mich der Browser nach dem PIN des Yubikeys. Den gebe ich ein, und dann werde ich aufgefordert, da drauf zu drücken, und schon bin ich angemeldet.
Genauso funktioniert das am Smartphone auch, wenn der Token per USB eingesteckt ist.
Ein Angreifer, der sich meinen Token stiehlt muss immer noch den PIN dazu wissen. Und nach 3x-iger falscher Eingabe ist der Token unbrauchbar.
Die Sicherheit ist also relativ hoch.
Aber Android (ich hab GrapheneOS im Einsatz) fragt mich auch, ob ich die Authentifizierung per NFC machen möchte. Das ist eine Google-App. Ja auch auf #GrapheneOS da diese noch nicht portiert wurde. Aber es ist egal, auf den allermeisten Androids rennt diese Google-App die für FIDO-Authentifizierung genutzt wird.
Wenn ich also NFC wähle, so muss ich nur den Token präsentieren und schon bin ich drin in meinem Account.
Es fehlt die Abfrage nach dem PIN des Token.
Ich habe in keycloak nichts gefunden, wo ich einstellen könnte, dass auch bei Authentifizierung mittels NFC der PIN abgefragt werden muss. Also scheint es die Google-App zu entscheiden, dass über USB der PIN abgefragt wird und über NFC nicht.
Und das sehe ich als gewaltige Sicherheitslücke, welche diesen Authentifizierungsflow in keycloak ad Absurdum führt.
Wenn ich einen Passkey eines Gerätes nehme, auf dem ich mich einloggen muss... ok. Es muss jemand meinen Laptop oder mein Smartphone stehlen und sich in meinen Account einloggen... dann passt es, dass kein PIN per NFC abgefragt wird.
Aber wenn ich bloß einen Yubikey stehlen muss und schon komm ich ohne dem Faktor "Wissen" in keycloak-Accounts rein... ist das NICHT GUT.
@kuketzblog @padeluun @publicvoit wie seht ihr das?
Guys, do you use YubiKey or similar devices?
I've been using YubiKey hardware keys for 2 years now, and I feel much more at ease when a service supports hardware keys (for example, Proton, Apple, etc.)
Saw some post about migrating #authenticator apps... and I realised I never used Google app for example. Because when I started configuring #2FA, I already had #Yubikeys 
So I naturally downloaded their Yubico Authenticator to use something I could use, without even thinking. And this was/is my first #OTP app I ever used.
I tried FreeOTP or something similar when it was recommended for some work thing in previous job, but never had a chance to really "feel" that because I changed jobs shortly after.
And now I thought for the first time that my only experience with OTP is when codes aren't device-locked... 
And for me it's absolutely natural state, as things should be.
@markwyner
I use a pair of #Yubikeys for my most valuable accounts, bank, phone, email, and unlocking my password manager. Also any “linked” accounts like “sign in with Google” are protected. It can be used where #passkeys are used, and a few other legacy hardware key apps/sites.
I like that it also stores TOTP seed keys so I can still have hardware level security for sites that don’t support passkeys yet.
Dmytro (Dima) Oliinyk
Mad Argon 
Nekodojo