mastouille.fr est l'un des nombreux serveurs Mastodon indépendants que vous pouvez utiliser pour participer au fédiverse.
Mastouille est une instance Mastodon durable, ouverte, et hébergée en France.

Administré par :

Statistiques du serveur :

648
comptes actifs

#passkeys

2 messages2 participants0 message aujourd’hui
Suite du fil

Tant de bo tinguessin #Passkeys arreu, en tots els servidors, bancs, oficines virtuals de les administracions etc. No hi haurien robatoris de contrasenyes perquè no hi hauria cap per robar!

Les claus d’accés (#Passkeys) són una forma moderna i segura d’iniciar sessió sense necessitat de contrasenyes tradicionals. Funcionen amb autenticació biomètrica (digital o facial) i utilitzen criptografia de clau pública per verificar la teva identitat.

Com funcionen?
1. quan crees una passkey, el teu dispositiu genera un parell de claus:
- Clau privada (emmagatzemada de forma segura al teu dispositiu).
- Clau pública (enviada al servidor del lloc web o app).

I'm basically dead in the water for anything that wants to [Google] reauthenticate occasionally (Google Finance, etc.) on this device (which is my daily driver). The issue is that the device-bound passkey isn't validating and it won't let me use anything else (like a security key).

Either the passkey on my Pixel 7 is corrupted, or the process of verifying it has a bug / wedge. Anything Google that wants to prompt for a passkey fails with the "2-Step Verification" flow's "Try another way" step. And even worse, the "other ways" (like the other passkeys I have on other devices, or the FIDO2 security keys that I have that predate passkeys) appear to succeed ... but then I'm redirected back to the same "try another way" as if presenting the key is being ignored even though it worked.

This was happening before the June update, and is still happening afterwards.

There also appears to be no way to delete a passkey from the Google Account side.

Edit: screenshot added (Sorry for the photo, had to take it from another device because you can't screenshot the auth flow)

Edit: this is only happening on one device. Other Google devices with automatically generated passkeys are working fine.

Edit: clearing all data for Chrome - not just cache, but all storage - fixed the issue for me!

Suite du fil

True story,
- Log into browser with IdP
- Get logged out of IdP
- Log back into IdP
- Click something in the browser's popover and now your browser has a passkey to the IdP
- Get logged out of browser and IdP
- Get locked out because you need to log into the browser to log into the IdP to log into the browser to log into the IdP to...

How can this failure mode exist?

Where do we even start to communicate this to users in a good way?

/rant

#infosec#passkeys#ux

#Passkeys are pretty cool, but the shotgun approach to implementation is horrendous.

It really grinds my gears that every browser, password manager++ tries to swoop in and steal that user flow.

Suddenly you've created and added passkeys to services without your intention, no knowing what key is used, which service has it or whether it's bound to hardware or roaming. It could be in the cloud for all you know.

I'm struggling to keep track, and I work with this every day...

A répondu dans un fil de discussion

Der Weg zu einem zuverlässigen Phishingschutz ist unklar und schwierig. Ein Schritt ist die Abkehr von Passwörtern, die wir Menschen uns merken müssen und damit auch einmal am falschen Ort eingeben können. Z.B. über #PassKeys.

Aber auch Sender von "guten" Mails könnten diese klarer von Phishing abgrenzen. Beispielsweise immer nur ab der eigenen, bekannten Domain versenden und Call-to-Action-Links nur auf ihre Domain zeigen lassen.

Mehr hier:
dnip.ch/2025/05/28/schweizerde

Das Netz ist politisch · Schweizerdeutsch liegt im Trend – auch bei Phishing - Das Netz ist politischSpam und Phishingversuche auf Schweizerdeutsch scheinen beliebter zu werden. Wieso nutzen Spammer denn diese Nischensprache? Schauen wir in dieser kleinen