Quel fonctionnement souhaitons-nous avoir pour nos sessions ?

a marqué ce sujet comme résolu.

Bonsoir,

Qu’est-ce qu’une session ?

Lorsque vous vous connectez sur un site web, une session est créée sur le serveur pour se souvenir de qui vous êtes. Au bout d’un certain temps, celle-ci expire et vous êtes déconnectés.

Actuellement le fonctionnement des sessions sur Zeste de Savoir est assez simple :

  • à la connexion, si coche « Se souvenir de moi », la session est créée avec une durée de 1 mois ;
  • à la fin de cette durée de 1 mois, la session expire et vous êtes déconnectés.

Plusieurs membres se sont plaints de ce fonctionnement donc je pense qu’il faut réfléchir à un autre fonctionnement. Cet article propose un fonctionnement (à la fin de l’article) qui, je pense, conviendrait bien à Zeste de Savoir étant donné que les données présentes sur le site web ne sont pas très sensibles (par exemple nous n’avons pas de paiement bancaire en ligne).

L’idée serait que la session expire soit après une certaine durée d’inactivité (c’est-à-dire si le site web n’a pas été visité pendant X semaines ou X mois) soit après une certaine durée depuis la dernière connexion (comme actuellement, mais avec une durée plus longue de Y mois).

Êtes-vous favorable à ce nouveau fonctionnement sur le principe ? Utilisez les pouces verts et rouges pour voter.

Quelle durée d’inactivité et quelle durée depuis la dernière connexion faut-il définir ?

Graphique qui résume bien le principe (issu de l'article au-dessus)
Graphique qui résume bien le principe (issu de l'article au-dessus)
+14 -0

Bonjour

Je suis favorable à un tel changement. Comme durées, je proposerais environ quarante jours de délai d’inactivité, et autour de neuf mois de délai de reconnexion forcée.

Pour être exact, et afin de maximiser la quantité de nombre premiers et de références mathématiques, je propose 41 jours d’inactivité et 271 jours (100e\approx 100e) de délai de reconnexion.

+2 -0

Désolé mais je ne comprend pas.

Quel est le reproche au fonctionnement actuel ? Ça aiderait à choisir une solution.

Je rappèle qu’on a pas de système solide de validation des actions importantes (Désinscription, changement d’adresse email), ni de gestion des sessions. En cas de vol de sessions, ben c’est Game Over pour le compte. Alors j’hésiterais 2s avant de valider une session pour 100J / 365J.

+0 -0

Le reproche est que la session expire vite et sans raison même quand on reste actif, et que ça embête plusieurs personnes. La session n’est jamais revalidée : elle expire dans tous les cas au bout d’un mois (ou de la session du navigateur si la petite case n’est pas cochée).

Mais je suis d’accord et le fait est qu’on en discutait justement à l’instant avec @Situphen : si la durée de la session change, vérifier par mot de passe les actions importantes est d’autant plus pertinent — déjà que ça l’est déjà…

+0 -0

Salut,

Mais je suis d’accord et le fait est qu’on en discutait justement à l’instant avec @Situphen : si la durée de la session change, vérifier par mot de passe les actions importantes est d’autant plus pertinent — déjà que ça l’est déjà…

Le risque de sécurité le plus important, c’est qu’une session ouverte soit récupérée par une personne mal attentionnée, ou c’est qu’un mot de passe réutilisé par les membres imprudents soit fishé/récupéré via une faiblesse sur un autre système ? On peut débattre tant qu’on veut sur la durée des sessions et sur le fait de redemander des mdp, si le point faible critique sont les mdp eux même, ça ne changera pas grand chose. Avoir du 2FA optionnel pour les membres et obligatoire pour ceux avec des pouvoirs supplémentaires (comme les Staff) me parait par exemple être une mesure beaucoup plus forte que redemander un mdp pour toute action critique (ça n’empêche pas que confirmer par mdp les actions définitives comme la suppression du compte est une bonne idée par ailleurs cela dit). Aujourd’hui, si même un seul Staff a un mdp faible/réutilisé, le risque pour le contenu sur le site est fort.

+5 -0

Si on va sur ce sujet de la sécurité, je pense que les différents risques sont, du plus probable au plus improbable :

  1. une personne de l’entourage (ami, famille, collègue…) qui a accès à l’ordinateur d’un membre sur lequel la session est déjà ouverte ;
  2. une personne se connecte au compte car le mot de passe est le même qu’ailleurs ;
  3. une personne réussit à voler la clé de la session pour la réutiliser sur son ordinateur à elle.

Voici de mon point de vue les solutions :

  1. la seule solution que je vois c’est de redemander le mot de passe avant certaines actions critiques ;
  2. deux solutions :
    • on peut effectivement mettre en place une authentification à double facteur mais ça risque d’être compliqué et potentiellement coûteux (notamment si on permet via SMS ou appels) ;
    • une alternative c’est de faire confiance aux membres (notamment aux Staffeux) et de les guider lors du choix du mot de passe (avec des étiquettes "Simple", "Moyen", "Difficile") ainsi que de mieux séparer les rôles (par exemple pour l’équipe de communication qui ne devrait pas avoir accès aux droits de modération et validation) ;
  3. la solution serait comme proposée par @ache de redemander le mot de passe avant certaines actions critiques et de proposer une gestion des sessions (ce dernier point est relativement aisé à mettre en place).

En tous cas, pour les points 1) et 2) le nouveau fonctionnement des sessions n’aggraverait pas vraiment la situation puisque le délai d’inactivité resterait à peu près le même (41 jours au lieu de 30 jours). Pour le point 3) effectivement plus le délai de reconnexion forcée est long, plus le risque augmente, mais comme il est déjà très faible au début je ne sais pas si c’est si bloquant que ça.

