Les mots de passe ont vécu, vive le passwordless 🤔 — mais pas encore totalement enterrés. Entre réutilisation, phishing, fuites massives et usagers fatigués, la gestion des identifiants est devenue la première cause opérationnelle de compromission. Sans compter les MFA Fatigue : ou comment cliquer frénétiquement sur “Accepter” est devenu la nouvelle faille. C’est dans ce contexte que les passkeys émergent : une façon d’authentifier un utilisateur sans jamais transmettre ni stocker un secret réutilisable côté serveur, grâce à la cryptographie à clé publique. Les géants et la communauté standards poussent fort (FIDO, W3C/WebAuthn) : l’idée est simple sur le papier et séduisante en pratique — moins d’emails « mot de passe oublié », moins de phishing réussi, moins de tickets helpdesk. FIDO Alliance

Mais attention : « sans mot de passe » ne veut pas dire « sans risques ». Le passage de la théorie (clé publique/privée) à la production dans des environnements hétérogènes (desktop + mobile + applis legacy + reverse proxies + SSO fédéré) introduit toute une série de surfaces d’attaque et de pièges opérationnels. On y revient plus bas, avec des scénarios concrets. 

🧩 Qu’est-ce qu’une passkey ?

Une passkey est, pour faire vite, un type de credential (identifiant cryptographique) basé sur le modèle clé publique / clé privée. Concrètement :

• L’appareil de l’utilisateur crée localement une paire de clés.
• La clé publique est envoyée et stockée sur le serveur du service (le « relying party »).
• La clé privée reste sur l’appareil (smartphone, PC, clé matérielle). Elle ne sort jamais.
  Lors de l’authentification, le serveur envoie un challenge (un petit paquet unique) que l’appareil signe avec la clé privée. Le serveur vérifie la signature avec la clé publique qu’il a stockée. Si la signature colle, l’utilisateur est authentifié — sans mot de passe à taper, et sans secret côté serveur pouvant être réutilisé sur d’autres sites. Ce mécanisme est la base de WebAuthn/FIDO.

🔑 Principe PKI & challenge-response (explication accessible, sans Diffie-Hellman)

On va le dire simplement, étape par étape (pour un novice technique) :

1. Enregistrement (inscription)
   • L’utilisateur clique « Enregistrer un passkey ». Sa machine génère une paire de clés (privée + publique).
   • La clé publique est envoyée au serveur, avec des métadonnées (type d’authenticator, attestation si disponible). Le serveur stocke la clé publique associée à l’utilisateur.
2. Authentification (login)
   • Le serveur génère un challenge (nombre aléatoire unique) et l’envoie au client.
   • Le client demande à l’authenticator local (puce TPM / enclave/clé USB) de signer ce challenge avec la clé privée. L’utilisateur valide localement (PIN ou biométrie).
   • Le client renvoie la signature au serveur. Le serveur vérifie la signature avec la clé publique stockée. Si OK → accès accordé.

Pourquoi c’est fort : la clé privée ne transite jamais, elle n’est pas copiable (sauf si l’appareil est compromis ou si l’authenticator le permet). Même si un pirate vole la base de données du serveur, il n’obtient que des clés publiques — inutile pour se faire passer pour l’utilisateur. passkeycentral.org

🔐 FIDO / WebAuthn — ce que les devs doivent vraiment savoir

WebAuthn (la couche standardisée côté web) + FIDO (les specs d’authenticators) forment la brique qui rend les passkeys utilisables par les navigateurs et les systèmes. C’est beau sur le papier : un navigateur parle à l’authenticator (TPM, secure enclave, clé USB), l’authenticator signe un challenge, et le serveur vérifie la signature. Mais pour qu’un déploiement soit sûr, le serveur doit faire un tas de vérifications — pas juste “vérifier la signature” et hop. La spec définit une procédure détaillée (la fameuse procédure en ~19 points pour la validation d’enregistrement) que tout dev sérieux doit implémenter ou déléguer à une librairie fiable.

🧾 Le flux d’implémentation côté serveur (vue pragmatique)

1) Inscription (registration) — checklist serveur

Lorsqu’un client envoie la PublicKeyCredential après navigator.credentials.create(), côté serveur il faut valider scrupuleusement :

• Vérifier que le RP ID (relying party id) correspond bien à votre domaine / scope attendu.
• Vérifier l’origin dans le clientDataJSON (même hôte + protocol) : c’est la barrière anti-phishing côté web.
• Vérifier que le challenge retourné est bien celui que le serveur a émis (lié à la session utilisateur).
• Parser attestationObject (CBOR), extraire authenticatorData et la clé publique (COSE format) — attention au décodage base64url / CBOR.
• Vérifier le format d’attestation (fmt) et valider l’attestation en conséquence (packed, tpm, fido-u2f, android-key, android-safetynet, apple, none). Selon le format, il faudra vérifier des certificats, signer des chaînes, ou accepter l’absence d’attestation.
• Contrôler le signatureCounter initial (doit exister) et enregistrer la clé publique + credential ID + counter + algorithme.
• Respecter la politique d’attestation choisie : accepter les attestations « none » (anonymes) ou exiger une attestation vérifiable via la FIDO Metadata Service.
• Valider flags uv (user verification) / up (user presence) selon votre requirement (MFA, passwordless strict, etc.).
• Gérer erreurs et rejets : logging, réponse claire pour l’UX côté client.
  Ces étapes sont celles formalisées dans le spec — ne pas les faire, c’est s’exposer à des contournements. Google for Developers+1

🔎 Attestation : utile mais dangereux — et pourquoi tu dois décider d’une politique

L’attestation est la preuve que l’authenticator est bien fabriqué par un fournisseur (attestation certificate chain). C’est utile pour détecter des authenticators compromis ou non-conformes, mais :

• Les formats sont variés : packed, tpm, fido-u2f, android-key, android-safetynet, apple, none. Chacun a une vérification différente. MDN Web Docs
• Exiger l’attestation « full trust » (chaîne CA vérifiée) augmente la sécurité, mais réduit l’interopérabilité (beaucoup d’authenticators vont renvoyer none ou packed sans chaîne publiquement vérifiable).
• Il existe des services et listes (FIDO Metadata Service) pour vérifier les identifiants d’authenticators. Pour les environnements sensibles, activer la vérification metadata est recommandé ; en revanche, c’est une gestion opérationnelle en plus.
  Bref : décide si tu veux contrôler le modèle d’authenticator, ou faire confiance au device & UX. Les deux approches ont un coût. W3C

✅ Vérification d’assertion (login) — les checks impératifs

Lors d’un login (assertion), le serveur doit :

