Je ne sais pas, peut-être que vous avez raison. Mais je trouve que, justement, appliqué des mesures de sécurité sans comprendre les risques réellement associés a une problématique donné n'est pas une bonne pratique, a mon avis. 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. Par analogie, cela reviens a attaché un vélo avec un antivol garanti anti effraction a une branche d'arbre. Le pire serait de que cela pourrait donner l'illusion a l'utilisateur qu'il peut faire confiance à mailman alors qu'il ne faut surtout pas lui faire confiance. C'est qui est dit texto dans la doc du soft.
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. Le mail, c'est encore pire que HTTP en clair. Les mails sont copié et dupliqué dans tout les coin, stocké en local et sur des serveurs distant, etc ... Dans le cas de mailman, si tu veux adresser la problématique du mot de passe stocké en clair cela reviens a interdire la gestion de l'abonnement par mail, et de privilégier un canal plus sur comme une application web. 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 a prendre en compte dans le contexte d'utilisation du produit, certes, mais le fait que le mot de passe soit hashé en base ou pas ne change rien au problème des mot de passe en clair dans des mails stockés un peu partout.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Chaussures du cordonnier
Posté par Big Pete . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à 3.
Je ne sais pas, peut-être que vous avez raison. Mais je trouve que, justement, appliqué des mesures de sécurité sans comprendre les risques réellement associés a une problématique donné n'est pas une bonne pratique, a mon avis. 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. Par analogie, cela reviens a attaché un vélo avec un antivol garanti anti effraction a une branche d'arbre. Le pire serait de que cela pourrait donner l'illusion a l'utilisateur qu'il peut faire confiance à mailman alors qu'il ne faut surtout pas lui faire confiance. C'est qui est dit texto dans la doc du soft.
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. Le mail, c'est encore pire que HTTP en clair. Les mails sont copié et dupliqué dans tout les coin, stocké en local et sur des serveurs distant, etc ... Dans le cas de mailman, si tu veux adresser la problématique du mot de passe stocké en clair cela reviens a interdire la gestion de l'abonnement par mail, et de privilégier un canal plus sur comme une application web. 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 a prendre en compte dans le contexte d'utilisation du produit, certes, mais le fait que le mot de passe soit hashé en base ou pas ne change rien au problème des mot de passe en clair dans des mails stockés un peu partout.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.