le risque pour le contenu sur le site est fort

N’oublions pas qu’il y a une sauvegarde du site web toutes les deux heures en deux endroits séparés (peut-être bientôt trois) donc normalement même si ça arrive on pourra toujours piocher dedans.

+0 -0

Quelle est la valeur d’un compte ZdS standard ?

A priori, je dirais pas grand chose. Un accès illicite à un compte ZdS permet au pire de diffuser du spam qui sera très vite intercepté et la compromission du compte sera détectée. Sinon, un compte ZdS ne permet (en principe) pas d’usurper l’identité civile de quelqu’un (comme sur un réseau social), ni de récupérer des coordonnées bancaires ou de faire des achats à l’insu de la victime.

En partant de ce constat, ça ne me choque pas de relaxer un peu la politique de la durée de session au profit d’une expérience améliorée.
En revanche, cela n’empêche aucunement de mettre en place une confirmation du mot de passe avant d’effectuer certaines actions, comme le préconise @ache. Cela n’empêche pas non plus de mettre en place du 2FA optionnel comme le suggère @adri1 (et c’est à la mode ! ^^ )

À noter que je ne parle ici que d’un compte standard, et que je ne prends pas en compte le fait que la messagerie privée pourrait dans certains cas (rares ?) contenir des informations sensibles.

En ce qui concerne les comptes spéciaux, je n’ai pas vraiment conscience de l’étendue de leurs pouvoirs respectifs, mais je suppose que le 2FA obligatoire pourrait être une bonne idée.

on peut effectivement mettre en place une authentification à double facteur mais ça risque d’être compliqué et potentiellement coûteux (notamment si on permet via SMS ou appels) ;

Ajouter une authentification à double facteurs ne me semble pas particulièrement coûteux, si on se contente de supporter du TOTP (un protocole de 2FA disponible sur toutes les plateformes existantes, et se basant sur l’heure et non sur des SMS ou similaire).

Ça peut être assez amusant à implémenter d’ailleurs ^^ .

Le rendre obligatoire (p.ex. en forçant la configuration si c’est pas actif et qu’on est dans le groupe staff) est aussi faisable mais c’est peut-être s’embêter pour pas grand chose quand on peut juste demander directement au quelques personnes ayant des droits large (à commencer par les super utilisateurs) de le faire.

une alternative c’est de faire confiance aux membres (notamment aux Staffeux) et de les guider lors du choix du mot de passe (avec des étiquettes "Simple", "Moyen", "Difficile") ainsi que de mieux séparer les rôles (par exemple pour l’équipe de communication qui ne devrait pas avoir accès aux droits de modération et validation) ;

C’est quelque chose qu’est en projet avec @gcodeur notamment (on retrouve des traces par ici, mais on en a aussi reparlé plus récemment). Comme toutes les permissions sont à reprendre, y’a un peu de boulot :) .