1. Récupérer le credentialId envoyé et retrouver la clé publique + counter associée.
2. Vérifier que l’origin et le rpId matchent.
3. Vérifier que le challenge dans clientDataJSON correspond à celui émis par le serveur.
4. Vérifier la signature de l’authenticatorData || clientDataHash avec la clé publique (algorithme COSE attendu).
5. Vérifier les flags up (user presence) et uv (user verification) selon la politique de l’app.
6. Vérifier que la signatureCounter est bien supérieure au compteur stocké (détection de clones/devices clonés). Si non — alerter / révoquer.
7. Mettre à jour le compteur stocké.
8. Rejeter si quoi que ce soit ne colle (mauvais algorithme, challenge mismatch, signature invalide, rpId mismatch, origin mismatch).
   Ces étapes (et d’autres variantes) sont listées par la spec et implémentées par des bibliothèques matures (Duo Labs, Yubico, SimpleWebAuthn, WebAuthn4J, etc.). Déléguer à une librairie testée réduit drastiquement les pièges.

🧩 Les pièges techniques qui vont te pourrir la vie (et comment les éviter)

• CBOR / COSE parsing : erreurs de parsing = vulnérabilité. Utiliser des libs éprouvées.
• Origin vs RP ID : si tu te trompes, tu acceptes des assertions depuis d’autres domaines (phishing). Toujours vérifier strictement l’origin.
• Algorithmes supportés : n’accepte pas aveuglément toutes les clefs/algos ; impose ECDSA P-256 (ES256) ou équivalents robustes.
• Gestion du credentialId : doit être indexable et unique — attention aux collisions et formats (binary blob).
• Compteurs : les authenticators logiciels peuvent ne pas incrémenter correctement — politique de tolérance à prévoir mais aussi processus d’investigation.
• Attestation CA compromise / magasin de certificats : si une CA d’attestation est compromise, tu dois pouvoir révoquer les attestations et forcer réenregistrement. (On détaille le scénario magasin de certificats dans la section attaque.) developers.yubico.com

🧾 Le “19 points” — que faut-il retenir ?

Le WebAuthn spec décrit une procédure en ~19 points pour valider l’enregistrement (registration) afin d’éviter que l’implémentation fasse un raccourci délétère. Ce n’est pas une check-list marketing : c’est la garantie que l’on n’a pas laissé une faille triviale (mismatch origin, challenge, parsing CBOR, algos, attestation, flags…). Si tu veux être tranquille, implémente la procédure complète ou utilise une librairie qui la suit à la lettre — l’écosystème a déjà des implémentations robustes (Duo Labs, Yubico, SimpleWebAuthn, WebAuthn4J). Guide to Web Authentication

✅ Les 19 points de validation WebAuthn (registration)

