Résumé

  • Dans l’instantané RIPE WHOIS de septembre 2026, ApiKeyAuthProvider copie le nom d’utilisateur Basic dans APIKeySession.keyId avant de contrôler l’absence du jeton ou d’obtenir le verdict du service de validation.
  • Le test syncupdates_gets_logged_invalid_apikeys attend un enregistrement d’audit contenant l’identifiant factice, des attributs d’identité nuls et errorStatus=Invalid APIKEY; il ne démontre ni une authentification réussie ni une mise à jour acceptée.
  • La documentation RIPE distingue l’identifiant de clé, utilisé comme nom d’utilisateur, du mot de passe affiché une seule fois. La sérialisation étudiée expose le premier, pas le second, sans pour autant certifier tous les journaux de production.
  • L’enjeu de gouvernance est de borner l’usage de cet identifiant: lecteurs autorisés, corrélation, export, durée de conservation et vérification par valeurs synthétiques.

L’échec reçoit un nom avant d’être prononcé

Le détail décisif se trouve dans l’ordre des opérations. À la révision figée 252681a0865d5a10dbcfeaeeaf81bf33ef2c3855, le fournisseur d’authentification reçoit les éléments d’un en-tête Basic. Il transmet les données présentées et le nom d’authentification vers le client chargé de valider la clé. Mais il construit d’abord une APIKeySession et y inscrit keyId(authentication.getName()).

Le verdict vient après. Si la valeur du jeton est vide, le fournisseur lève une AccessTokenValidationException portant le texte Invalid APIKEY. Le bloc de traitement de l’erreur ne jette pas la session commencée. Il tente de construire une session OAuth, puis renvoie un ApiKeyAuthenticationToken qui contient l’état d’échec. Le mot «token» dans le nom de l’objet ne signifie donc pas que l’appelant a été admis: cet objet transporte également une décision négative et son contexte.

Ce choix donne à l’échec un point d’ancrage. Le nom d’utilisateur Basic n’est pas ici un pseudonyme créé pour les besoins du journal. L’annexe RIPE consacrée aux clés API explique qu’une clé comporte deux parties. L’identifiant sert de nom d’utilisateur; le secret, montré une seule fois lors de la création, sert de mot de passe. L’interface de gestion affiche notamment le Key ID, la dernière utilisation et l’échéance, et permet la révocation. L’identifiant retenu par le code correspond donc à un objet que le titulaire peut administrer.

Cette correspondance est utile parce qu’elle rapproche un rejet de la clé qui l’a provoqué. Elle mérite aussi d’être gouvernée parce qu’un identifiant administrable est potentiellement corrélable. Il n’est pas le mot de passe à usage ultérieur, mais son absence de pouvoir d’authentification direct ne le rend pas automatiquement public. Selon les tables auxquelles un lecteur a accès, il peut révéler l’existence d’une intégration, rattacher une série d’essais au même compte ou faciliter une recherche dans l’outil de gestion.

Le test décrit la forme, pas l’exploitation réelle

La preuve la plus forte est le test d’intégration. syncupdates_gets_logged_invalid_apikeys envoie une requête POST à un point de terminaison Syncupdates de test avec une authentification Basic et une clé factice inexistante. La chaîne XML attendue pour l’audit contient le keyId factice, des valeurs nulles pour les attributs de l’utilisateur et errorStatus=Invalid APIKEY. Les cas voisins rendent la distinction explicite: une clé valide produit des éléments d’identité et de portée, alors que les cas expiré et invalide gardent l’identifiant et un état d’erreur.

Ce n’est donc pas seulement une lecture plausible du chemin de code. La persistance du key ID dans la représentation testée constitue un comportement attendu. L’opérateur obtient un moyen de séparer, par exemple, une automatisation oubliée qui continue d’utiliser une clé révoquée d’une hausse générale d’erreurs d’authentification. L’assistance peut rechercher la clé concernée; la sécurité peut rapprocher des tentatives répétées; le propriétaire peut décider de supprimer ou de remplacer l’intégration.

