J'ai retiré l'accès et la personne est toujours dedans : une session n'est pas une permission

Vous avez retiré la permission d'un utilisateur. Peut-être avez-vous désactivé le compte entièrement. Puis vous remarquez que cette personne peut encore faire des choses.

Rien n'est cassé. Se connecter et être autorisé sont deux moments distincts, et il y a un écart entre les deux.

La connexion arrive une fois, la permission est demandée à chaque fois

Quand vous vous connectez, le système vous remet un ticket. Le ticket dit : cette personne a prouvé qui elle est, et ce ticket est valable jusqu'à telle heure.

La permission est une question à part, reposée à chaque requête. Mais en pratique, beaucoup de systèmes prennent au moment de la connexion une copie de la carte des permissions, pour la vitesse, et se servent de cette copie un certain temps.

Deux décalages en découlent.

Le premier : quand vous retirez une permission, une session ouverte peut continuer à porter cette copie. Le changement ne l'atteint qu'au renouvellement de la session.

Le second, et le plus important : supprimer ou désactiver l'utilisateur ne déchire pas le ticket qu'il tient. Le ticket se suffit à lui-même et reste valable jusqu'à son expiration.

La règle : retirer un accès n'est pas mettre fin à une session

Ce sont deux actions distinctes, et ne faire que la première laisse une fenêtre ouverte derrière vous.

La fenêtre n'est pas infinie ; un ticket n'est pas valable une journée. Mais elle n'est pas nulle non plus, et dans une situation urgente « ça va se fermer bientôt » n'est pas une réponse suffisante.

Quand quelqu'un part, ou qu'un mot de passe est suspect

Faites trois choses, dans l'ordre.

Retirez la permission. Désactivez aussi le compte si cela se justifie.

Changez le mot de passe. Cela ferme la voie qui permet d'obtenir un ticket frais pour remplacer celui qu'il détient. Retirer une permission seule ne le fait pas.

Supprimez les jetons d'accès séparément. C'est l'étape la plus souvent sautée. Un jeton n'est pas une session : il n'expire pas de lui-même, il vit jusqu'à ce que vous le supprimiez. Changer le mot de passe d'un utilisateur n'invalide pas ses jetons. En supprimant un utilisateur, vérifiez séparément ce que sont devenus ses jetons.

Et dissipons une idée fausse : l'authentification à deux facteurs ne vous aide pas ici. Elle protège le moment de la connexion. Elle n'a rien à dire sur une session déjà ouverte.

Le sens inverse : pourquoi suis-je déconnecté sans arrêt

C'est l'autre face du même mécanisme.

Le ticket a une durée de vie limitée, et l'interface le renouvelle régulièrement tant que vous êtes sur l'onglet. Fermez l'onglet et revenez des heures plus tard : aucun renouvellement n'a eu lieu, le ticket est mort, on vous demande de vous reconnecter. Ce n'est pas une panne.

La deuxième cause, moins connue, est plus intéressante : l'horloge de la machine. Un ticket porte un horodatage. Si l'horloge du serveur dérive, un ticket tout juste émis peut sembler venir du futur ou être expiré depuis longtemps. Le symptôme déroute : le mot de passe est bon, la connexion semble acceptée, et la session tombe juste après. Chercher un problème d'horloge du côté de l'identité ne vient à l'esprit de personne, mais cherchez.

Ce que fait Atlas

Chez Atlas, le cookie qui part vers le navigateur n'est pas le vrai ticket. Le navigateur ne porte qu'un identifiant aléatoire dénué de sens ; le ticket réel reste sur le serveur.

La différence est concrète : même si une faille du navigateur lit le cookie, elle ne repart pas avec le ticket lui-même, donc elle ne peut pas l'emporter ailleurs et s'en servir là-bas. La seule chose qu'elle puisse faire est d'agir depuis ce navigateur tant que cette session vit. Ce n'est pas un risque nul, mais cela réduit la portée de la menace.

Les sessions ouvertes sont écrites sur disque, si bien que personne n'est éjecté quand le produit se met à jour. L'écriture se fait volontairement en une seule étape : si le fichier était resté à moitié écrit, alors même que la lecture le tolère, toutes les sessions ouvertes seraient tombées.

Ce qui mérite vraiment d'être raconté, c'est un défaut trouvé ici en mesurant.

Les enregistrements de session expirés étaient nettoyés de la mémoire seulement, pas du fichier. Une machine en service a été examinée : cinq enregistrements expirés dormaient dans le fichier, chacun contenant un ticket. Ils y seraient restés jusqu'à la prochaine connexion, car rien d'autre n'écrivait jamais ce fichier.

L'intention du code était déjà de ne pas les garder. La seule chose qui manquait, c'était l'étape d'écriture.

La leçon vaut pour quiconque écrit du code de sécurité : oublier a deux lieux. Ce qui a été retiré de la mémoire n'a pas été retiré du disque, et des deux, celui du disque vit toujours plus longtemps. Quand vous décidez qu'une chose ne doit pas être conservée, la deuxième question est toujours la même : où est-elle conservée ?