1. Recevoir la réponse client : clientDataJSON + attestationObject.
2. Vérifier la structure : s’assurer que clientDataJSON est bien JSON et que attestationObject est un CBOR valide.
3. Extraire clientData et vérifier :
   • que type = "webauthn.create".
   • que le challenge correspond à celui généré par le serveur.
   • que l’origin est bien celui attendu (ex. https://tondomaine.com).
   • que tokenBinding (si présent) est cohérent.
4. Hacher clientDataJSON pour obtenir clientDataHash.
5. Extraire authenticatorData de l’attestationObject.
6. Vérifier le RP ID hash dans authenticatorData correspond au hash SHA-256 du RP ID attendu (ton domaine).
7. Vérifier les flags dans authenticatorData :
   • UP (user present) = 1 (l’utilisateur a interagi).
   • UV (user verified) selon ta politique (PIN, biométrie).
8. Extraire le compteur (signCount).
9. Extraire la clé publique du attestedCredentialData (format COSE).
10. Vérifier que le credentialId est unique (non déjà enregistré dans ta base).
11. Vérifier que la clé publique est dans un algorithme supporté (ex. ES256).
12. Vérifier l’attestation : format (packed, tpm, fido-u2f, android-key, etc.).
13. Valider la signature de l’attestation : signature faite avec la clé d’attestation sur (authenticatorData + clientDataHash).
14. Vérifier la chaîne de certificats d’attestation (si applicable).
15. Vérifier les métadonnées (via FIDO Metadata Service ou politique interne) : AAGUID, algorithme, validité.
16. Vérifier les extensions (si présentes) : que leur traitement est conforme et qu’elles ne violent pas ta politique.
17. Appliquer ta politique d’attestation : accepter ou refuser selon l’attestation (none, cert validé, etc.).
18. En cas de succès : stocker credentialId, clé publique, compteur initial, AAGUID, algorithme, flags, et attestation metadata.
19. En cas d’échec : rejeter la création et loguer l’erreur pour analyse.

🧭 Recommandations pratiques (checklist courte pour devs)

• N’ignore jamais clientDataJSON.origin et le RP ID.
• Utilise une lib WebAuthn mature plutôt que du code maison (par ex. WebAuthn4J, simplewebauthn, duo-labs).
• Décide ta politique d’attestation (accept/reject none, metadata service?).
• Ne stocke que : credentialId, clé publique (COSE), algorithme, signatureCounter, date d’émission, attestation metadata.
• Prends en charge la portabilité (passkey sync via vendor cloud) mais documente les risques et offre des alternatives (clés matérielles).
• Prévois un processus de récupération sécurisé (par ex. réenregistrement avec MFA humaine, ou workflows identifiés), pas un reset trivial par helpdesk.
• Ajoute du monitoring sur échecs d’assertions, mismatch de counter, tentatives répétées — ces signaux précèdent souvent une attaque ciblée.

En bref (piquant mais franc)

WebAuthn/FIDO ne sont pas un gadget marketing à cocher. C’est une techno solide, mais exigeante côté implémentation et gouvernance. Si tu traites ça comme « un simple remplacement de mot de passe » et que tu skips la validation, l’attestation ou la gestion des origins, tu vas juste déplacer la surface d’attaque — et probablement te retrouver avec des erreurs sournoises en prod. Fais-le propre, confie ça à des bibliothèques éprouvées, et prépare-toi à gérer attestation, policies, et récupération utilisateurs. Le diable est dans les 19 points. 

🧨 Scénario d’attaque — compromission d’un magasin de certificats (attestation)

🔎 Contexte rapide

La valeur ajoutée des passkeys/FIDO passe aussi par l’attestation : un authenticator peut fournir une preuve (certificat d’attestation) liant la clé publique créée à un fabricant/produit. Les serveurs peuvent utiliser ces attestations pour décider s’ils acceptent ou non un authenticator. Mais si le magasin de certificats d’attestation (la chaîne de confiance, ou la PKI qui signe les attestations) est compromis — ou si un CA/Issuer est frauduleusement émis — on transfère la confiance vers un composant qui peut être trahi. Bref : on a déplacé la cible.

🎯 Objectif de l’attaquant

Créer/présenter des attestations apparemment valides (ou corrompre la vérification) pour faire accepter des authenticators contrôlés par l’attaquant, permettant la connexion sans posséder les comptes légitimes (ou pour faciliter d’autres escroqueries/implantations).

🔢 Déroulé détaillé de l’attaque (étapes)

1. Compromission initiale
   • Voie A : compromission d’un CA d’attestation (ex : vol de clé privée d’un émetteur d’attestation).
   • Voie B : compromission d’un service intermédiaire (magasin de certificats interne, FIDO Metadata Service mal protégé, ou système d’ingestion d’attestations).
   • Voie C : social engineering + installation d’un certificat racine local (Windows) sur des postes ciblés (deux clics « Installer ce certificat »).
2. Fabrication d’attestations malveillantes
   • L’attaquant utilise la clé d’attestation volée (ou un CA compromis) pour signer des attestationObjects qui contiennent des clés publiques contrôlées par l’attaquant.
   • Ces attestations paraissent conformes au format attendu (fmt = packed|tpm|fido-u2f|...) et contiennent des chaînes de certif valides ou faussées.
3. Enrôlement / propagation
   • L’attaquant enregistre massivement des credentials « légitimes » sur des services ciblés (inscriptions automatisées via API ou via sessions de phishing ciblées).
   • Si le serveur exige ou vérifie l’attestation, celle-ci passe la validation (CA compromise), donc le credential est accepté.
4. Évasion & persistance
   • Les credentials malveillants sont utilisés pour authentifier, contourner MFA, ou créer des sessions persistantes.
   • Alternativement, l’attaquant installe des backdoors côté serveur (modifie vérifications, bypass origin checks) pour faciliter l’usage ultérieur.
5. Escalade et exploitation
   • Avec accès, l’attaquant peut demander réinitialisation d’accès, escroquerie interne, exfiltration, ou mouvement latéral vers des systèmes sensibles.

💥 Conséquences pratiques

• Comptes compromis malgré l’usage de passkeys « hardware » ou « verified ».
• Perte de confiance dans la chaîne d’attestation ; nécessité d’un forcé réenregistrement massif.
• Impact fort si l’attaque touche un provider cloud (synchronisation passkey compromise).
• Coût opérationnel énorme (revocation, forensics, communication, obligations légales).

🕵️ Signaux & indicateurs de compromission (logiques à surveiller)

• Pics d’enregistrement : vagues anormales d’enrôlements d’authenticators avec le même AAGUID / même chaîne d’attestation.
• Multiples credentialId associés à un même attestation certificate serial.
• SignatureCounter qui n’augmente pas correctement (ou qui augmente bizarrement) — clones ou authenticators non conformes.
• Origin / RP ID mismatches dans logs de clientDataJSON (tentatives d’inscription via des origins inattendues).
• Échecs d’attestation parsing suivis d’acceptations manuelles ou bypass côté infra.
• Événements SIEM : connexions réussies hors horaires, IPs géo-anormales, nouveaux devices non inventoriés.

Exemples de requêtes SIEM (pseudo) :

• SELECT count(*) FROM webauthn_registrations WHERE aaguid = 'XXXX' AND timestamp > now()-1h GROUP BY serial
• search logs where event='assertion' and signatureCounter <= previous_counter

🛡️ Mesures d’atténuation & bonnes pratiques (opérationnelles + techniques)

A. Gouvernance & politique d’attestation

• Politique claire : définir si tu acceptes fmt=none ou si tu exiges attestation CA vérifiable. Pour les comptes sensibles, n’accepte que les attestations vérifiées via FIDO MDS.
• Inventory AAGUID : maintenir une liste blanche d’AAGUIDs approuvés (pour comptes sensibles).
• Rotation & révo : préparer un plan de révocation d’attestations (et d’IDs compromis) — pas trivial mais indispensable.

B. Renforcer la chaîne d’attestation

• Protéger les PKI/CA : HSM pour les clés d’attestation, MFA forte pour accès aux CA, audits réguliers, journaux immuables.
• Vérifier la Metadata FIDO : utiliser la FIDO Metadata Service pour valider les authenticators et détecter anomalies.
• Ne pas faire confiance aveuglément : cross-check du cert chain, vérifier les EK certs TPM/nonce si possible.

C. Durcissement côté client & OS

• Éduquer utilisateurs : bloquer l’installation de certificats racine par utilisateurs non-admin ; renforcer politiques Windows GPO.
• Bloquer WebUSB / extensions non-trusted : restreindre extensions navigateur via listes blanches, désactiver WebUSB si non nécessaire.

D. Harden serveur & logging

• Valider strictement origin & RP ID ; refuser tout mismatch.
• Vérifier challenge/session binding pour éviter replay.
• Stocker counters et monitorer ; alerter sur anomalies.
• Ne pas déléguer l’attestation aveuglément : stocker la trace complète de l’attestation pour forensics.

E. Processus de récupération & IR

• Processus de récupération robustes (réenregistrement avec 2 facteurs physiques, vérification manuelle).
• Playbook IR : isoler, révoquer credentials identifiés, forensics sur CA/metadata, communication aux tiers, forcing re-enroll.
• Table-top exercises sur scénarios de CA compromise.

🔚 Conclusion piquante

La passkey rend la vie plus dure aux phishing-kickers et aux failles classiques de mot de passe. Mais si tu confies la vérification à un magasin de certificats ou à une chaîne d’attestation non-protégée, tu donnes à un attaquant une clé maîtresse morale : il pourra fabriquer l’apparence de légitimité. En clair : la passkey te protège d’un certain nombre d’attaques, pas d’une mauvaise gouvernance de la PKI. La sécurité réelle vient d’un triptyque : implémentation correcte (19 points), chaîne d’attestation bien protégée, et procédures de réponse testées

🌐🪟 WebAuthn & navigateurs — pourquoi le client web reste le maillon fragile

Les passkeys sont superbes… jusqu’à ce que le navigateur fasse la connerie. WebAuthn repose sur un axiome : le navigateur fait bien son boulot (vérifie l’origin, relaye proprement les challenges, n’expose pas la clé privée). Malheureusement, dans la vraie vie, le navigateur n’est pas un bunker inviolable — il a des extensions, des APIs riches (WebUSB, WebAuthn, WebCrypto, etc.), et un DOM qui peut être manipulé par du code injecté. Voici où ça coince, et comment s’en prémunir.

🔓 Extensions malveillantes et profils compromis

Les extensions de navigateurs sont une porte trop souvent laissée ouverte. Une extension malveillante ayant des permissions étendues (activeTab, webRequest, file access) peut injecter du JS dans des pages, modifier le DOM, ou intercepter des réponses. Résultat : un script malveillant pourrait lancer des flows d’enregistrement/connexion (navigator.credentials.create() / navigator.credentials.get()) en contexte utilisateur trompé, forcer des prompts, ou exfiltrer des métadonnées.
Même si la clé privée ne sort jamais, une extension qui simule l’UX (popup biométrique factice) peut conduire à des actions d’acceptation par l’utilisateur. Bref : les extensions, c’est la roulette russe.

Mitigation : force de la whitelist d’extensions via MDM/GPO, audit périodique des extensions en production, et blocage des extensions non-essentielles pour les comptes à privilèges.

🧯 WebUSB, WebHID, WebBluetooth — trop de portes ouvertes

Les APIs modernes (WebUSB / WebHID / WebBluetooth) permettent aux pages d’interagir avec du hardware. Combinaison dangereuse : une page piégée qui accède à un authenticator mal configuré (ou à un dongle USB mal protégé) peut tenter des opérations non voulues. Même si WebAuthn reste soumis à origin checks et user gestures, ces APIs augmentent la surface d’attaque.

Mitigation : désactiver WebUSB/ WebHID dans les environnements sensibles via politiques navigateur, ou restreindre par extension.

⚔️ XSS + WebAuthn = mauvais mélange

Le modèle WebAuthn s’appuie fortement sur la confiance dans le DOM : si un site est vulnérable à une XSS, un attaquant peut injecter un script qui déclenche l’authentification ou l’enregistrement, redirige les challenges, ou manipule l’UI pour tromper l’utilisateur. Même si clientDataJSON.origin protège contre le phishing cross-site, la XSS intervient sur le même origin, donc l’origin check devient inutile : tu es sur la même origine, mais contrôlée par l’attaquant.
En clair : WebAuthn arrête les phishers, pas un site lui-même compromis.

Mitigation : renforcer CSP, audits XSS fréquents, SRI pour les scripts tiers, scanner automatisé des payloads XSS.

🔁 Attaques de relay / clickjacking & user gestures

WebAuthn exige souvent une interaction utilisateur. Les attaquants inventent des moyens de la simuler ou de la tromper (clickjacking, overlays, social engineering). Les techniques de relay (Evilginx-like) restent plus difficiles avec passkeys mais des variantes existent, notamment si la chaine d’attestation ou la logique serveur est faible.

Mitigation : SameSite cookies stricts, frame-ancestors CSP, protection anti-clickjacking, UI nette et non-spoofable côté OS (préférer prompts natifs).

🧠 La confiance dans le navigateur — et pourquoi c’est un problème d’infra

WebAuthn ne remplace pas la nécessité d’un navigateur sécurisé : profils sync (sauvegarde de session), extensions, ou installations de certificats racine (via clics utilisateurs) peuvent compromettre la chaîne. Si un profil Chrome/Edge est sync et compromis, l’attaquant gagne un vecteur d’accès. Les entreprises doivent considérer le navigateur comme une pièce d’infra critique à durcir.

Mitigation infra : désactiver/sécuriser le sync de profils pour comptes sensibles, contrôler GPO/MDM, forcer mises à jour et appliquer policies d’extensions.

✅ Recommandations de base côté produit & infra

• Bloquer ou limiter les extensions pour comptes sensibles.
• Désactiver WebUSB/HID si inutiles.
• Mettre CSP strict et scanner XSS en continu.
• Forcer userVerification (uv) pour opérations sensibles (exiger biométrie/PIN).
• Afficher un prompt OS-natif non spoofable pour les actions critiques (hardware auth).
• Monitorer les enrollments anormaux et les patterns d’extensions.

🔄 Interopérabilité & migration dans les environnements legacy

🏗️ Le problème de fond : l’entreprise n’est pas Google

Oui, les passkeys sont jolies quand tu as un écosystème flambant neuf et que tout ton SI tourne en SaaS moderne compatible WebAuthn. Dans la vraie vie, tu as :

• un Active Directory qui traîne depuis Windows Server 2008,
• un ERP (SAP, IBM i, AS/400) qui n’a jamais entendu parler de FIDO,
• des applis maison qui s’authentifient encore en LDAP simple bind (oui, en clair parfois),
• et des VPN SSL où on a bricolé du SAML avec des bouts de scotch.

Bref : implémenter les passkeys ne veut pas dire « appuyer sur ON ». C’est une migration progressive, avec des couches qui doivent cohabiter.

🧩 Les couches de compatibilité

1. Active Directory & Azure AD

• Azure AD (désormais Entra ID) sait gérer les passkeys nativement, intégrés à FIDO2.
• Mais ton AD on-prem ? Là, c’est du Kerberos/NTLM, pas de WebAuthn. Pour faire le pont, tu dois mettre un Identity Provider moderne (ADFS, Ping, Okta…) qui joue la traduction.
• Conséquence : le vrai login AD classique (Ctrl+Alt+Del) continuera longtemps d’exiger mot de passe ou smartcard. Les passkeys viendront surtout pour les apps web fédérées.

2. ERP & applis legacy

• SAP a introduit du support partiel (via SSO, SAML, OIDC).
• IBM i / AS400 ? Là, tu oublies WebAuthn natif. La seule option c’est un proxy d’authentification qui valide la passkey côté web et émet un ticket interne (LDAP bind, EIM, etc.).
• Pour les applis maison, il faudra patcher : ajouter un module OIDC / SAML qui sache dialoguer avec un IdP passkey-compatible.

3. VPN & accès réseau

• Beaucoup de VPN (Cisco AnyConnect, Palo Alto, Fortinet) ajoutent petit à petit du support FIDO2. Mais encore beaucoup reposent sur RADIUS + LDAP.
• La migration passe par des proxies d’authentification ou par l’ajout d’une authentification adaptative : si passkey dispo → FIDO, sinon fallback mot de passe/MFA.

🕸️ L’architecture hybride en pratique

En réalité, tu auras une cohabitation :

• Des apps modernes → authentifiées 100% passkey via IdP.
• Des systèmes legacy → authentifiées par translation (SAML/OIDC ↔ LDAP/Kerberos).
• Des comptes admin/domain controllers → encore en smartcards ou mots de passe costauds (parce que FIDO2 n’est pas partout).

Donc non, on ne devient pas « passwordless » du jour au lendemain. On vit dans un patchwork.

⚠️ Les pièges typiques

1. Double UX : l’utilisateur doit parfois se connecter avec passkey, parfois encore avec mot de passe — résultat : confusion + tickets helpdesk.
2. Fallbacks mal gérés : si tu gardes le mot de passe comme « secours » mais qu’il est faible, tu as simplement déplacé le problème.
3. Licences & coûts IdP : beaucoup d’éditeurs font payer le support passkeys/FIDO comme un module premium.
4. Sécurité de la translation : un proxy d’authentification mal configuré devient la nouvelle « clé de voûte vulnérable ».
5. Shadow IT : certains éditeurs SaaS non compatibles vont te forcer à garder les mots de passe, ce qui ruine la promesse « passwordless ».

🛠️ Bonnes pratiques pour la migration

• Cartographier les flux d’authentification actuels (AD, LDAP, SAML, OIDC, VPN, applis internes).
• Prioriser : commencer par les apps web fédérées (portail RH, CRM, SharePoint Online).
• Installer un IdP compatible FIDO2 qui sert de traducteur.
• Planifier le fallback : smartcards matérielles pour les comptes sensibles, mots de passe robustes pour les apps legacy mais sous politique renforcée.
• Former les utilisateurs : oui, il faudra encore leur dire « parfois passkey, parfois mot de passe », au moins au début.
• Surveiller : logs d’enrôlement, anomalies, et flux hybrides.

🧠 Conclusion

Le marketing « passwordless » donne envie de croire que demain matin, tu te connectes partout avec ton empreinte digitale et basta. La réalité, c’est que ton vieux SAP ou ton AS/400 n’a aucune idée de ce qu’est une passkey — et qu’un proxy mal fichu vaut un mot de passe réutilisé.
La migration est donc plus une cohabitation bordélique qu’une révolution instantanée. Les passkeys sont un outil puissant, mais elles ne font pas disparaître ton legacy d’un coup de baguette magique.

🧰 Bonnes pratiques d’implémentation (sans paillettes)

Mettre en place des passkeys, ce n’est pas un bouton magique « passwordless ». C’est un vrai chantier technique et organisationnel. Voici la checklist à avoir sous la main avant de foncer tête baissée.

🔑 Côté technique — devs & infra

• Valide tout : respecte la procédure WebAuthn complète (19 points de validation). Origin, rpId, challenge, algorithme, counters → pas d’approximation.
• N’utilise pas du code maison : prends une librairie WebAuthn éprouvée (ex. SimpleWebAuthn, WebAuthn4J, Duo-labs). Tu n’écris pas ton propre parseur CBOR à 3h du matin.
• Algorithmes stricts : impose ES256 (P-256) et refuse le reste si tu n’as pas de cas d’usage spécifique.
• Attestation policy : décide si tu acceptes none ou si tu exiges une chaîne d’attestation vérifiée. Pour les comptes sensibles, whitelist d’AAGUID + vérif via FIDO Metadata Service.
• Monitoring : logue tout (enrôlements, assertions, mismatches, counters non incrémentés). Mets des alertes SIEM sur anomalies.
• Fallback solide : pas un simple reset par helpdesk avec une question secrète. Mets une procédure MFA manuelle, une preuve physique, ou une clé matérielle alternative.

🧑‍💻 Côté utilisateurs — l’UX

• Clarté : explique simplement à quoi sert une passkey (un badge numérique qui reste dans ton appareil).
• Multiples devices : documente le fonctionnement cloud sync (Apple iCloud, Google Password Manager, MS Authenticator). Si tu l’acceptes → assume la dépendance au vendor.
• Process de perte : dis clairement « si tu perds ton téléphone, voici comment tu récupères ». Rien de pire qu’un utilisateur qui panique en croyant avoir perdu son job avec son smartphone.
• Communication : prépare des guides avec captures d’écran pour chaque OS/navigateur (sinon ton support va te haïr).

🏢 Côté organisation — l’entreprise

• Cartographie : liste toutes tes applis → lesquelles supportent WebAuthn, lesquelles sont legacy.
• Priorisation : commence par les applis SaaS fédérées (Office 365, Salesforce, CRM) → ROI rapide.
• Politiques d’accès : impose passkeys pour les comptes sensibles (admins AD, comptes cloud).
• MFA by design : la passkey est déjà une MFA (facteur device + biométrie/PIN). Mais ne l’oublie pas pour les environnements où tu gardes des mots de passe.
• Shadow IT : surveille les applis tierces non compatibles qui vont forcer les utilisateurs à garder des mots de passe.

⚠️ Les « don’t »

• ❌ Ne fais pas confiance au navigateur « par défaut » : configure CSP, bloque les extensions, durcis le poste client.
• ❌ Ne pense pas que les passkeys suppriment tous les risques → elles réduisent phishing & vol de mots de passe, pas la compromission du navigateur ni la corruption du serveur.
• ❌ Ne garde pas un mot de passe faible comme « secours ». C’est comme verrouiller ta porte blindée et laisser la clé sous le paillasson.
• ❌ N’ignore pas la gouvernance PKI → un magasin de certificats compromis annule tout le gain de sécurité.

✅ Résumé (utile)

Tu veux être « passwordless » ? Parfait. Mais sois prêt à :

1. Gérer une PKI et un IdP comme si ta vie en dépendait (parce que c’est un peu le cas).
2. Former tes utilisateurs pour éviter qu’ils fassent n’importe quoi.
3. Accepter qu’un monde hybride passkeys + legacy va durer longtemps.
4. Répondre à un incident PKI en mode pompier (et avoir un plan écrit, pas sur un post-it).

🕷️ Cas concret : attaque navigateur + WebAuthn (XSS et extension malveillante)

🎭 Le décor

Imaginons une entreprise qui déploie fièrement les passkeys pour son portail RH. Tout est conforme : challenge signé, clé privée dans le TPM, origin check nickel.
Mais… le navigateur des utilisateurs est Chrome/Edge avec :

• des extensions non contrôlées (ex. « gestionnaire de PDF » un peu louche),
• un portail RH codé vite-fait avec une faille XSS stockée (un champ « commentaire » non filtré).

🧩 Étape 1 : l’injection XSS

Un attaquant dépose un script malveillant dans le champ commentaire du portail RH. Lorsqu’un utilisateur légitime ouvre la page, le script s’exécute dans le même origin que le portail (https://rh.entreprise.com).

• Du coup, le script peut appeler directement navigator.credentials.get() pour lancer un flux WebAuthn.
• Le navigateur ne voit aucun problème : origin valide, challenge renvoyé par le serveur, tout semble légitime.

🧩 Étape 2 : manipulation DOM et UX

Le script affiche un faux pop-up (« Votre session a expiré, reconnectez-vous »).
L’utilisateur clique, le navigateur demande la validation biométrique (empreinte, FaceID). L’utilisateur valide sans se poser de questions.
Résultat : l’attaquant récupère une assertion signée valide, qui peut être relayée vers son propre serveur (attaque de type credential relay).

🧩 Étape 3 : extension malveillante (option bonus)

Une extension installée par l’utilisateur (après avoir cliqué sur un joli bouton « installer ») peut aussi :

• Intercepter ou modifier les réponses du serveur.
• Injecter son propre JavaScript sur toutes les pages RH.
• Forcer l’appel à navigator.credentials.create() pour enregistrer une nouvelle clé publique sous contrôle de l’attaquant (si la logique serveur est trop laxiste sur l’attestation).

🎯 Résultat

• L’attaquant a un accès utilisateur légitime, validé par WebAuthn.
• Le système a fait tout ce qu’il fallait, mais la faille venait du navigateur (XSS, extensions) et du site vulnérable.
• La promesse « phishing-resistant » des passkeys est tenue… sauf que ça n’empêche pas le compromis côté clientou le code malicieux dans ton propre site.

🔧 Mitigation (ou comment éviter de se faire avoir)

• Durcissement appli web : CSP strict, nettoyage des entrées, XSS scanner, SRI sur scripts tiers.
• Durcissement navigateur : bloquer les extensions non approuvées (GPO/MDM), désactiver WebUSB/WebHID si inutile.
• UX anti-spoofing : préférer prompts natifs (Windows Hello, TouchID) qui s’affichent hors DOM, limitant les faux popups.
• Monitoring : surveiller les enregistrements inattendus (navigator.credentials.create()), origins, et flux de relai.

💡 Morale piquante

Une passkey ne t’immunise pas contre ton propre JavaScript pourri ni contre une extension que ton utilisateur a installée après avoir cliqué sur « Recevoir mes horoscopes quotidiens ».
En bref : tu ne peux pas te cacher derrière WebAuthn si ton site est une passoire XSS ou si tu laisses tes navigateurs en mode « Far West ».

🤨 Conclusion — « T’es vraiment sûr, on y va ? »

Alors, les passkeys, c’est la fin des mots de passe ? Oui… et non.

• Oui, parce que tu réduis drastiquement le phishing et le credential stuffing (adieu les « azerty123 » recyclés sur 12 sites).
• Oui, parce que le support IT va moins se taper de tickets « j’ai oublié mon mot de passe ».
• Oui, parce que c’est plus fluide pour l’utilisateur final (un clic, une empreinte, basta).

Mais.

• Non, ça ne supprime pas le problème des applis legacy qui vivent encore en LDAP simple bind.
• Non, ça ne protège pas ton infra si ton magasin de certificats ou ta PKI est compromis.
• Non, ça n’empêche pas un XSS bien placé ou une extension malveillante de détourner le flow côté navigateur.
• Non, ça ne t’exonère pas de gouvernance : politique claire, procédures de réenrôlement, plan IR testé.

En fait, les passkeys ne sont pas le Saint-Graal du “passwordless”, mais plutôt une évolution sérieuse du MFA. Elles résolvent un paquet de problèmes, mais elles en introduisent de nouveaux : dépendance aux géants du cloud pour la synchro, complexité d’intégration dans ton SI legacy, gestion des fallback, et nécessité de durcir ton navigateur et ton code applicatif.

🎯 Le mot de la fin

Adopter les passkeys, c’est comme passer d’un cadenas en plastique à une serrure électronique biométrique : oui, c’est plus costaud, mais si tu laisses la fenêtre ouverte (XSS, PKI mal gérée, utilisateurs crédules), tu invites quand même le cambrioleur à entrer.

Alors, t’es vraiment sûr d’être « passwordless » ? Ou tu viens juste d’acheter une nouvelle illusion de sécurité qui fera joli dans le rapport annuel ?

ANNEXES

Playbook IR : Compromission du magasin d’attestation (PKI / CA / FIDO metadata)

Isoler rapidement l’impact, identifier l’étendue (services / credentials affectés), empêcher l’utilisation frauduleuse d’attestations malveillantes, restaurer la confiance et ré-enrôler de façon contrôlée.

1) Activation & premières minutes (0–60 min)

Actions immédiates (qui, quoi) :

• Qui : SOC lead / on-call IR lead (R), Head of Security (A), Infra ops, App owners, Legal, Comms (I/C).
• Objectif : arrêter l’hémorragie, collecter preuves immuables, préserver la chaîne de custody.

Tâches urgentes :

1. Isoler le(s) service(s) affecté(s) : mettre en mode maintenance / disable enrollment endpoints API publiques (e.g., /webauthn/register, /webauthn/assert).
2. Activer journalisation complète (if not already): augmenter verbosité des logs WebAuthn, reverse proxies (NGINX/ALB), WAF, IdP/SSO logs.
3. Collecter artefacts immuables : exporter snapshots des bases WebAuthn (credentialId, public key, attestationObject, aaguid, attestation cert chain, signatureCounter), export DB backups, capture memory on key servers if possible.
4. Prendre images des serveurs/VMs et verrouiller accès administratif (change admin creds, block malicious sessions).
5. Notifier legal / conformité si données à caractère personnel potentiellement impactées.

2) Investigation rapide (60–240 min)

