Actions critiques : pourquoi certaines opérations redemandent vos deux appareils
Vous êtes connecté. Vous avez un rôle d'administrateur. Vous cliquez sur « retirer un membre » — et SSP vous demande de signer avec vos deux appareils, exactement comme si vous vous connectiez de zéro.
Ce n'est pas de la friction pour la friction. C'est une ligne tracée délibérément entre les opérations qu'un jeton de session devrait pouvoir autoriser et celles qu'il ne devrait pas, et le raisonnement derrière cette ligne mérite d'être compris, que vous utilisiez SSP ou non.
Les sessions servent le confort, pas les conséquences
Un jeton de session est une preuve au porteur. Quiconque le détient est vous, du point de vue du serveur. C'est précisément ce qui rend les sessions pratiques — vous vous authentifiez une fois puis agissez librement — et précisément ce qui en fait une mauvaise base pour des décisions irréversibles.
Les sessions se font voler. Par un bug de cross-site scripting, un ordinateur non verrouillé, un logiciel malveillant, une sauvegarde fuitée, ou simplement un navigateur laissé ouvert dans un bureau partagé. Le guide de gestion des sessions de l'OWASP traite le vol de session comme une condition attendue plutôt qu'un cas limite, et toute conception qui suppose le contraire est optimiste.
Pour la plupart des actions, c'est un risque acceptable, parce que la plupart des actions sont réversibles. Renommer un coffre, ajouter un observateur, ajuster un réglage de notification : si un attaquant muni d'une session volée fait cela, vous le défaites.
Certaines actions ne sont pas de cette nature. Transférer la propriété d'une organisation remet le contrôle à quelqu'un d'autre. Retirer un membre lui coupe l'accès. Supprimer une organisation est définitif. Pour celles-là, SSP exige la preuve que la personne qui agit détient encore les deux appareils à cet instant — et non qu'elle les détenait plus tôt dans la journée.
Les treize actions
Treize opérations exigent une nouvelle signature. Elles se répartissent en quatre groupes.
Contrôle de l'organisation
- Transférer la propriété
- Supprimer l'organisation
Adhésion et rôles
- Retirer un membre
- Promouvoir un membre au rang d'administrateur
- Rétrograder un administrateur
Identité du compte
- Changer l'e-mail d'entreprise
- Retirer l'e-mail d'entreprise
Cycle de vie et administration des coffres
- Archiver un coffre, et le désarchiver
- Geler un coffre, et le dégeler
- Promouvoir un administrateur de coffre, et le rétrograder
Ce qui les unit n'est pas qu'elles déplacent de l'argent — aucune ne le fait, et aucune ne le peut, puisque seuls les signataires peuvent déplacer des fonds. Ce qui les unit, c'est qu'elles changent qui pourra faire des choses ensuite. Ce sont les opérations qu'un attaquant convoiterait pour ancrer son accès, verrouiller les véritables propriétaires dehors, ou préparer discrètement un vol ultérieur.
Notez que les actions liées à l'e-mail figurent dans la liste. Changer l'e-mail d'entreprise d'un compte a l'air administratif, mais c'est le coup d'ouverture classique d'une prise de contrôle de compte : rediriger le canal de récupération, puis travailler à loisir. Exiger les deux appareils pour cela ferme cette voie.
Pourquoi le serveur écrit le défi
Le mécanisme compte autant que l'exigence, et une décision de conception fait l'essentiel du travail.
Le serveur génère le message que vous signez. Jamais le client.
Si le client composait son propre défi, un client compromis pourrait en composer un bien commode : un message décrivant une action inoffensive, signé par un utilisateur persuadé de faire quelque chose d'inoffensif, puis rejoué contre un point d'accès dangereux. Que le serveur rédige le message signifie que ce que vous signez est ce qui sera exécuté, car le serveur vérifie la signature face au message qu'il a émis et à aucun autre.
C'est le même schéma que SSP emploie pour la connexion, et le même schéma qui rend l'authentification par signature sûre en général : ne signez jamais quelque chose que vous n'avez pas reçu de la partie qui le vérifiera.
À quoi le défi est lié
Le message n'est pas un « oui » générique. C'est une chaîne précise contenant quatre éléments qui, ensemble, rendent une signature capturée inutile ailleurs.
L'action exacte. remove_member et transfer_ownership produisent des messages différents. Une signature pour l'une ne peut pas autoriser l'autre.
La cible exacte. L'organisation, le coffre le cas échéant, et la personne visée sont nommés dans le message. Les actions à portée de coffre incluent explicitement l'identifiant du coffre, de sorte qu'une signature pour geler un coffre ne puisse être rejouée pour en geler un autre.
Un horodatage. Il occupe les treize premiers caractères du message — une position fixe, car SSP Wallet valide ce format avant d'afficher quoi que ce soit. Les défis expirent au bout de quinze minutes.
Un nonce aléatoire. Douze octets d'aléa cryptographique, ce qui rend chaque défi unique même pour une action identique visant une cible identique à la même seconde.
Et le défi est à usage unique. Lorsqu'il est consommé, le serveur le marque comme utilisé dans l'opération atomique même qui le valide — une signature rejouée est donc rejetée avec « déjà utilisé » au lieu de réussir discrètement deux fois. Les défis expirés sont nettoyés automatiquement par un index TTL.
Chaque tentative est consignée, y compris les échecs
Les actions critiques sont écrites dans un journal permanent, et il y a ici un détail facile à survoler : l'entrée du journal est écrite quand le défi est demandé, et pas seulement quand l'action aboutit.
Cela signifie que le journal inclut les tentatives abandonnées, celles où la signature a échoué et celles qui ont été refusées. Une action critique en échec, isolée, c'est en général quelqu'un qui a changé d'avis. Une grappe de ces échecs à 3 h du matin, c'est une histoire.
Comme le reste de la piste d'audit de SSP, ces enregistrements n'ont ni expiration ni tâche de nettoyage. La valeur d'un journal d'audit vit entièrement dans les parties dont personne n'avait anticipé le besoin.
À quoi cela ressemble en pratique
Ayez vos deux appareils avec vous avant de commencer. Les actions critiques ne peuvent pas s'achever avec un seul appareil, et le défi expire en quinze minutes. Si votre téléphone est dans une autre pièce, allez le chercher d'abord.
Lisez l'action sur le téléphone, pas seulement sur le tableau de bord. Le message affiché par vos appareils nomme l'action et la cible. C'est votre occasion de remarquer que la cible n'est pas celle que vous attendiez — la même habitude qui vous protège lors de la vérification d'une transaction. Les attaques de phishing visant les utilisateurs de crypto explique pourquoi ce second regard sur le second appareil vaut les secondes qu'il coûte.
Ne les groupez pas. Chaque action critique obtient son propre défi et sa propre signature. Si vous retirez trois employés sur le départ, cela fait trois signatures. C'est délibéré : grouper signifierait une signature autorisant plusieurs changements, soit exactement la propriété que l'on cherche à éviter.
Attendez-vous à elles aux pires moments. Les actions critiques se concentrent précisément aux instants où quelqu'un s'en va, où un compte est compromis, où un coffre doit être gelé — c'est-à-dire aux instants où les gens sont sous tension et veulent aller vite. Savoir à l'avance qu'elles requièrent les deux appareils transforme une surprise en une étape.
Le tableau plus large de ce qui impose quoi — et pourquoi la re-signature se situe dans la couche intermédiaire plutôt que dans la plus solide — figure dans ce qui arrête vraiment une transaction. Pour l'articulation de l'organisation et de ses coffres, commencez par SSP Enterprise : des coffres multisig pour les équipes.
