Sécurité

Sécurité

Chiffrement des graines, isolation par équipe, rôles, journal d’accès, protection des comptes et hébergement : ce que fait Share Auth, et ce qu’il ne fait pas.

Share Auth stocke des secrets qui ouvrent des comptes. Cette page décrit comment ils sont protégés, à chaque étape, et où s’arrête ce que l’outil peut garantir.

Les graines restent chiffrées

Une graine TOTP est chiffrée en AES-256 avant d’être enregistrée, avec une clé propre à l’application qui ne se trouve pas dans la base de données. Elle n’est déchiffrée qu’au moment de calculer un code, en mémoire, et n’est jamais renvoyée par l’API, l’extension navigateur ou le connecteur MCP : ils ne reçoivent que le code courant.

Chaque équipe est cloisonnée

Un secret appartient à une équipe. Chaque requête vérifie qu’il fait partie de l’équipe active de la personne, puis que son rôle autorise l’action demandée :

  • lecteur : consulter et copier les codes, sans voir la graine ;
  • éditeur : ajouter et modifier les secrets, et voir leur graine ;
  • administrateur : tout cela, plus la suppression et la facturation ;
  • propriétaire : tous les droits, dont les membres, la facturation et le journal d’accès.

Les limites de votre forfait s’appliquent en plus, sans jamais rien supprimer.

Chaque code communiqué est enregistré

Le journal d’accès note qui a obtenu quel code, quand et par quel canal : site, API, Slack, Discord ou Microsoft Teams, avec l’adresse IP pour le site et l’API. Il est réservé au propriétaire. Les consultations répétées d’un même secret par la même personne sont regroupées sur cinq minutes, pour qu’une page laissée ouverte ne noie pas l’historique.

Les bots de messagerie

Chaque appel d’un bot est authentifié par la signature de la plateforme (Slack, Discord ou Microsoft Teams), et le nombre de commandes par personne est limité. Seul le propriétaire peut créer une intégration, et il peut la désactiver à tout moment.

Une intégration ouvre l’accès à tout l’espace de travail connecté : la plateforme prouve d’où vient la commande, pas quel compte Share Auth la lance, et les rôles de l’équipe ne s’y appliquent donc pas. Les restrictions par canal limitent les secrets que chaque canal peut obtenir. Chaque code communiqué par un bot figure dans le journal, avec le nom déclaré par la plateforme.

Les comptes sont protégés

  • Double authentification de votre compte Share Auth par application TOTP, avec des codes de secours.
  • Sans application d’authentification, chaque nouveau navigateur doit être confirmé par e-mail, par lien ou par code. Un navigateur confirmé est reconnu pendant 30 jours.
  • Le mot de passe est redemandé avant de connecter un nouvel appareil, comme l’extension navigateur.

Les jetons d’API sont bornés

Un jeton porte les permissions choisies à sa création, pas plus : un jeton qui liste et lit des codes ne peut rien modifier. Sa durée est de 1, 7, 30 ou 90 jours, il se révoque depuis votre profil, et l’API limite chaque utilisateur à 60 requêtes par minute.

Hébergement et transport

Les données sont hébergées en France. Tout passe en HTTPS, avec HSTS, et les pages de l’application qui affichent des secrets ne sont jamais mises en cache. Les détails des prestataires figurent dans la politique de confidentialité.

Ce que Share Auth ne fait pas

Share Auth partage des codes 2FA. Il ne remplace ni un gestionnaire de mots de passe ni une stratégie de gestion des identités, et il ne protège pas un compte dont le mot de passe circule déjà. Gardez la liste de vos éditeurs courte : ce sont eux qui peuvent voir les graines.

Questions fréquentes

Les éditeurs, administrateurs et propriétaires, depuis la page de modification d’un secret, pour pouvoir la déplacer ailleurs. Un lecteur ne voit que le code courant. L’API, l’extension et le connecteur MCP ne renvoient jamais la graine, quel que soit le rôle.