Objectifs : confirmer compromission, scope, vecteur (CA private key leak, metadata poisoning, social install of root certs).

Checks techniques rapides :

• Inspecter attestations récemment acceptées : rechercher patterns (même issuer serial, mêmes AAGUIDs, même subject CN).
• Vérifier FIDO MDS / metadata updates : timestamp/manifest récents — anomalies de signature.
• Vérifier PKI / CA logs : accès aux HSM, opérations de signing inhabituelles.
• Vérifier endpoints de provisioning : IPs clients, user agents, origins liés aux nouveaux enregistrements.

Requêtes SIEM / Splunk (exemples) :

• Splunk (pseudo) : index=webauthn sourcetype=registration | stats count by aaguid, attestation_cert_serial | where count > 10
• ELK/Kibana (pseudo) : POST /webauthn/_search { "query": { "bool": { "must": [{"match":{"event":"register"}}, {"range":{"@timestamp":{"gte":"now-1h"}}}]}}}
• Counter anomalies : index=webauthn event=assertion | timechart span=1h count by signatureCounter → alerte si pattern non-incrémental.

Forensics (Windows/Linux):

• Windows: lister certificats racine utilisateur/local : certutil -viewstore -user Root / certutil -store My ; supprimer certificat racine malveillant : certutil -delstore Root "<SerialNumber>".
• PowerShell: Get-ChildItem Cert:\LocalMachine\Root | Where-Object {$_.Thumbprint -eq "<thumbprint>"}
• Linux: vérifier /etc/ssl/certs, openssl x509 -in cert.pem -noout -text pour inspecter CN/SNs.
• DB dump: mysqldump --single-transaction --skip-lock-tables webauthn_db > dump.sql (preserve immutability, hash the dump).
• Capture HTTP transactions (reverse-proxy logs): extract origins, user-agents, IPs.