J’ai aussi un peu avancé dans ce sens en mettant la possibilité de marquer les messages comme potentiel spam sous une permission dédiée, dans ma reprise récente de ces dernières. Il serait bien que toute nouvelle fonctionnalité ait sa permission associée.

+0 -0

on peut effectivement mettre en place une authentification à double facteur mais ça risque d’être compliqué et potentiellement coûteux (notamment si on permet via SMS ou appels) ;

Ajouter une authentification à double facteurs ne me semble pas particulièrement coûteux, si on se contente de supporter du TOTP (un protocole de 2FA disponible sur toutes les plateformes existantes, et se basant sur l’heure et non sur des SMS ou similaire).

Amaury

Tout à fait, le TOTP présente bien des avantages par rapport au SMS :

  • il est gratuit à l’usage ;
  • possible d’enregistrer sa seed de façon sécurisée au cas où l’on perdrait son appareil servant au 2FA ;
  • ne dépend pas des réseaux de communication (pas de lag, pas de coupure) ;
  • ne nécessite pas de demander un numéro de téléphone à l’utilisateur qu’il faut ensuite traiter en adéquation avec le RGPD.

Puis surtout, c’est beaucoup moins fragile que les SMS.

une alternative c’est de faire confiance aux membres (notamment aux Staffeux) et de les guider lors du choix du mot de passe (avec des étiquettes "Simple", "Moyen", "Difficile")

On en voit un peu partout depuis plusieurs années (parfois d’ailleurs avec une mesure foireuse), et pourtant force est de constater que les études sur les habitudes des gens en terme de mots de passes ont toujours des résultats aussi désastreux. Faire confiance aux utilisateurs pour qu’ils aient effectivement des pratiques saines, ça ne marche pas.

+1 -0

Pour moi, on ne peut pas généraliser les pratiques des banques, car elles sont justement l’exemple à ne pas suivre, très souvent.

Mon expérience avec les banques c’est que leur « sécurité » relève surtout du spectacle, certainement pour rassurer les utilisateurs. Je pense notamment au fait de taper avec un pad virtuel un mot de passe (composé de quelques chiffres…) alors qu’autoriser le copier-coller depuis un gestionnaires de mot de passe et d’accepter n’importe quel caractère serait sûrement mieux et moins contraignant.
Les banques se préoccupent d’un potentiel keylogger avant même de regarder plus simple : étendre l’ensemble des caractères possibles au-delà des 10 chiffres… C’est comme le coup de la porte blindée posé sur un mur en plâtre.

Ça suppose que la personne en question possède, utilise et garde sur soi en continu un smartphone.

Quant au 2FA via TOTP, c’est effectivement l’idée, et cela apporte son lot de contraintes. On peut estimer qu’un bon modèle d’authentification comprend trois facteurs :

  • ce que je sais (mot de passe) ;
  • ce que j’ai (mon téléphone (via SMS, TOTP), une clé U2F, …) ;
  • qui je suis (mon empreinte digitale, mon iris, mon ADN, …).

Il est vrai qu’il faut avoir un appareil sur soi, mais c’est justement tout le principe de la chose : ça sert à vérifier ce que j’ai en plus du ce que je sais. C’est donc par nature une contrainte. On peut estimer ou non que le fait d’avoir une smartphone toujours sur soi est une contrainte acceptable selon les cas.

Quant au 3e facteur, il est évidemment assez difficile et coûteux à mettre en place, mais les deux premiers facteurs sont déjà amplement suffisants pour la vie de tous les jours.

Je précise que KeePassXC dispose d’un gestionnaire TOTP intégré ;)

On peut générer des TOTP sans smartphone à partir de la graine.

adri1

En effet. Après recherche, voici les trois outils que j’ai trouvé :


Pour moi, on ne peut pas généraliser les pratiques des banques, car elles sont justement l’exemple à ne pas suivre, très souvent.

sgble

J’espère ne pas avoir sous-entendu qu’il fallait s’inspirer des banques. :)

@tleb: Je n’ai pas de téléphone portable, du coup, j’ai fais un billet pour utiliser oathtool avec Discord par exemple. ^^

Dans pas longtemps (genre la semaine prochaine certainement…) je pense passer à l’utilisation d’une Yubikey (ou Solokey peu importe).

Bref, tant qu’un portable n’est pas nécessaire moi ça me va. J’ai pas besoin d’un portable ni pour les SMS, ni pour un TOTP, donc pas de problème.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte