Quelles règles prévoir pour ouvrir, maintenir et fermer les sessions utilisateurs ?
D’après Sécurité informatique
Protéger les identifiants de session
Générer des tokens longs, aléatoires, non prévisibles.
Les envoyer uniquement sur un canal chiffré, marqués HttpOnly/Secure dans le cas de cookies web.
Les stocker côté serveur de manière sûre, avec un mapping vers l’utilisateur et son état de session.
Gérer la durée de vie
Timeout d’inactivité.
Expiration “absolue” (max-lifetime).
Renouveler le token avant/après une opération critique (login, élévation de privilèges), envoi de messages etc.
Inclure des mécanismes d’intégrité
Signature des messages ou au moins un hashing du contenu pour détecter toute altération.
Contrôle strict des points de reprise ou de synchronisation pour éviter le rejeu.
Superviser et auditer
Collecter les logs de session et les analyser.
Détecter les pics inhabituels ou incohérences (même session depuis deux origines différentes).
Mettre en place des alertes SIEM et des audits de configuration réguliers.
Tenir compte du contexte
Les protocoles plus anciens (SMBv1, PPTP, Telnet, etc.) sont à proscrire ou à entourer de défenses si on ne peut pas les supprimer.
Les interactions client-léger (notamment sur le Web) imposent des mesures spécifiques (cookies, authentification par jetons, etc.).
Les sessions de type “machine-to-machine” (API, microservices) peuvent nécessiter du OAuth2, des certificats mutuels, etc.