3) Containment (4–24 h)

But : neutraliser l’usage des attestations compromises.

Actions techniques :

• Blacklister AAGUIDs / attestation cert serials dans ta DB d’enrôlements et dans la validation : toute assertion provenant d’une credential avec ces AAGUID/serial → reject.
• Désactiver l’acceptation d’attestations signées par la CA compromise (update validate-attestation logic).
• Forcer rejection des nouveaux enregistrements: fermer endpoint register public, autoriser uniquement via change control pour le réenrôlement contrôlé.
• Bloquer synchronisation vendor-cloud (si enterprise utilise Apple/Google passkey sync) en informant les fournisseurs si nécessaire.
• Appliquer GPO / MDM pour empêcher l’installation de certificats racine par utilisateurs.

Opérations légères :

• Rotation des credentials d’administration applicatifs qui ont pu être exposés.
• Patch immédiat si tampering trouvé sur serveur d’enrôlement.

4) Eradication & remediation (24h–7 jours)

• Révoquer / marquer invalides les credentials identifiés : set status=revoked in DB, invalidate sessions.
• Roll-back / reissue : si CA compromise → révoquer CA cert + publier CRL/OCSP, générer CA propre dans HSM, mise à jour de toute la chaine.
• Nettoyer endpoints, corriger vulnérabilités qui ont permis compromission (accès non MFA, ports ouverts, scripts non durcis).
• Auditer MDS : vérifier metadata authenticity; faire incident report to FIDO Alliance if metadata poisoned.
• Forensically analyse HSM logs; si fuite de key material confirmée, plan de remplacement total.

