Chaque violation impliquant des identifiants volés a la même cause racine : les identifiants ont existé quelque part en texte clair suffisamment longtemps pour être découverts. Dans une base de données, dans une variable d’environnement, dans un fichier de journal, dans un instantané de mémoire. La fenêtre d’exposition peut durer des millisecondes ou des mois. Ce qui compte, c’est que la chaîne était présente et que quelqu’un l’a trouvée. La réponse standard consiste à améliorer la gestion des secrets : solutions de coffre-fort, politiques de rotation, accès avec privilèges minimum, stockage chiffré. Tous ces moyens réduisent la fenêtre d’exposition. Aucun ne l’élimine complètement. L’identifiant existe toujours sous une forme qui peut être extraite si le bon système est compromis au bon moment. Le modèle REX de Rialo adopte une approche différente de ce problème. Les identifiants d’authentification sont chiffrés avant soumission. À l’intérieur de l’environnement d’exécution privé, ils sont déchiffrés une seule fois, utilisés pour l’appel spécifique pour lequel ils étaient destinés, puis effacés de la mémoire. Le texte clair n’apparaît jamais sur le registre public. Même les validateurs ne peuvent pas accéder au contenu de l’environnement d’exécution pendant son fonctionnement. Ce n’est pas une amélioration marginale de la gestion des secrets. C’est un modèle de menace différent. @RialoHQ ne cherche pas à protéger un identifiant stocké contre un vol. Il élimine complètement l’identifiant stocké. On ne peut pas voler ce qui ne persiste pas. Le modèle « utiliser une fois et détruire » pour les données d’authentification sensibles est quelque chose que la sécurité Web2 tente d’approcher depuis des décennies avec des services de gestion de clés et des modules de sécurité matériels. Rialo l’implémente nativement au niveau de l’exécution.