Sécurité
Une sécurité qui a le sens de l’accueil.
Un fournisseur d’identité ne vaut que par les cloisons qui séparent ses locataires et par le soin qu’il apporte aux secrets. Voici comment Usher Identity est construit. Nous décrivons ce que fait le logiciel ; nous ne revendiquons aucune certification.
Architecture
Des domaines distincts, des réseaux distincts.
Les pages d’Usher Identity et l’émetteur de chaque client se trouvent sur des domaines enregistrables différents. Les bases de données sont sur un réseau qui ne peut pas atteindre Internet, et la seule issue est un proxy qui vérifie la destination.
- Caddy assure la terminaison TLS pour chaque hôte et supprime les en-têtes que seuls les services d’Usher Identity peuvent définir.
- La couche d’authentification répond pour chaque environnement, distingué par son hôte ; rien n’est mis en cache pour un hôte puis servi à un autre.
- Chaque service se connecte à Valkey avec son propre utilisateur, limité à ses propres clés. Il n’existe aucun utilisateur par défaut.
- Les requêtes qui contiennent des jetons et des codes ne sont jamais écrites avec leurs valeurs dans le journal de la base de données.
Internet
Les utilisateurs, vos apps, vos serveurs
La périphérie
Caddy : TLS, HSTS, suppression des en-têtes internes
usheridentity.com
Site et Console
usheridentity.com, console.usheridentity.com
API
api.usheridentity.com
*.usherid.com
Couche d’authentification
L’émetteur et le Lobby de chaque environnement
Réseau de données · aucune route vers l’extérieur
Postgres
Un schéma par environnement
Valkey
Chaque service limité à ses propres clés
La seule issue
Proxy de sortie
Pour chaque URL fournie par un client
Découverte, JWKS, déconnexion
Adresses publiques uniquement
Isolation
Rien d’important n’est partagé.
Chaque environnement de projet a son propre schéma Postgres, ses propres clés de signature et ses propres secrets, scellés avec sa propre clé de données. Son émetteur est un hôte du domaine des locataires, et ses cookies sont limités à cet hôte : un navigateur n’envoie donc jamais le cookie d’un environnement à un autre.
usheridentity.com
Le site, Usher Identity Console, les comptes Usher Identity
*.usherid.com
Un émetteur par environnement, sur un domaine distinct
Les utilisateurs, les sessions et les jetons se trouvent dans un schéma créé pour cet environnement. Les requêtes s’exécutent sur ce schéma, jamais sur une table partagée avec une colonne de locataire.
Copier le secret client Google scellé de l’environnement de production Acme vers l’environnement de production Northwind.
Chiffrement au repos
Un chiffrement par enveloppe, lié à sa place.
Les secrets que vous confiez à Usher Identity sont scellés avec AES-256-GCM sous une clé de données qui appartient à un seul environnement. Les clés de données sont elles-mêmes enveloppées par une clé maîtresse versionnée, conservée hors de la base de données.
- Des clés de données par environnement
- Compromettre la clé de données d’un environnement ne révèle rien de celle d’un autre.
- Liaison AAD
- L’environnement et la finalité sont liés à chaque texte chiffré : une valeur ne peut donc pas être déplacée d’une ligne ou d’un locataire à l’autre.
- Clés versionnées
- Chaque valeur scellée enregistre la version de la clé qui a servi à la créer : les clés peuvent ainsi être renouvelées, et les anciennes valeurs enveloppées à nouveau.
- Authentifié
- Grâce à l’étiquette d’authentification de GCM, une valeur altérée ne peut pas être ouverte, au lieu d’être déchiffrée en autre chose.
Clé maîtresse
Conservée hors de la base de données, versionnée
Clé de données, une par environnement
Enveloppée par la clé maîtresse
Le secret
Scellé avec AES-256-GCM sous la clé de données
u1.<key version>.<iv>.<ciphertext + tag>
aad = u1 | version | environment | purpose
Pratiques
Les détails, traités avec soin.
Les mots de passe, si vous les utilisez
Hachés avec Argon2id au coût recommandé par l’OWASP (19 Mio, deux passes), avec un plafond sur le nombre de calculs simultanés pour qu’un afflux de connexions ne puisse pas faire tomber le service. Les nouveaux mots de passe sont comparés aux fuites connues grâce à l’API par plages de Have I Been Pwned, qui ne voit qu’un court préfixe du hachage du mot de passe. La longueur minimale est de 12 caractères par défaut.
Rien de stocké qui puisse être rejoué
Les secrets client, les jetons, les jetons de lien magique et les codes envoyés par e-mail sont stockés sous forme hachée. Les codes de secours sont chiffrés. Un code d’autorisation est valable cinq minutes ; un code envoyé par e-mail autorise trois essais.
Des limites de débit à chaque porte
La connexion, l’inscription, les codes par e-mail, les liens magiques, les réinitialisations de mot de passe et les vérifications du second facteur ont chacun leur propre limite : par exemple, dix connexions par mot de passe par minute, et cinq codes par e-mail toutes les dix minutes.
Une Content-Security-Policy stricte
Chaque page du Lobby reçoit un nonce neuf et une politique construite autour de lui : seuls les scripts de cette origine qui portent le nonce s’exécutent, les formulaires ne sont envoyés qu’à la même origine, et les autres sites ne peuvent pas afficher la page dans un cadre.
Un journal d’audit digne de confiance
Les modifications des espaces de travail, des projets et des environnements sont écrites dans un journal en ajout seul, chaque entrée étant chaînée par hachage à la précédente : une entrée modifiée ou manquante se remarque.
Un proxy de sortie pour les URL des clients
Chaque requête qu’Usher Identity envoie à une adresse fournie par un client (découverte OIDC, JWKS, déconnexion par canal arrière) passe par un seul et même proxy. Il résout le nom une seule fois, refuse les adresses privées, de bouclage, de lien local et de métadonnées cloud, et se connecte à l’adresse qu’il a vérifiée : le DNS rebinding ne peut donc pas transformer l’URL d’un client en adresse interne.
Des identifiants jamais attribués deux fois
L’identifiant d’un environnement de production est le premier libellé de son émetteur. La Console est accessible sur invitation, un Lobby signalé pour hameçonnage est suspendu, et un identifiant déjà utilisé n’est jamais réattribué, car d’anciennes apps peuvent encore faire confiance à ses jetons.
Des sessions qui prennent fin quand vous le décidez
Usher Identity vérifie ses propres sessions à chaque requête plutôt que de se fier à une copie en cache : une session à laquelle vous mettez fin est terminée sur-le-champ. Les jetons d’accès ont une courte durée de vie (dix minutes par défaut), et votre API peut les introspecter.
Divulgation responsable
Vous avez trouvé quelque chose ? Prévenez-nous d’abord.
Si vous pensez avoir trouvé un problème de sécurité dans Usher Identity, nous aimerions en être informés, et nous travaillerons avec vous pour le corriger.
- Ce que vous avez trouvé, où, et comment le reproduire.
- Ce que quelqu’un pourrait en faire, selon vous.
- Comment vous joindre, et si vous souhaitez que votre nom soit mentionné.
Veuillez ne tester que des environnements qui vous appartiennent, ne pas accéder aux données d’autrui, et nous laisser un délai raisonnable pour corriger le problème avant de le rendre public. Pour signaler une page qui se fait passer pour une page de connexion Usher Identity, consultez Signaler un abus.