5) Recovery & re-enrollment (J+3 → J+30)

Objectif : restaurer accès légitime, minimiser friction.

Processus recommandé :

1. Communiquer (voir templates ci-dessous) aux utilisateurs affectés : expliquer mesures, pas de panique, procédure de ré-enrôlement.
2. Ré-enrôlement contrôlé :
   • Step 1 : administratively verify user identity (MFA + helpdesk validation).
   • Step 2 : issue temporary fallback (time-limited OOB code) or require physical key (YubiKey) for high privilege.
   • Step 3 : call navigator.credentials.create() only after verification. Log everything.
3. Revoke old credentials en batch.
4. Offer hardware keys for critical users (ops, admins): policy to require U2F/YubiKey for privileged accounts.
5. Post-recovery monitoring: heightened monitoring 30 days, watch counters and enrollment patterns.

6) Communication — templates (rapide & efficace)

Internal (short) — to Execs:

Objet : Incident sécurité — compromission magasin attestations (passkeys) — action et impact
Résumé : Nous confirmons une compromission affectant la chaîne d’attestation utilisée pour les passkeys. Actions immédiates : endpoints d’enrôlement fermés, blacklist AAGUIDs, révo des credentials suspects. Impact : possibilité de sessions frauduleuses limitée. Nous travaillons le containment, l’éradication et la notification. Détails et next steps suivront.

