Dans cet article, je vais vous parler des "connexions persistantes", avant toute chose, on va définir ce qu'est une connexion persistante. Pour commencer, vous verrez les usages communs de cette pratique, la place qu'elle a prise au sein de nos systèmes informatiques depuis plusieurs années. Pour finir, vous verrez en quoi cela doit être, comme tout au final, une pratique à utiliser avec pragmatisme et que toute application ne doit pas être en connexion permanente (vous pouvez vous spoiler avec l'une des principales raisons en reprenant cet article écrit il y a fort longtemps, mais toujours d'actualité : https://www.kanjian.fr/pourquoi-devez-vous-systematiquement-vous-deconnecter-dun-site-internet-quand-vous-avez-termine.html).
Définition
Ce que vous devez considérer comme connexion persistante, c'est par exemple la connexion à votre compte Facebook, Gmail, Tweeter, LinkedIn, Spotify, etc. et autres ou vous n'êtes jamais déconnecté au bout d'une certaine durée que vous l'utilisiez tous les jours ou que vous n'avez pas utilisé le service en question depuis plusieurs semaines. Une exception dans la liste Gmail en version pro va vous déconnecter de manière régulière, même si ce délai est beaucoup trop long et ne concerne pas que les applications mobiles, mais vous verrez pourquoi ensuite.
Une vraie généralisation de la pratique
Cette pratique, c'est accélérée ces dernières années, notamment à cause de Facebook. En effet, ne plus avoir à vous connecter un est confort sans précédent pour les utilisateurs. Vous pourriez même oublier votre mot de passe que cela ne vous portera pas préjudice tant que vous ne changez pas d'appareil.
De ce fait, on a commencé à l'avoir si tous les réseaux sociaux concurrents ou de la même firme. Puis, vous l'avez constaté, cette pratique, c'est déployée aussi dans les applications métiers ou aujourd'hui demander à un collaborateur de se reconnecter tous les jours sur une application critique de l'entreprise et perçue comme une application datée et obsolète...
Est-ce dangereux ?
Si je vous propose un article là-dessus, vous avez déjà la réponse : OUI. Alors pourquoi et dans quel contexte cela pose un problème, c'est ce que vous allez voir dans la suite de cet article. Dans un premier temps, je vous renvoie à un ancien article sur la nécessité de se déconnecter d'une application : https://www.kanjian.fr/pourquoi-devez-vous-systematiquement-vous-deconnecter-dun-site-internet-quand-vous-avez-termine.html.
Si vous n'avez pas peur de l'Anglais le NIST déconseille cette pratique dans ces recommandations notamment ici : https://pages.nist.gov/800-63-3/sp800-63b.html#sec7 dans le chapitre 7.2 via la phrase suivante :
When a session has been terminated, due to a time-out or other action, the user SHALL be required to establish a new session by authenticating again.
En français :
Lorsqu'une session a été résiliée, en raison d'un délai d'attente ou d'une autre action, l'utilisateur sera tenu d'établir une nouvelle session en s'authentifiant à nouveau.
Ce qui sous-entend qu'une session doit être résiliée, notamment soit via une action de l'utilisateur ou de l'application, ou d'un délai.
L'un des risques et qu'une personne qui ne se déconnecte jamais, laisse son appareil sans surveillance juste quelques minutes, qu'une personne malveillante arrive, ouvre la page de l'application et réalise des actions en son nom.
Autre risque en entreprise si vous utilisez une technologie de type SSO pour ensuite via le SSO, vous connectez aux autres applications, dans le cas ou l'une de ces applications ne met pas en place d'expiration de session (1h, 24h, 7jours - au-delà ça devient trop long dans un contexte professionnel-). Eh bien votre collaborateur n'aura plus besoin de passer par le SSO, ce qui pourrait avoir des impactes dans l'application, mais surtout laisser un accès utilisateur illégitime dans l'application (sans rentrer dans la technique, si certain process ne sont pas en place vous vous retrouvez avec un utilisateur qui maintient un accès non autorisé).
Un autre point, c'est que ce genre de session doit avoir en entreprise une durée de vie raisonnable, ne pas obliger une personne à se connecter toutes les heures, avoir un mécanisme de 24h (avec un système robuste), n'est pas en soit un souci. Dans l'idéal, selon l'application le délai doit être différent. Un système ultra-critique, par exemple une interface de gestion des sauvegardes ne devrait, à mon sens, ne pas vous laisser sans activité avoir une session qui dur plus d'une heure.
Vous augmentez les risques de vols de session également, et le plus souvent, le vol d'un simple cookie permettra à l'attaquant de prendre possession de votre compte. Et si vous n'êtes pas vigilant aux autres connexions active sur votre compte (quand l'application le permet), vous pouvez partager durant un long moment votre compte avec un acteur malveillant.
Autre point, si on vole votre session, pour ensuite l'utiliser d'un autre pays par exemple l'Inde, vu que c'est votre session "permanente" et que l'attaquant n'est pas repassé par les mécanismes d'authentification aucune alerte sur une connexion depuis un lieu trop distant de vos habitudes ne sera levé.
De même, je suis certain que vous n'accepteriez pas d'avoir une connexion permanente à votre application bancaire, imaginez si vous perdiez votre mobile le risque que cela représente. Car craquer un code sur un mobile n'est qu'une question de temps un exemple en vidéo que j'ai fait ici : Cracker un PIN de téléphone Android avec le FlipperZero.
Les exceptions
Je l'ai évoqué un peu plus haut, vous allez trouver des exceptions plus ou moins légitime à cette recommandation. Un exemple commun, c'est Gmail. En effet, si vous avez activé le 2FA / MFA sur votre compte Gmail, en personnel ou professionnel, peu importe, et que vous avez notamment choisi la validation par l'application, Google vous informe alors que sur l'application mobile votre compte n'aura jamais de déconnexion automatique ! C'est en effet pour lui indispensable de garder ce facteur actif pour valider vos futures connexions...
Conclusion
Pour terminer, vous l'aurez compris, je suis défavorable à cette fonctionnalité en entreprise, sans généraliser je pense, qu'une journée maximum de connexion ou au pire 7 jours pour certaines applications moins critiques — mais du coup moins utilisées ? — sont tout à fait légitime.
C'est surtout en fonction des applications que vous devez estimer le risque de ce genre de pratique et définir un curseur cohérent avec l'usage de l'application et la sécurité de cette dernière.
Crédit photo : Image de jcomp sur Freepik
