This is a story of how ZDNet got blocked from my new list.

Absolute bullshit. The term "click bait" doesn't cover it. It's total bullshit. ZDNet knows it's bullshit but decided making people anxious about their passkeys was no big deal and ran with it anyway.

This is not acceptable. It takes significant cognitive load to filter information, even on a good day. Throwing these "you must act" headlines into the mix is grossly abusive. ZDNet is dead to me now.

Your #passkeys could be vulnerable to #attack, and everyone - including you - must act. When a clickjack attack managed to hijack a passkey #authentication ceremony, were password managers really to blame? ZDNET's investigation reveals a more complicated answer.
https://www.zdnet.com/article/your-passkeys-could-be-vulnerable-to-attack-and-everyone-including-you-must-act/
#security #vulnerability

I released SimpleWebAuthn v13.2.0 over the weekend

Highlights include @deno_land 2.2+ support, improved support for more esoteric attestation cert chain public keys, and an escape hatch for RPs that want to allow SafetyNet attestations from rooted devices.

Check out the changelog for more info:

https://github.com/MasterKale/SimpleWebAuthn/releases/tag/v13.2.0

Oh cool, SimpleWebAuthn got a shout-out in one of Cursor's videos

...I only spotted a few issues with the PR

h/t @cendyne

Hang on?!? I created a passkey for Amazon through Google!?!

TIL that NPM lets you use passkeys for second factor

https://hachyderm.io/@febog/115175499384585446

So it looks like it is actually possible to remove TOTP 2FA from your NPM account and leave only passkeys as a required second factor.

heise+ | So ermöglichen #Passkeys passwortlose Authentifizierung | iX Magazin https://www.heise.de/ratgeber/So-ermoeglichen-Passkeys-passwortlose-Authentifizierung-10476770.html #heiseplus

Making Self-Service Password Reset and Account Recovery Secure – Source: securityboulevard.com https://ciso2ciso.com/making-self-service-password-reset-and-account-recovery-secure-source-securityboulevard-com/ #rssfeedpostgeneratorecho #SecurityBloggersNetwork #CyberSecurityNews #SecurityBoulevard #Identity&Access #Risk&Compliance #authentication #Industrynews #passwordless #Perspectives #Passkeys #SBNNews

A beta release of KeePassDX with passkey support will be available soon

https://github.com/Kunzisoft/KeePassDX/issues/1421#issuecomment-3258372000

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?

Suche: Gute Erklärung für #Passkeys, für Anfänger*innen. Gern mit Einordnung, wann die relevant sind, aber vor allem gern die gut verständliche Anleitung.

How #Passkeys Work—and How to Use Them

https://www.wired.com/story/what-is-a-passkey-and-how-to-use-them/

Still trying to understand who the audience for passkeys are.

There are folks who just won't get onboard with password managers, and while I hope they would adopt passkeys I'm doubtful.

Then there are folks like me who are perfectly happy with using different passwords everywhere. For which passkeys would be taking a step backwards

UniSuper #passkeys

https://www.unisuper.com.au/articles/2025/06/how-do-passkeys-keep-you-safe

#Development #Analyses
Passkeys and modern authentication · Let’s consider whether this is really what we want https://ilo.im/166klm

_____
#Business #BigWeb #Gatekeepers #Authentication #Passkeys #PasswordManagers #WebDev #Frontend #Backend #Pitfalls

Avec les passkeys, on a une authentification sécurisée, pratique et sans mot passe.
Découvrez comment les implémenter en pratique avec @kehrlann !

https://www.paris-web.fr/2025/conference/passkeys-en-pratique