User-facing (concise):

Objet : Sécurité — procédure de ré-enrôlement passkey
Contenu : Nous avons détecté une anomalie technique liée au système d’enrôlement des passkeys. Par mesure de précaution, certains accès vont être temporairement réinitialisés. Vous recevrez un email avec instructions pour vous ré-enregistrer. Nous n’avons pas de preuve de compromission directe de comptes individuels <ou préciser si oui>. Merci de suivre les instructions.

Legal / regulators: prepare timeline + data scope; include forensic artifacts hash.

7) Monitoring & détection post-incident (alerts à déployer)

• Alarme : New registrations from same attestation cert serial > N/hour
• Alarme : signatureCounter decrease or no-increment
• Alarme : Origin mismatch during registration
• Alarme : Spike in DB writes to credentials table
• Alarme : New attestation format fmt not in whitelist

8) Rôles & responsabilités (RACI bref)

• R : SOC (detection), IR lead (orchestration), App owner (closure)
• A : Head of Security
• C : Legal, Comms, Vendor support (Yubico / FIDO)
• I : Execs, affected user groups

9) Post-mortem & actions long terme (30–90 jours)

• Rotate PKI, force metadata re-validation, mandate hardware keys pour admins, update runbooks, run TTX (table-top exercises) sur CA compromise, renforcer governance FIDO MDS, GPO pour cert installation.

Annexes techniques utiles

Commands / snippets (concise)

• Export webauthn table (MySQL):
  mysqldump -u root -p webauthn_db credentials > webauthn_credentials.sql && sha256sum webauthn_credentials.sql
• Inspect cert (OpenSSL):
  openssl x509 -in attestation_cert.pem -noout -text
• Delete Windows cert by thumbprint:
  certutil -delstore Root "THUMBPRINT"
• Example Splunk:
  index=webauthn sourcetype=webauthn_register | stats count by att_cert_serial, aaguid | where count>5

Conclusion — la morale amère

Tant que tu dépends d’une chaîne d’attestation, tu dois gérer la PKI comme un bijou : HSM, rotation, monitoring, et playbooks testés. Les passkeys ferment de grandes portes aux attaques classiques, mais si tu laisses la cave (PKI/metadata) ouverte, un attaquant rentre par la cheminée.

🎉 Cadeau : script PowerShell pour détecter et lister certificats racine récemment installés sur un parc.

<#
PowerShell script — Detecter et lister les certificats racine récemment installés sur un parc

Fonctions:
 - Get-RootCertificates      : liste les certificats des stores Root (LocalMachine + CurrentUser) pour un hôte
 - Save-CertsBaseline       : enregistre un baseline CSV pour comparaison ultérieure
 - Compare-CertsBaseline    : compare l'état courant à un baseline et retourne les certificates ajoutés/supprimés
 - Find-RecentCerts         : heuristique qui retourne les certificats dont NotBefore est dans les X derniers jours
 - Collect-FromHosts        : collecte les certificats depuis plusieurs machines via Invoke-Command (WinRM)

Limitations importantes:
 - Windows ne stocke pas un "install timestamp" explicite pour un certificat dans le store. Nous utilisons deux approches:
   1) comparaison par baseline (fiable si vous avez une baseline antérieure)
   2) heuristique sur le champ NotBefore (indique la date de validité, pas la date d'installation — utile comme indice)
 - Pour inventaire à l'échelle, activez WinRM / PSRemoting et exécutez Collect-FromHosts avec des comptes ayant droits d'administration.

Usage exemple (local):
  # créer un baseline
  Save-CertsBaseline -FilePath "C:\temp\certs_baseline.csv" -IncludeCurrentUser:$false

  # vérifier les changements depuis le baseline
  Compare-CertsBaseline -FilePath "C:\temp\certs_baseline.csv" -IncludeCurrentUser:$false

  # trouver les certs avec NotBefore dans les 30 derniers jours
  Find-RecentCerts -Days 30 -IncludeCurrentUser:$false

Usage exemple (parc):
  $hosts = @('host1','host2')
  $cred = Get-Credential
  Collect-FromHosts -ComputerNames $hosts -Credential $cred -OutputDir "C:\temp\webauthn_inventory"

#>

function Get-RootCertificates {
    [CmdletBinding()]
    param(
        [Parameter()]
        [bool]$IncludeCurrentUser = $true
    )

    $results = @()

    # LocalMachine Root
    try {
        $lm = Get-ChildItem -Path Cert:\LocalMachine\Root -ErrorAction Stop
        foreach ($c in $lm) {
            $results += [PSCustomObject]@{
                Store        = 'LocalMachine\\Root'
                Thumbprint   = $c.Thumbprint
                Subject      = $c.Subject
                Issuer       = $c.Issuer
                NotBefore    = $c.NotBefore
                NotAfter     = $c.NotAfter
                HasPrivateKey= $c.HasPrivateKey
                FriendlyName = $c.FriendlyName
                SerialNumber = $c.SerialNumber
                SignatureAlgorithm = $c.SignatureAlgorithm.FriendlyName
                RawDataHash  = ([System.BitConverter]::ToString(($c.GetCertHash()))).Replace('-','')
                ExportedAt   = (Get-Date)
            }
        }
    }
    catch {
        Write-Warning "Impossible d'énumérer Cert:\LocalMachine\Root - $_"
    }

    if ($IncludeCurrentUser) {
        try {
            $cu = Get-ChildItem -Path Cert:\CurrentUser\Root -ErrorAction Stop
            foreach ($c in $cu) {
                $results += [PSCustomObject]@{
                    Store        = 'CurrentUser\\Root'
                    Thumbprint   = $c.Thumbprint
                    Subject      = $c.Subject
                    Issuer       = $c.Issuer
                    NotBefore    = $c.NotBefore
                    NotAfter     = $c.NotAfter
                    HasPrivateKey= $c.HasPrivateKey
                    FriendlyName = $c.FriendlyName
                    SerialNumber = $c.SerialNumber
                    SignatureAlgorithm = $c.SignatureAlgorithm.FriendlyName
                    RawDataHash  = ([System.BitConverter]::ToString(($c.GetCertHash()))).Replace('-','')
                    ExportedAt   = (Get-Date)
                }
            }
        }
        catch {
            Write-Warning "Impossible d'énumérer Cert:\CurrentUser\Root - $_"
        }
    }

    return $results
}

function Save-CertsBaseline {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true)]
        [string]$FilePath,
        [bool]$IncludeCurrentUser = $true
    )

    $data = Get-RootCertificates -IncludeCurrentUser:$IncludeCurrentUser
    $data | Select-Object Store, Thumbprint, Subject, Issuer, NotBefore, NotAfter, HasPrivateKey, FriendlyName, SerialNumber, SignatureAlgorithm, RawDataHash, ExportedAt |
        Export-Csv -Path $FilePath -NoTypeInformation -Encoding UTF8

    Write-Host "Baseline saved to $FilePath" -ForegroundColor Green
}

