Chrome sur Mac gère les clefs d'identification "Passkeys"
C'est au tour de Chrome sur Mac de savoir gérer les passkeys, ces clefs d'identification pour se connecter à un service en ligne en tapant son identifiant, mais sans avoir à saisir ensuite son mot de passe.
Il ne suffit pas qu'un navigateur devienne compatible avec ce système pour ouvrir comme par magie tous les sites requérant une identification. Le responsable du site a sa part à jouer et doit le doter de cette capacité. Nous avions détaillé récemment la manière de procéder avec le site de la banque Boursorama qui utilise les passkeys depuis peu pour son espace client.
Boursorama gère déjà les clés d'identification : plus besoin de mot de passe pour accéder à son compte
La méthode décrite alors avec Safari est identique — ou presque — avec Chrome. Il faudra au préalable activer cette fonction sur le site qui la propose (Boursorama parle de « clé de sécurité »).
Ensuite, lorsqu'on revient, on saisit son identifiant puis après validation, le site propose de conclure votre identification en utilisant un appareil de confiance qui contient la clef. Cela peut être une clef USB de sécurité, mais aussi, et surtout, votre iPhone, iPad ou votre Mac (équipé d'un bouton Touch ID).
Lorsque votre appareil vous a identifié avec son système biométrique, le site valide votre accès. Vous n'aurez rien eu à taper. Plus de problème en cas de trou de mémoire (la saisie de son mot de passe, comme avant, reste bien sûr possible en dernière extrémité).
Chrome diffère toutefois de Safari en cela qu'il ne se sert pas de Touch ID sur Mac. À la place, le site affiche un QR code que l'on vise avec l'appareil photo de son téléphone. Touch ID ou Face ID sont alors appelés et vous validez votre identité par leur entremise.
Sur iPhone, Chrome fonctionne de la même manière que Safari puisqu'il se repose sur son moteur.
Passkeys : le futur sans mots de passe se conjugue au présent
> Chrome diffère toutefois de Safari en cela qu'il ne se sert pas de Touch ID sur Mac.
Je ne sais pas si vous parlez d'une site en particulier mais par exemple sur Boursorama sur chrome mac, j'utilise bien le touch ID du mac, je n'ai pas besoin de scanner un QR code avec mon mobile.
Il y a quelque chose qui m'échappe. J'ai encore essayé avec Boursorama dans Chrome Mac, je n'ai pas d'autres choix que ceux dans la capture : clef USB ou autre méthode qui affiche immédiatement le QR Code.
Tu as la version stable de Chrome (108.0.5359.98) ou une plus récente en dev ?
@supapopo
Idem pour moi
Webauthn demande le touchid ou une app ou une clé
A quand la prise en charge de Passkeys pour s'identifier sur le ClubiGen 😉
« Chrome sur Mac gère les clefs d'identification "Passkeys" »
Titre trompeur 😵
Chrome ne gère pas les passkeys , car c’est Apple keychain qui les gère:
chrome se contentant de supporter le protocole.
J’aurai plutôt écrit :
« Chrome ajoute la compatibilité avec le système Passkey »
Pourquoi ce serait le trousseau d'accès d'Apple qui les gérerait??? 😳
Moi mes passkeys sont gérés par 1Password. Je n'ai rien dans le Trousseau Apple.
(Et je n'ai pas testé car je ne l'utilise pas non plus, mais il est tout à fait possible que le trousseau de Chrome puisse gérer lui-même les passkeys, comme il peut gérer les mots de passe des utilisateurs !)
@r e m y
Lis l’article avant de réponse
« Sur iPhone, Chrome fonctionne de la même manière que Safari puisqu'il se repose sur son moteur. »
Tu écris que le titre est trompeur ! Or le titre c'est "Chrome sur Mac..." et tu l'as même recopié dans ton commentaire. Alors excuse-moi de te parler de Chrome sur Mac (et pas sur iPhone!)
@r e m y
La réponse dans l’article que tu n’as pas lu…
Mais ce que tu dis est faux!
Donc si tu crois l'avoir lu dans l'article, désolé, mais tu as lu de travers... 🤦♂️
@Sgt. Pepper
"En train, à cheval, en Cadillac, chu toujours à côté de la track... etc."
Le Rock'n' Roll du Grand Flanc Mou...
@r e m y
Vos Passkeys sont dans 1Password? Vous avez une version beta? Car les passkeys seront supportés par 1Password début 2023 seulement…..
Tout à fait!
Vous pouvez vous inscrire au beta test depuis cette page:
https://www.future.1password.com/passkeys/ (Sign up for early access).
@r e m y
Non justement. 🤦♂️
Chrome ne se connecte plus au trousseau de macOS, mais à Google Password Manager.
Par défaut et sauf utilisation d'une extension pour le gérer de manière tierce les données sont stockées chez Google.
En outre, sur Edge/Chrome Windows, Apple laisse l'extension accéder aux données du trousseau iCloud, sur macOS ce n'est pas possible et Apple oblige à passer par Safari : https://support.apple.com/fr-fr/guide/icloud-windows/icw76039ec0f/icloud
Juste pour clarifier un peu les choses:
Si vous créez un passkey à partir de Chrome, il sera sauvegardé dans le trousseau Google.
Si vous le créez dans Safari, il sera sauvegardé dans le trousseau iCloud.
L’utilisation du Qr Code, c’est justement pour pouvoir utiliser un passkey du trousseau iCloud quand on utilise Chrome. Ou l’inverse….
Et j’aimerais aussi préciser que ce n’est pas une nouveauté de la dernière version de Chrome. Ça fait au moins un mois que j’expérimente les passkeys dans Chrome sans utiliser une version beta (Canari)
Le plus gros problème des passkeys sera d’expliquer au commun des mortels comment ça marche….
Je vous prie de pardonner ma condescendance mais j'ai un peu de mal...
J'ai l'impression d'être Brochant dans le dîner de con quand il dit "le téléphone sonne il est content"... (quand Juste Leblanc devine que Brochant a perdu sa femme)
"Chrome gère les passkeys"
Mais la vraie question est "où stocke-t-il cette p... de clé privée ?", jamais traitée dans les informations.
Si c'est pour supprimer les mots de passes (parce que l'ANSSI a dit que c'est mal de les noter dans des calepins en papier) pour les envoyer dans les clouds non chiffrés (pardon chiffré mais avec un double de la clé chez eux) des gama (parce que vous comprenez, "nous" avons peur que vous ne perdiez la clé) c'est 💯% pourri.
Est-ce que 1password propose toujours le stockage "on premise" ou au moins sans faire appel à leur service de cloud ?
On est vraiment en train de donner nos clés numériques aux gama et autres.
"où stocke-t-il cette p... de clé privée ?",
Dans l'appareil, ensuite les clés privées sont synchronisées dans Google Password Manager entre les appareils si la synchronisation est active, et ce avec la politique de chiffrement choisi. Par défaut c'est le compte google ou sinon par une phrase secrète.
Les clés publiques et privées sont cryptées de bout en bout pour le transfert et stockées chiffrés.
https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html
Comme tout produit GAMA, c'est effectivement soumis à leurs lois sur la sécurité intérieure et malgré toutes les promesses effectivement si besoin accessibles par leurs services de renseignement ou agences apparentées. Il n'y a que la justice civile qui n'y a pas accès.
@lmouillart
Merci beaucoup. Quelques extraits
Le début fait peur car la clé de chiffrement du catalogue de clés privées stockée en backup est le code du téléphone qui peut être faible et testé par force brute par Google
"To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys. Note, that restoring passkeys on a new device requires both being signed in to the Google Account and an existing device's screen lock."
La suite n'est que moyennement rassurante car il limite a priori que les forces brutes externes en limitant les essais (par contre les 0000, 1234, et les dates de naissances, bof bof, les "gestes" que je vois dans le métro c'est un general un U, un trait ou un rond) mais il ne limite rien pour eux.
"Since screen lock PINs and patterns, in particular, are short, the recovery mechanism provides protection against brute-force guessing. After a small number of consecutive, incorrect attempts to provide the screen lock of an existing device, it can no longer be used. This number is always 10 or less, but for safety reasons we may block attempts before that number is reached. Screen locks of other existing devices may still be used."
Le fin est beaucoup mieux car ils disent utiliser une enclave sécurisée matérielle à l'instar de iPhones et appareils Android
"The data that allows Google to verify correct input of a device's screen lock is stored on Google's servers in secure hardware enclaves and cannot be read by Google or any other entity. The secure hardware also enforces the limits on maximum guesses, which cannot exceed 10 attempts, even by an internal attack. This protects the screen lock information, even from Google."
Donc effectivement Google peut pas chercher le code par force brute non plus (s'ils ne mentent pas mais je fais en général confiance à ces très grosses boîtes qui ont plus à perdre à trahir qu'à rester honnête, même si les équilibres de Nash se brisent assez facilement en cas de bouleversement).
Maintenant au moment où un utilisateur ajoute un nouveau système Android ou installe chrome, Google et les autorités américaines peuvent a priori en profiter pour piquer la clé (ils ne parlent pas d'avoir du TLS directement géré par l'enclave sécurisée et comme de toutes façons les américains gèrent les certificats de TLS ils pourraient faire un man in the middle).
Il y a le même document chez Apple ?