Question fréquemment posée

1) C’est quoi une Passkey (simplement)

Une passkey est une méthode de connexion basée sur la norme FIDO2 / WebAuthn : au lieu d’un mot de passe, l’utilisateur utilise un déverrouillage local (empreinte, FaceID, code PIN du téléphone/PC, clé FIDO type YubiKey).

Le principe clé :

• l’appareil crée une paire de clés cryptographiques (publique/privée) pour votre site (“relying party”)

• la clé privée ne quitte jamais l’appareil

• votre serveur ne stocke que la clé publique + des métadonnées

• à chaque login, le serveur envoie un challenge, l’appareil signe → le serveur vérifie avec la clé publique.

???? Donc : pas de “secret” réutilisable côté serveur comme un password.

2) Comment on les utilise (côté utilisateur)

Deux étapes typiques :

A) Enrôlement (création de passkey)

1. L’utilisateur est déjà authentifié (par OTP/mot de passe temporaire, ou session existante)

2. Il clique “Créer une passkey”

3. Le navigateur ouvre une fenêtre système (Google/Apple/Windows)

4. L’utilisateur valide (biométrie / PIN)

5. Votre serveur enregistre la clé publique + un identifiant de credential

B) Connexion (login)

1. L’utilisateur saisit son identifiant (ou email) + éventuellement société (dans votre cas)

2. Votre serveur lance une “authentication ceremony” WebAuthn

3. Le navigateur propose la bonne passkey

4. Validation biométrie/PIN

5. Signature du challenge → vérification serveur → session ouverte

3) Niveau de sécurité (pourquoi c’est fort)

Les passkeys sont généralement plus sûres qu’un mot de passe classique, pour 4 raisons :

1. Anti-phishing natif : la passkey est liée au domaine (origin). Un faux site ne peut pas “réutiliser” la passkey du vrai domaine.

2. Pas de secret volable côté serveur : même si votre base est compromise, il n’y a pas de hash de password à casser.

3. Résistance au credential stuffing : pas de mot de passe réutilisable.

4. Challenge unique : chaque authentification est un challenge différent.

En pratique, ça réduit énormément :

• phishing

• mots de passe faibles

• réutilisation de mots de passe

• fuites exploitables

4) Configuration : ce que HLI_v22 doit régler (les points importants)

Voici les choix “structurants” pour une intégration propre :

A) Relying Party (RP)

• rpId : votre domaine (ex: horus-solutions.cloud)

• origin : exact (https, hostname, port) côté front

⚠️ Erreur fréquente : mismatch rpId/origin entre environnements (test/prod, sous-domaines).

B) Discoverable vs non-discoverable

• Discoverable credentials (“username-less”) : l’utilisateur peut se connecter sans taper login (pratique)

• Non-discoverable : vous avez besoin du login pour retrouver les credentials en base

???? Dans HLI (avec société + login), le plus simple au départ est non-discoverable (vous contrôlez l’UX et le lookup), puis vous pourrez évoluer.

C) User verification

Forcer userVerification = "required" (biométrie/PIN obligatoire) : c’est un vrai plus sécurité.

D) Algorithmes

Accepter principalement ES256 (P-256) et éventuellement RS256 selon les plateformes.

E) Attestation

Souvent on met attestation = "none" (simplicité, confidentialité).
L’attestation stricte peut être utile si vous voulez imposer certains authentificateurs (ex: uniquement clés certifiées), mais c’est plus complexe à gérer.

F) Stockage en base

Stocker au minimum :

• credentialId (bytes)

• publicKey (COSE → ou format converti)

• signCount (si vous le gérez)

• usrId / structureId

• date création, dernier usage, device label (optionnel)

• état actif/révoqué

G) Politique de “recovery”

Prévoir la vie réelle :

• utilisateur change de téléphone

• perte de device

• passkey non disponible

???? Il faut un fallback : OTP fort, ou procédure admin, ou passkey secondaire.

5) Forces (avantages concrets pour HLI)

• Moins de support “mot de passe oublié”

• Connexion plus rapide et moderne

• Sécurité accrue contre phishing

• Très bon signal audit/compliance (RGPD : réduction des données sensibles type passwords)

6) Faiblesses / limites (à connaître)

A) Récupération / multi-device

• Si l’utilisateur n’a qu’une passkey sur un seul appareil et le perd : il faut fallback.

• Les passkeys “synchronisées” (cloud Apple/Google/Microsoft) sont super pratiques, mais soulèvent une question “gouvernance” chez certains clients (dépendance à un écosystème).

B) Compatibilités / environnements verrouillés

• Certaines entreprises bloquent biométrie, WebAuthn, ou ont des postes anciens.

• Certains navigateurs/OS très vieux ne supportent pas bien.

C) Implémentation

Le plus grand risque n’est pas la crypto : c’est les erreurs de configuration :

• rpId/origin incohérents

• challenge mal géré

• sessions mal attachées

• mauvais encodages base64url / bytes

• confusion multi-tenant (votre cas : société + login + base PEG puis base client)

D) Social engineering / support

Même si phishing est largement réduit, un attaquant peut viser :

• la procédure de récupération (reset / OTP)

• l’ingénierie sociale auprès du support

???? Le “weak point” devient souvent le fallback, pas la passkey.

7) Recommandation pragmatique pour votre modèle “Société + Login”

Pour HLI_v22, un schéma robuste :

1. Écran : Société + Login

2. Serveur : retrouve l’utilisateur (dans PEG), vérifie statut/actif

3. Propose :

   • Passkey (prioritaire)

   • OTP (fallback)

4. Si passkey :

   • challenge + allowCredentials liés à cet usrId

5. Si OTP :

   • OTP court + TTL + anti-bruteforce + device/IP heuristics

6. Après authent OK :

   • bascule vers la base client + création session applicative

8) Mesures “must-have” autour des passkeys

• Rate limiting sur endpoints WebAuthn + OTP

• Journalisation : création/révocation/dernier usage (audit)

• Révocation : bouton “désactiver cette passkey”

• 2 passkeys recommandées (téléphone + PC, ou + clé FIDO)

• Fallback très sécurisé (sinon vous annulez le gain sécurité)