function Compare-CertsBaseline {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true)]
        [string]$FilePath,
        [bool]$IncludeCurrentUser = $true
    )

    if (-not (Test-Path $FilePath)) { throw "Baseline file not found: $FilePath" }

    $baseline = Import-Csv -Path $FilePath
    $current  = Get-RootCertificates -IncludeCurrentUser:$IncludeCurrentUser

    # Nouveaux certificats = présents dans current mais pas dans baseline (par Thumbprint)
    $new = $current | Where-Object { -not ($baseline.Thumbprint -contains $_.Thumbprint) }

    # Certificats supprimés = présents dans baseline mais pas dans current
    $removed = $baseline | Where-Object { -not ($current.Thumbprint -contains $_.Thumbprint) }

    $report = [PSCustomObject]@{
        GeneratedAt = (Get-Date)
        NewCerts    = $new
        RemovedCerts= $removed
        BaselineFile = (Get-Item $FilePath).FullName
    }

    # Affichage confort
    if ($new.Count -gt 0) {
        Write-Host "Nouveaux certificats détectés : $($new.Count)" -ForegroundColor Yellow
        $new | Format-Table Thumbprint, Subject, Issuer, NotBefore, Store -AutoSize
    } else { Write-Host "Aucun nouveau certificat détecté." -ForegroundColor Green }

    if ($removed.Count -gt 0) {
        Write-Host "Certificats retirés depuis le baseline : $($removed.Count)" -ForegroundColor Magenta
        $removed | Format-Table Thumbprint, Subject, Issuer, NotBefore, Store -AutoSize
    }

    return $report
}

function Find-RecentCerts {
    [CmdletBinding()]
    param(
        [int]$Days = 30,
        [bool]$IncludeCurrentUser = $true
    )

    $cutoff = (Get-Date).AddDays(-1 * [int]$Days)
    $current = Get-RootCertificates -IncludeCurrentUser:$IncludeCurrentUser

    # Heuristique : NotBefore récent
    $recentByNotBefore = $current | Where-Object { $_.NotBefore -ge $cutoff }

    # Heuristique alternative : certs dont ExportedAt récent (utile si baseline non dispos)
    $recentByExport = $current | Where-Object { $_.ExportedAt -ge $cutoff }

    return [PSCustomObject]@{
        Cutoff = $cutoff
        RecentByNotBefore = $recentByNotBefore
        RecentByExport    = $recentByExport
    }
}

function Collect-FromHosts {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true)]
        [string[]]$ComputerNames,
        [Parameter(Mandatory=$true)]
        [System.Management.Automation.PSCredential]$Credential,
        [Parameter(Mandatory=$true)]
        [string]$OutputDir,
        [bool]$IncludeCurrentUser = $false
    )

    if (-not (Test-Path $OutputDir)) { New-Item -Path $OutputDir -ItemType Directory | Out-Null }

    $scriptBlock = {
        param($IncludeCurrentUser)
        # retourner la table de certificats simplifiée
        $res = @()
        try { $lm = Get-ChildItem -Path Cert:\LocalMachine\Root -ErrorAction Stop } catch {$lm = @()}
        foreach ($c in $lm) {
            $res += [PSCustomObject]@{
                Host = $env:COMPUTERNAME
                Store = 'LocalMachine\\Root'
                Thumbprint = $c.Thumbprint
                Subject = $c.Subject
                Issuer = $c.Issuer
                NotBefore = $c.NotBefore
                NotAfter = $c.NotAfter
                FriendlyName = $c.FriendlyName
                SerialNumber = $c.SerialNumber
            }
        }
        if ($IncludeCurrentUser) {
            try { $cu = Get-ChildItem -Path Cert:\CurrentUser\Root -ErrorAction Stop } catch {$cu = @()}
            foreach ($c in $cu) {
                $res += [PSCustomObject]@{
                    Host = $env:COMPUTERNAME
                    Store = 'CurrentUser\\Root'
                    Thumbprint = $c.Thumbprint
                    Subject = $c.Subject
                    Issuer = $c.Issuer
                    NotBefore = $c.NotBefore
                    NotAfter = $c.NotAfter
                    FriendlyName = $c.FriendlyName
                    SerialNumber = $c.SerialNumber
                }
            }
        }
        return $res
    }

    foreach ($host in $ComputerNames) {
        Write-Host "Collecte depuis $host ..." -ForegroundColor Cyan
        try {
            $out = Invoke-Command -ComputerName $host -Credential $Credential -ScriptBlock $scriptBlock -ArgumentList $IncludeCurrentUser -ErrorAction Stop
            $file = Join-Path $OutputDir "certs_$host.csv"
            $out | Export-Csv -Path $file -NoTypeInformation -Encoding UTF8
            Write-Host "Exporté: $file" -ForegroundColor Green
        }
        catch {
            Write-Warning "Échec collection depuis $host : $_"
        }
    }
}

# Helper: suppression (manuelle & prudente) d'un certificat racine sur la machine locale
function Remove-RootCertificate {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true)]
        [string]$Thumbprint,
        [ValidateSet('LocalMachine','CurrentUser')]
        [string]$StoreLocation = 'LocalMachine'
    )

    $storePath = "Cert:\$StoreLocation\Root"
    try {
        $c = Get-ChildItem -Path $storePath | Where-Object { $_.Thumbprint -eq $Thumbprint }
        if ($null -eq $c) { Write-Warning "Certificat $Thumbprint introuvable dans $storePath"; return }
        Write-Host "Suppression du certificat $Thumbprint dans $storePath" -ForegroundColor Yellow
        # action destructive: ask confirmation
        Remove-Item -Path ($c.PSPath) -Confirm
    }
    catch {
        Write-Error "Erreur lors de la suppression: $_"
    }
}

<#
Exemples d'utilisation rapide:
# 1) Sauvegarder un baseline local
Save-CertsBaseline -FilePath "C:\temp\certs_baseline.csv" -IncludeCurrentUser:$false

# 2) Comparer le baseline
Compare-CertsBaseline -FilePath "C:\temp\certs_baseline.csv" -IncludeCurrentUser:$false

# 3) Chercher les certs dont NotBefore < 30 jours
Find-RecentCerts -Days 30 -IncludeCurrentUser:$false | Select-Object -ExpandProperty RecentByNotBefore | Format-Table -AutoSize

# 4) Collecter depuis 2 hôtes (WinRM requis)
$hosts = @('host1','host2')
$cred = Get-Credential
Collect-FromHosts -ComputerNames $hosts -Credential $cred -OutputDir "C:\temp\webauthn_inventory" -IncludeCurrentUser:$false

# 5) Supprimer manuellement un certificat (locale)
Remove-RootCertificate -Thumbprint "‎DEADBEEF..." -StoreLocation LocalMachine
#>

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com