La représentation a cependant une frontière nette. APIKeySession.toString() énumère aud, keyId, email, uuid, scopes, azp, jti et errorStatus. OAuthCredential enveloppe la session offerte et, dans la forme étudiée, imprime cette session. Aucun champ nommé mot de passe ou jeton d’accès n’apparaît dans ces deux sérialisations. Cette absence est un élément positif, mais elle ne vaut que pour cette surface. Elle ne prouve pas ce que peuvent capter un mandataire inverse, un traçage d’exception, le client de validation, la plate-forme d’hébergement ou une configuration de journal distincte.

Les données du test sont également des fixtures. Elles ne sont ni des identifiants réels ni des fiches d’abonné. L’intégration n’observe aucun fichier de journal en production, ne mesure aucune durée de conservation et ne recense pas les personnes pouvant effectuer une recherche. Elle ne dit rien des exports, des sauvegardes, des tickets d’assistance ou des règles de suppression. Enfin, le dépôt permet de connaître le code source figé et le commit de changement 0ad411c9f4cb4ba0c278142f8bbf886bb9c0a89c, pas le commit réellement déployé ni le pourcentage d’un éventuel déploiement.

L’identifiant minimal est une décision d’architecture

Deux défauts symétriques menacent un journal d’authentification. S’il efface tout contexte, les échecs deviennent interchangeables et l’enquête perd sa granularité. S’il conserve la valeur complète présentée par le client, il transforme un outil d’observation en dépôt de secrets. Le chemin étudié retient un identifiant de corrélation et, dans la sérialisation démontrée, laisse de côté le secret porteur.

Cette séparation rejoint le principe défendu par le guide de journalisation OWASP: enregistrer les succès et les échecs d’authentification, sans inscrire directement mots de passe et jetons d’accès. OWASP n’a pas audité RIPE WHOIS dans ce dossier et son guide n’atteste aucune conformité. Il fournit simplement un étalon indépendant qui explique pourquoi un key ID peut avoir une valeur opérationnelle alors que le mot de passe doit rester hors du flux de journalisation.

La valeur de corrélation ne doit pas devenir une identité de personne par raccourci. Un key ID peut renvoyer à une entrée du service de gestion, mais l’association à un compte ou à un utilisateur dépend d’autres données. Les chaînes factices ne démontrent ni unicité mondiale, ni entropie, ni confidentialité. Aucun essai de force brute, aucune compromission et aucun incident client n’a été observé. Le test ne couvre pas non plus les en-têtes Basic mal formés, l’absence de nom, les doublons ou tous les chemins de mise à jour.

Il serait tout aussi erroné de décrire ce changement comme la correction d’une vulnérabilité. Le journal des changements mentionne à proximité une meilleure résilience lorsque l’arrière-plan de validation est en panne ainsi que de la journalisation, mais il ne transforme pas l’observation en avis de sécurité. L’élément établi est plus sobre: un chemin de rejet conserve volontairement le key ID dans la forme d’audit attendue.

Vérifier le contrat sans risquer un secret

Une équipe d’exploitation peut commencer par une clé synthétique créée dans un environnement autorisé. Elle note son identifiant, la révoque ou invalide son secret, puis effectue une requête non destructive sur l’interface couverte. Le résultat attendu comporte trois assertions séparées: refus de la requête, présence du key ID synthétique avec un état invalide, absence du mot de passe et de l’en-tête Basic complet. Il faut vérifier en parallèle qu’aucun objet du registre n’a changé.

La deuxième vérification concerne le trajet après l’écriture. Qui peut rechercher par key ID? La valeur est-elle copiée dans un SIEM, une sauvegarde ou un ticket? Les règles de conservation sont-elles identiques dans les différentes destinations? La fermeture d’un compte ou la suppression d’une clé atteint-elle les copies secondaires? Le code du fournisseur ne peut répondre à ces questions; ce sont des choix de plate-forme et d’organisation.

