Dans le cas de mailman, tu applique un principe édicté comme une loi d'airain (stockage des mot de passe sous forme hashé) mais de l'autre coté, tu autorise la transmission du password par mail.
Sérieusement, si tu veux débattre il faut éviter de balancer ce genre de bêtise.
Réfléchit 30 secondes, et tu comprendras qu'il est impossible de transmettre un password par mail si on le stocke hashé, donc...
Même si c'est simple à implémenter, ça reste une mesure inutile si tu ne renforce pas le canal de transmission du mot de passe
Qui a dit que je trouvais ça bien de transmettre le (allez disons nouveau) mot de passe par mail? Au contraire! si tu as fais la conclusion de ma phrase au dessus, tu sais qu'il est impossible de transmettre un truc qu'on n'a pas.
C'est bon, on est en 2018 et non 1998, il y a des "best practices" sur le sujet depuis des lustres (transmission d'un lien, en HTTPS, de reset de mot de passe avec durée de vie courte, par exemple).
Si le sujet t’intéresse, tu trouveras plein d'info sur comment sécuriser ce type de fonctionnalité. Pour mailman pourquoi pas (rien à foutre du token), mais un minimum serait à faire comme par exemple ne pas fournir la fonctionnalité par défaut et fournir un token non modifiable (juste renouvelable en désactivant l'ancien en cas de perte/vol), mais "rien à foutre on fait comme il y a 20 ans" est léger.
Ce n'est pas le choix des dev qui préfèrent garder la fonctionnalité d'abonnement/désabonnement par mail
C'est un choix. Soit. Mais alors :
- On évite de laisser l'utilisateur éditer le pass, ça doit être un token (non personnalisable). Pas la config par défaut de mailman si j'ai bien suivi.
- Ce n'est pas parce que ce choix était viable en 1998 avec quelques perdus sur le net qu'il reste "bien" en 2018, le monde a changé entre les deux, les risques (et les attaques, les usages du pass...) aussi. Rester figé avec des idées et usage de 1998 en 2018 est juste dangereux pour l'ensemble quand ce n'est pas déjà pour soit. Comme pour les vaccins, la fainéantise pour une partie des outils a un impact sur les autres.
Et en fait ça se fait déjà (la fonctionnalité, sans exposer le pass) dans d'autres outils moderne (par exemple les mails Google ou Microsoft) : fourniture d'un token pour la gestion "en clair" (pour les mails en IMAP, j'ai un token pour mot de passe, que je peux révoquer dans l'interface d'admin, et surtout celui-ci est unique par appli dans le workflow présenté à l'utilisateur; tu l'auras compris, ce n'est pas une question de fonctionnalités, mais de sensibilité à la sécurité qu'on veut).
Oui, c'est toute une mentalité qu'il faut changer, et on est loin de le faire, on trouve une tonne d'excuses à mailman historique mais encore une fois bizarrement quand c'est Free on ne cherche pas d'excuses (alors qu'on peut en trouver des aussi "bonnes", le mot entre guillemets hein, d'excuses) alors que bon on peut en trouver (en premier lieu que le pass est une token non modifiable en fait, donc pas personnalisable, ça limite, et les données sont peu utiles aux "méchants" donc sécurité adaptée comme argumenté pour mailman).
Mais pourquoi cette tolérance arbitraire? La nostalgie?
bon, je pense que tout est dit, les personnes sensibles à la sécu savent déjà tout ça et les autres ne seront pas plus convaincues avec plus.
[^] # Re: Chaussures du cordonnier
Posté par Zenitram (site web personnel) . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à -4.
Sérieusement, si tu veux débattre il faut éviter de balancer ce genre de bêtise.
Réfléchit 30 secondes, et tu comprendras qu'il est impossible de transmettre un password par mail si on le stocke hashé, donc...
Qui a dit que je trouvais ça bien de transmettre le (allez disons nouveau) mot de passe par mail? Au contraire! si tu as fais la conclusion de ma phrase au dessus, tu sais qu'il est impossible de transmettre un truc qu'on n'a pas.
C'est bon, on est en 2018 et non 1998, il y a des "best practices" sur le sujet depuis des lustres (transmission d'un lien, en HTTPS, de reset de mot de passe avec durée de vie courte, par exemple).
Si le sujet t’intéresse, tu trouveras plein d'info sur comment sécuriser ce type de fonctionnalité. Pour mailman pourquoi pas (rien à foutre du token), mais un minimum serait à faire comme par exemple ne pas fournir la fonctionnalité par défaut et fournir un token non modifiable (juste renouvelable en désactivant l'ancien en cas de perte/vol), mais "rien à foutre on fait comme il y a 20 ans" est léger.
C'est un choix. Soit. Mais alors :
- On évite de laisser l'utilisateur éditer le pass, ça doit être un token (non personnalisable). Pas la config par défaut de mailman si j'ai bien suivi.
- Ce n'est pas parce que ce choix était viable en 1998 avec quelques perdus sur le net qu'il reste "bien" en 2018, le monde a changé entre les deux, les risques (et les attaques, les usages du pass...) aussi. Rester figé avec des idées et usage de 1998 en 2018 est juste dangereux pour l'ensemble quand ce n'est pas déjà pour soit. Comme pour les vaccins, la fainéantise pour une partie des outils a un impact sur les autres.
Et en fait ça se fait déjà (la fonctionnalité, sans exposer le pass) dans d'autres outils moderne (par exemple les mails Google ou Microsoft) : fourniture d'un token pour la gestion "en clair" (pour les mails en IMAP, j'ai un token pour mot de passe, que je peux révoquer dans l'interface d'admin, et surtout celui-ci est unique par appli dans le workflow présenté à l'utilisateur; tu l'auras compris, ce n'est pas une question de fonctionnalités, mais de sensibilité à la sécurité qu'on veut).
Oui, c'est toute une mentalité qu'il faut changer, et on est loin de le faire, on trouve une tonne d'excuses à mailman historique mais encore une fois bizarrement quand c'est Free on ne cherche pas d'excuses (alors qu'on peut en trouver des aussi "bonnes", le mot entre guillemets hein, d'excuses) alors que bon on peut en trouver (en premier lieu que le pass est une token non modifiable en fait, donc pas personnalisable, ça limite, et les données sont peu utiles aux "méchants" donc sécurité adaptée comme argumenté pour mailman).
Mais pourquoi cette tolérance arbitraire? La nostalgie?
bon, je pense que tout est dit, les personnes sensibles à la sécu savent déjà tout ça et les autres ne seront pas plus convaincues avec plus.