Sujet : authentication
-
Tale MCP : point de terminaison de déploiement et périmètre d'organisation
Tale expose un point de terminaison MCP propre à chaque déploiement pour la connaissance et les automatisations, avec des clés d'API de type bearer et un cloisonnement par organisation. Cette référence résume les modalités de connexion et les limites de permissions telles que la documentation les décrit.
-
Bases du client Kerberos sous Linux : krb5.conf, kinit/klist/kdestroy et keytabs
Un hôte Linux utilise Kerberos via /etc/krb5.conf, un cache d'identifiants propre à chaque utilisateur ou service (géré avec kinit, klist et kdestroy) et des keytabs pour l'authentification non interactive. Le décalage d'horloge et la casse des noms de realm sont à l'origine de la plupart des erreurs rencontrées par un agent.
-
Kerberos sous Windows : klist, klist purge et setspn -L/-Q pour diagnostiquer les problèmes de SPN
Windows expose les tickets Kerberos en cache via klist et les noms de principal de service via setspn. Les SPN en double et le décalage d'horloge entre un client et un contrôleur de domaine sont les deux défaillances qui produisent le plus souvent des erreurs « impossible de s'authentifier » peu explicites, plutôt qu'un message Kerberos clair.
-
Les JSON Web Tokens : ce qui peut mal tourner et les réponses de la RFC 8725
Les JWT sont des revendications signées, pas des secrets chiffrés ; valider l'algorithme contre une liste blanche, vérifier l'émetteur, l'audience et l'expiration, garder des durées de vie courtes, ne jamais accepter « none », et se rappeler qu'un jeton sans état ne peut pas être révoqué sans une liste côté serveur.
-
Attributs de cookie : Secure, HttpOnly, SameSite, Domain, Path et le préfixe __Host-
Chaque attribut de Set-Cookie restreint où un cookie est envoyé ou qui peut le lire : Secure le limite au TLS, HttpOnly le cache aux scripts, SameSite=Strict/Lax/None régit l'envoi intersites, Domain élargit la livraison aux sous-domaines (à omettre pour un cookie limité à l'hôte), Path n'est pas une frontière de sécurité, et le préfixe __Host- fait imposer par le navigateur Secure, Path=/ et l'absence de Domain. Les cookies ne s'isolent pas par port.
-
« Permission denied (publickey) » avec SSH : l'interpréter grâce à ssh -v
Dans OpenSSH, « Permission denied (publickey) » signifie que toutes les clés proposées par le client ont été rejetées, ou qu'aucune n'a été proposée, sans préciser laquelle. L'article montre comment ssh -v désigne précisément les clés essayées et passe en revue les cas suivants : mauvais nom d'utilisateur, IdentitiesOnly, permissions d'authorized_keys côté serveur et abandon par défaut de ssh-rsa (SHA-1) depuis OpenSSH 8.8.
-
Des flux de réinitialisation de mot de passe qui ne divulguent ni comptes ni jetons
Un flux de réinitialisation est un second chemin de connexion et mérite le même soin : répondre de façon identique à toute demande, envoyer à l'adresse enregistrée un jeton à usage unique, expirant et généré aléatoirement, construire le lien à partir d'une origine fixe plutôt que de l'en-tête Host, ne rien modifier avant la présentation du jeton, et terminer en notifiant l'utilisateur et en le redirigeant vers la connexion normale.
-
Prévenir l'énumération de comptes dans les formulaires de connexion, d'inscription et de réinitialisation
Toute différence entre la réponse pour un compte existant et un compte inexistant (texte du message, statut HTTP, redirection, timing) permet à un attaquant de constituer une liste d'utilisateurs valides à attaquer. Renvoyer le même message générique et le même statut, effectuer le même travail sur les deux chemins, déplacer l'information distinctive dans un e-mail, et limiter le débit afin que les différences résiduelles ne puissent pas être échantillonnées à grande échelle.
-
Stocker les mots de passe et les clés d'API
Les mots de passe ne sont stockés que sous forme de hachages lents et salés (Argon2id, scrypt, bcrypt) ; les clés d'API à forte entropie peuvent utiliser un hachage rapide à clé ; les deux sont comparés en temps constant et ne sont jamais journalisés ni renvoyés après leur émission.
-
Les mots de passe à usage unique basés sur le temps comme second facteur
TOTP (RFC 6238) dérive un code court d'un secret partagé et du pas de temps courant ; il protège contre la réutilisation de mot de passe mais pas contre le hameçonnage en temps réel, et nécessite un stockage sûr du secret, une tolérance d'horloge et des codes de récupération.
-
Les identifiants client OAuth 2.0 pour l'accès machine à machine
Le grant client credentials permet à un service ou à un agent d'obtenir un jeton d'accès avec son propre identifiant client et son secret, sans utilisateur ; les indicateurs de scope et de ressource délimitent le jeton, et le secret doit être traité comme un mot de passe : stocké haché par le serveur et régulièrement remplacé (roté) par le client.
-
Les messages génériques de connexion et de réinitialisation réduisent-ils mesurablement la prise de contrôle de comptes, alors que les corpus de fuites révèlent déjà quelles adresses existent ?
Question ouverte : les recommandations demandent des réponses indiscernables pour les comptes existants et inexistants, au prix d'un coût réel d'utilisabilité ; un service a-t-il mesuré si le credential stuffing ou l'hameçonnage ciblé le visant a diminué après la fermeture de l'énumération, alors que les attaquants disposent déjà de listes d'adresses issues de fuites d'autres sites ?
-
Notions de base de la gestion des sessions pour les applications web
Les identifiants de session doivent être aléatoires, longs, portés par un cookie doté des attributs Secure/HttpOnly/SameSite, régénérés à la connexion, expirés côté serveur et révocables ; l'état doit être stocké côté serveur ou dans des jetons signés à courte durée de vie.
-
Verrouillage de compte et qualité des mots de passe sous Linux avec pam_faillock et pwquality
pam_faillock verrouille un compte après plusieurs échecs de connexion, et la commande faillock permet d'inspecter ou d'effacer cet état ; pam_pwquality applique les règles de robustesse des mots de passe définies dans pwquality.conf. Les deux s'intègrent à PAM via authselect sur la famille RHEL et via pam-auth-update sur Debian/Ubuntu, et non en modifiant directement la pile PAM à la main.
-
Clés d'API ou OAuth pour les intégrations tierces
Une clé d'API identifie une application appelante et convient aux intégrateurs côté serveur agissant pour leur propre compte ; OAuth 2.0 est nécessaire lorsqu'un tiers agit pour le compte d'un utilisateur, car il offre un accès délimité par portée (scope), révocable et propre à chaque tiers, sans partager les identifiants de l'utilisateur. De nombreuses API ont besoin des deux.
-
Codes de récupération MFA : génération, stockage et consommation
Les codes de récupération sont des secrets à consulter (« look-up secrets ») : un petit ensemble de codes aléatoires à usage unique, délivrés lors de l'enrôlement d'un second facteur, stockés hachés comme des mots de passe, soumis à une limitation de débit, et consommés un par un. Ils constituent le recours en cas de perte du téléphone ou de la clé, si bien que leur délivrance, leur usage et leur renouvellement doivent être aussi protégés que le facteur qu'ils remplacent.
-
Connexion résistante à l'hameçonnage avec WebAuthn et les clés d'accès (passkeys)
WebAuthn authentifie au moyen d'une paire de clés publiques propre à chaque site : le navigateur ne laisse un identifiant être utilisé que par les origines relevant de l'identifiant de partie de confiance (relying party ID) pour lequel il a été enregistré, et l'authentificateur signe un défi émis par le serveur, si bien qu'un site imitateur n'obtient rien de rejouable ; les clés d'accès (passkeys) sont des identifiants WebAuthn découvrables, souvent synchronisés entre les appareils d'un utilisateur.
-
Interroger LDAP et Active Directory depuis Linux avec ldapsearch sans mot de passe en ligne de commande
ldapsearch prend en charge la liaison simple (DN et mot de passe), la liaison SASL/GSSAPI avec un ticket Kerberos existant, la pagination des résultats et StartTLS/LDAPS pour chiffrer la connexion. Les options -y et -W existent précisément pour que le mot de passe n'ait jamais à apparaître en clair comme argument de la ligne de commande.
-
Attaques temporelles et comparaison à temps constant des secrets
Une vérification d'égalité ordinaire s'arrête au premier octet différent, si bien que le temps de réponse laisse fuiter la part correcte d'un jeton ou d'un MAC deviné ; comparer les secrets avec les fonctions à temps constant fournies par la plateforme (hmac.compare_digest, crypto.timingSafeEqual, subtle.ConstantTimeCompare), garder des entrées de même longueur, et faire suivre aux utilisateurs inconnus le même chemin de code qu'aux utilisateurs connus.
-
Flux de code d'autorisation OAuth 2.0 avec PKCE pour les clients publics
Un client public (application monopage, application native ou en ligne de commande) ne peut pas garder de secret client, il lie donc chaque requête d'autorisation à un vérificateur de code à usage unique : il envoie le hachage SHA-256 comme code_challenge, et le point de terminaison de jeton ne délivre les jetons qu'à celui qui présente le vérificateur correspondant. La RFC 9700 rend PKCE obligatoire pour les clients publics et déconseille l'octroi implicite.
Lisible par machine : JSON