La troisième vérification porte sur la qualité du diagnostic. Une clé expirée, un identifiant inconnu, un mauvais mot de passe pour une clé existante et l’indisponibilité du service de validation appellent des réponses différentes. Les tests voisins donnent quelques états, mais ils ne démontrent pas la taxonomie complète des alertes. Une panne de validation classée comme une simple clé invalide peut envoyer l’équipe sur une fausse piste; à l’inverse, chaque faute de frappe ne doit pas déclencher un incident majeur.

Enfin, l’équipe doit écrire la finalité du key ID dans l’audit. L’usage pour la révocation et le diagnostic est défendable. Sa transformation silencieuse en clé universelle de recherche de compte l’est beaucoup moins. Le bon contrat n’est pas «tout garder au cas où», mais conserver le minimum utile, limiter ses lecteurs et prouver périodiquement la frontière à l’aide de valeurs synthétiques.

Le dossier d’enquête devrait également formuler ce que la corrélation ne prouve pas. Retrouver le même key ID dans deux événements n’établit ni que la clé a déjà été valide, ni que son titulaire légitime a émis la requête, ni même que le client est identique. Le journal rapproche une valeur déclarée, pas un auteur. Une attribution plus forte exige des éléments séparés et autorisés: horodatage, réseau source, version du client et correspondance dans le service de gestion. Cette discipline évite qu’un index commode soit présenté comme une preuve d’identité.

Une revue périodique peut enfin chercher les consommateurs devenus inutiles. Une équipe ayant demandé le champ pour une migration ponctuelle n’a pas nécessairement besoin de le lire deux ans plus tard. Retirer l’accès et arrêter les copies obsolètes sont des mesures de minimisation aussi importantes que le choix initial de ne pas sérialiser la clé secrète.

Sources

  1. RIPE NCC, commit 0ad411c9: https://github.com/RIPE-NCC/whois/commit/0ad411c9f4cb4ba0c278142f8bbf886bb9c0a89c
  2. RIPE NCC, ApiKeyAuthProvider.java: https://github.com/RIPE-NCC/whois/blob/252681a0865d5a10dbcfeaeeaf81bf33ef2c3855/whois-api/src/main/java/net/ripe/db/whois/api/security/auth/provider/ApiKeyAuthProvider.java
  3. RIPE NCC, APIKeySession.java: https://github.com/RIPE-NCC/whois/blob/252681a0865d5a10dbcfeaeeaf81bf33ef2c3855/whois-commons/src/main/java/net/ripe/db/whois/common/oauth/APIKeySession.java
  4. RIPE NCC, OAuthCredential.java: https://github.com/RIPE-NCC/whois/blob/252681a0865d5a10dbcfeaeeaf81bf33ef2c3855/whois-commons/src/main/java/net/ripe/db/whois/common/credentials/OAuthCredential.java
  5. RIPE NCC, test d’audit et de mise à jour: https://github.com/RIPE-NCC/whois/blob/252681a0865d5a10dbcfeaeeaf81bf33ef2c3855/whois-api/src/test/java/net/ripe/db/whois/api/log/UpdateAndAuditLogTestIntegration.java
  6. RIPE NCC, journal des changements: https://github.com/RIPE-NCC/whois/blob/252681a0865d5a10dbcfeaeeaf81bf33ef2c3855/changes.txt
  7. Documentation RIPE Database, clés API: https://docs.db.ripe.net/Appendices/Appendix-K--API-Keys
  8. Documentation RIPE Database, API REST: https://docs.db.ripe.net/Update-Methods/RESTful-API
  9. Documentation RIPE Database, modèle d’autorisation: https://docs.db.ripe.net/Authorisation/Authorisation-Model/
  10. OWASP, guide de journalisation: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html