Bienvenue en 2018,
Année de la mise en application du RGPD.
Année de la maturité en cybersécurité ? Pas pour tout le monde en tous cas.
Mon expérience d'hier soir m'a laissé perplexe. Sur la page de connexion des abonnés Freebox, ayant perdu mon mot de passe, j'ai renseigné les champs me permettant de le récupérer et … surprise, je l'ai récupéré … en clair par mail.
Nous sommes en 2018 et Free stocke les mots de passe de ses abonnés en clair.
Free ! Pas la petite PME du quartier …
Il y a encore du boulot.
La route est longue et la voie est pleine de crottin !
# Pas forcément
Posté par Mimoza . Évalué à 7.
Il y a un processus de chiffrement/déchiffrement du mot de passe. Donc pas forcément stocké en claire mais de manière réversible.
Je te rassure Pole emploie fait la même chose quand tu perd tes identifiants de connexion. Une fois ton adresse mail renseigné ils t'envoient 2 mails, en même temps, a cette adresse, un avec l'identifiant, l'autre avec le mot de passe en claire.
Que dire d'une certaine banque en ligne qui te demande via leur serveur vocal la première lettre de ton mot de passe ?
[^] # Re: Pas forcément
Posté par Adminrezo (site web personnel) . Évalué à 10.
En effet, c'est soit en clair soit réversible dans un cas comme dans l'autre c'est aberrant.
[^] # Re: Pas forcément
Posté par David Demelier (site web personnel) . Évalué à 7.
Tout à fait, quand je pense que tous les mois je reçois mon mot de passe en clair des abonnements mailman, pourtant personne s'en plaint !
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas forcément
Posté par Framasky (site web personnel) . Évalué à 2. Dernière modification le 09 septembre 2018 à 19:37.
Au moins mailman te prévient explicitement que c'est stocké en clair.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Pas forcément
Posté par Sufflope (site web personnel) . Évalué à 6.
Donc en O(clair), merci d'avoir joué.
[^] # Re: Pas forcément
Posté par kursus_hc . Évalué à 2. Dernière modification le 10 août 2018 à 00:59.
Mis à part qu'une telle demande n'a aucun sens ils peuvent ne stocker en clair que la première lettre du mot de passe.
[^] # Re: Pas forcément
Posté par Mimoza . Évalué à 2.
Oui, mais ça veux dire affaiblir intentionnellement le mot de passe client. Connaissant la solidité usuel pas sûr que ce soit une bonne idée …
[^] # Re: Pas forcément
Posté par Maclag . Évalué à 7.
En même temps, la gestion des mots de passe en ligne est devenu un cauchemar à gérer:
-Si tu exiges un mot de passe complexe, il va être unique pour une myriade de service et la sécu devient basée sur le service le plus faible
-S'il est unique à chaque service, soit assuré que le mot de passe sera court-circuité à chaque connexion par le système de récupération de mot de passe, qui est… moins sûr!
-Ou alors tu acceptes que le mot de passe doit être facile à retenir et donc moins robuste
Du coup les services en ligne commencent à déléguer l'authentification aux GAFAM, ce qui nuit encore un peu plus à la protection de la vie privée!
Les "experts" utiliseront un gestionnaire de mot de passe, ce qui n'est pas bien loin du mot de passe unique si l'attaque vise une personne en particulier plutôt que la pêche au filet.
Conclusion: privilégiez les systèmes d'authentification libres, tels que celui de XMPP, et ce serait bien qu'on puisse y ajouter une double vérif (SMS ou autre) à peu de frais.
C'étaient mon opinion super pertinente de non-expert…
# Chaussures du cordonnier
Posté par Zenitram (site web personnel) . Évalué à -10.
Je m'étais fait la même réflexion sur un outil fait par des geeks barbus pour gérer des trucs de geeks barbus, de ce que j'ai compris d'une réponse est que pour 2018, le besoin de chiffrer les mots de passe est subjectif (dépendrait de l'importance qu'on apporte aux données derrière)(et après recherche sur le net ça semble être connu et "qu'est-ce que ça peut te foutre?" semble être la réponse la plus classique.
Le fait de ne pas pouvoir changer le mot de passe (aléatoire) pourrait être un argument d'une telle sélectivité dans le cas de Free, donc acceptable, na (et compatible RGPD si ça ne l'est pas sans cet argument?).
Bref, avant de condamner Free "nous sommes en 2018 et toujours mots de passe en clair" il faudrait mieux nettoyer devant chez soit "nous les geeks barbus" avec les outils maintenu par des geeks barbus, sinon la critique n'est pas bien crédible.
[^] # Re: Chaussures du cordonnier
Posté par Adminrezo (site web personnel) . Évalué à 10.
Euh …
J'ai pas de barbe.
Et en plus les données qui sont derrière sont un peu personnelles quand même …
Bien sûr Free n'est pas le seul à pratiquer ce genre de solutions, on trouvera toujours tel site qui fait les chose bien et tel autre qui les fait mal mais il est peut-être temps de changer, il y a tout ce qu'il faut aujourd'hui pour faire les choses proprement.
[^] # Re: Chaussures du cordonnier
Posté par Adminrezo (site web personnel) . Évalué à 2. Dernière modification le 06 août 2018 à 14:48.
Et les geeks (barbus ou non) ça sert aussi à faire ça qui répond au problème :
https://ltb-project.org/
[^] # Re: Chaussures du cordonnier
Posté par Maclag . Évalué à 4. Dernière modification le 09 août 2018 à 06:35.
Totalement HS, mais "Welcome on…", ça sent très fort la traduction littérale mot-à-mot.
Les anglophones vont se faire mal aux yeux. "Welcome to the LDAP Toolbox Project", ça me semblerait plus Anglais.
[^] # Re: Chaussures du cordonnier
Posté par kursus_hc . Évalué à 2.
Et
a compilation of tools for LDAP administrators, to ease their rough lifedevienta compilation of tools for LDAP administrators to make their life easier.[^] # Re: Chaussures du cordonnier
Posté par Zenitram (site web personnel) . Évalué à -6. Dernière modification le 06 août 2018 à 15:04.
Tu n'as pas suivi le pic, OK, explicitons.
Pour être plus clair : "chaussure du cordonnier" en sujet, c'est pour parler que "ceux qui font" Internet (je ne parle pas que du lien, il suffit de regarder le net ailleurs pour avoir une idée) ne trouvent rien à redire du sujet ("ça dépend" à la place de "toujours", c'est la porte à toute subjectivité).
Quand aux données personnelles, on peut facilement te répondre que le mot de passe est unique (pas modifiable donc tu mets ton mot de passe) et que ça change rien de le chiffrer puisque même chiffré on t'enverras un lien de reset sur ton mail (la où tu reçois le pass en clair : tout est en clair dans les 2 cas, si on a accès à ton mail on a accès à tes données Free). Bref, quand on excuse "chez soit", les autres ont les mêmes type d'excuse ensuite et sont tout autant légitime.
Dire "ce n'est pas bien de fumer" à ses enfants tout en fumant,est-ce crédible? Je ne parle pas du voisin dans cette phrase.
Bref, voila, à partir du moment où ceux sensés donner l'exemple (et non je ne parle pas "on trouvera toujours tel site", je parle de sites et d'outils gérés par ceux sensés montrer l'exemple) donnent l'exemple de mots de passe en clair, difficile de condamner Free pour ce qu'ils font (et si leur base se fait dumper, ils resetteront tout et basta).
Note : chez moi je n'accepte pas de stocker les mots de passe en clair, je connais. Je dis juste que publiquement condamner un site X qui vient d'une entreprise qui veut faire du fric, ce n'est pas utile si déjà on n'arrive pas à convaincre les "geeks barbus" (une image) que c'est gênant. Vilipender publiquement une entreprise X qui utilise des outils et peu sensible au problème ne servira à rien si déjà tu ne sais pas convaincre des gens "passionnés".
[^] # Re: Chaussures du cordonnier
Posté par Colin Pitrat (site web personnel) . Évalué à 5.
Le problème ce n'est pas d'envoyer le mot de passe par mail. Le problème c'est de le stocker en clair. Parce que ça arrive même aux meilleurs de se faire pirater sa base de données … Dans ce cas là, un accès en lecture seule suffit à causer beaucoup de tort.
[^] # Re: Chaussures du cordonnier
Posté par Zenitram (site web personnel) . Évalué à 5.
Mais tu prêches un convaincu!
Les réponses qu'on me fait sont toutes hors sujet : je suis convaincu que c'est mal, suivez le lien que j'ai mis dans on premier commentaire.
Perso, ça me déprime qu'on trouve normal, même pour les plus technophiles, que le pass soit stocké et envoyé en clair, juste parce que c'est un accès "pas important" (ce qui est subjectif, surtout avec les pass réutilisés).
Le problème est la crédibilité : est-ce jugé comme mal de stocker et envoyer des pass en clair? Oui pour des gens qui s'y connaissent. C'est ça le soucis. Que Free le fasse est un détail, car des gens "dans le domaine" disent aussi que ça va (sur Twitter, ou en codant des outils).
M'argumenter que c'est mal ne changera rien (prêcher un convaincu ne change rien dans le nombre de convaincu), la question subtile qu'il faut expliciter donc est : bon, vous imaginez comment de changer ça? Ne me dite pas "balancer le nom de Free en public chez les geeks", ça ne sert strictement à rien car la seule réponse de Free serait que même des gens pointus dans le domaine trouvent ça pas méchant.
C'était peut-être trop implicite, soyons explicite : le problème est de ne pas voir le problème à l'origine, et de vouloir traiter les conséquences (Free) et pas les causes (gens experts, outils d'expert, trouvent ça acceptable), et je me demande comment on pourrait changer le problème sans se poser la question de traiter le problème à la source.
[^] # Re: Chaussures du cordonnier
Posté par Faya . Évalué à 10. Dernière modification le 06 août 2018 à 18:09.
Ou alors on peut simplement penser qu'en soulevant publiquement le soucis (bon je sais pas si DLFP est suffisament "public"…) chez Free quelqu'un va se rendre compte que c'est une connerie et n'attendra pas que l'IETF corrige pour se mettre à jour… C'est quoi cet argument d'autorité inversé !?
X c'est une grosse connerie, mais comme les pros font la même, les autres peuvent la faire aussi… C'est débile. Et beaucoup de boîtes, petites ou grandes, n'ont pas attendu l'IETF pour hasher leurs passwords ! C'est dans leur intérêt puisqu'un leak d'infos privées qui passe au JT ça n'est jamais bon pour la boîte en question.
T'aime bien les analogies, c'est comme si je disais "Cahuzac, ministre du budget, fraude le fisc. Je peux le faire aussi." Y'en a sûrement qui ont ce genre de raisonnement mais ça n'en reste pas moins débile. Donc ça peut valoir le coup de communiquer dessus et d'en informer Free. On excuse pas une connerie avec une autre connerie.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . Évalué à 8.
Le stockage des mdp en clair ou de façon réversible entraîne pas mal de problème parce que les gens normaux réutilisent souvent les mdps. N'importe quel argumentaire en faveur du stockage des mdps en clair ou de façon réversible n'est qu'une justification face à l'abaissement de sécurité que cela provoque et en rien une raison vis-à-vis de ce problème de sécurité.
De même, stocker en clair des mdps soit-disant parce que la sécurité de la bdd est inviolable n'est qu'un argument illusoire, valable uniquement jusqu'au jour où la bdd des mdps se fait voler.
Personnellement, sur mon serveur perso, tout mes mdps sont hashés en sha256. Et bon, se servir de la médiocrité des autres pour justifier sa propre médiocrité, c'est rentrer dans la spirale de la nullité. À un moment donné, faut bien se lancer la sécurisation de ses services sans attendre que le moindre petit site perdu du web l'ait également fait.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Christie Poutrelle (site web personnel) . Évalué à 3. Dernière modification le 06 août 2018 à 17:18.
Et saltés, avec un salt unique par utilisateur, salt unique qui est regénéré à chaque modification du mot de passe, j'espère. Et d'ailleurs y'a d'autres algos de hash bien mieux que sha256 à ce que j'ai lu.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . Évalué à -3.
Ah bon ? On a une attaque efficace sur tout ce qui est sha2 ? Ce n'est pas parce que sha3 est sorti qu'il existe une attaque rapide sur sha2. Même sans sel ca reste une bonne solution. Contrairement à garder des mdps en clair.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Sufflope (site web personnel) . Évalué à 4.
Non, c'est de la merde. bcrypt ou mieux or die. Sinon autant stocker en clair au moins ça sera écologique en économisant des cycles processeur.
[^] # Re: Chaussures du cordonnier
Posté par Parleur . Évalué à 1.
Je ne sais pas à quel degré ton commentaire est à prendre, mais pour bcrypt, moi j'en suis resté à ça : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700758
[^] # Re: Chaussures du cordonnier
Posté par Wawet76 . Évalué à 6.
Apparemment il y a bcrypt un algo fait pour hacher les mots de passe, et bcrypt un logiciel pour chiffrer des fichiers. Les deux utilisent Blowfish, mais pas pour la même chose.
Le lien que tu as donné parle du logiciel de chiffrement. Pas de la fonction de hash.
https://en.wikipedia.org/wiki/Bcrypt#See_also
https://en.wikipedia.org/wiki/Blowfish_(cipher)#Blowfish_in_practice
[^] # Re: Chaussures du cordonnier
Posté par Parleur . Évalué à 1.
Merci du complément d'information et de clarifier les choses pour moi. :)
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . Évalué à 0. Dernière modification le 07 août 2018 à 09:24.
En quoi ? Y a une attaque viable contre sha2 ? Je t'avoue que j'attendais une réponse un peu plus élaboré qu'un simple jugement sans rien derrière.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Zenitram (site web personnel) . Évalué à 6.
Ha… Ouch, ça fait mal, j'espère pour toi que tu ne travailles pas dans la sécurité, ça serait une faute professionnelle et tu devrais être viré sur le champs (bon, à relire, "Même sans sel ca reste une bonne solution" était déjà un motif).
Oui : brute-force.
La vite fait recherche rapide (il doit y avoir bien mieux), je trouve :
"SHA256 […] an average graphic card that costs only $150 can calculate more than 200 million hashes/s. Calculating at 200M/s, to try all possibilities for an 8 character alphanumberic (capital, lower, numbers) will take around 300 hours."
Note : ça date de 2011, je te laisse essayer d'imaginer pour du matos de 2018 et/ou AWS, tu vas prendre la honte.
Et ça, c'est avec sel (sinon il y a les tables), "Même sans sel ca reste une bonne solution." c'est juste une connerie.
--> PBKDF2 (avec du SHA2 ça va, c'est juste seul, ce qui est le cas quand on dit "SHA2", qui est pourri; avec un sel sinon ça redevient une connerie) avec 10000 itérations mini! (Source : NIST)
Disons que c'est largement connu, donc bon on ne s'attend pas à ce genre de réponse et au besoin d'élaborer quand on répond "c'est de la merde" quand quelqu'un dit que la terre est plate.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . Évalué à -6. Dernière modification le 07 août 2018 à 11:11.
Bah c'est sûr, si tu coupes 90% des possibilités, d'un coup le bruteforce c'est plus rapide. Dans ce cas, je peux te bruteforcer n'importe quel mdp en un temps record, à condition qu'il ne fasse qu'un seul caractère …
Et sinon, avec un mdp dont tu ne connais pas la taille, pouvant aller jusqu'à 12 (voir 36) caractères, incluant des caractères spéciaux, dont le fameux symbole '€' qui n'est quasiment jamais testé, il faut combien de temps ? Si t'as une étude dessus je suis preneur.
Et du coup, t'as des algo de hash qui sont efficaces face à un bruteforce ?
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par oinkoink_daotter . Évalué à 5.
Le truc c'est que 8 caractères c'est déjà beaucoup pour un humain, surtout si on doit en avoir un par service, alors 12 à 36 … Malheureusement, assez peu de gens utilisent des gestionnaires de mot passe et continuent à utiliser et réutiliser des mots de passe faibles. Donc malheureusement, c'est la réalité. Pour le reste, HIBP permet de télécharger la liste de l'intégralité des mots de passe pétés dont il dispose, donc ça fait un corpus sympa pour faciliter le boulot.
Aujourd'hui, il me semble que la reco c'est PBKDF2, comme l'a pointé Z<.
[^] # Re: Chaussures du cordonnier
Posté par Psychofox (Mastodon) . Évalué à 3.
Alors qu'une longue phrase c'est tellement plus facile et plus long à bruteforcer.
[^] # Re: Chaussures du cordonnier
Posté par brendel . Évalué à 2.
Du coup pour toi, le sel c'est fait pour éviter les attaques par bruteforce c'est bien ça?
[^] # Re: Chaussures du cordonnier
Posté par octane . Évalué à 5.
c'est surtout fait pour rendre la vie difficile à un attaquant.
A priori le service est là pour authent des users. Donc si on choppe la liste:
1/ on google les hashs, généralement on arrive à en casser un paquet car google a stocké des millions de hash avec leur clair
2/ on bruteforce
le calcul du hash prend un temps léger, la comparaison va vite. Si on a 100 hashs de users, alors on calcul 1 hash et on compare 100x.
Maintenant avec un sel:
-plus de cassage de hash avec google.
-le calcul du hash doit être fait autant de fois que de user (lire le sel, prendre le pass évalué, calculer le hash, comparer avec le hash. Reprendre step 1 pour le user suivant)
Et avec PBKDF2:
tu fais pareil, mais avec un facteur de temps de 1 million.
[^] # Re: Chaussures du cordonnier
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Oh, que oui. Y compris des trucs invraisemblables. Je te laisse chercher ce MD5
290b284d9e401b0a1b25ddb281cf5bf0ou ce SHA-1b19e461aeaba1172b26b552471f56405e1928d17.La connaissance libre : https://zestedesavoir.com
[^] # Re: Chaussures du cordonnier
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
Génial!
[^] # Re: Chaussures du cordonnier
Posté par brendel . Évalué à 4.
Allez je re-répond pour noter que je sais pas ou on est pour que ce genre de réponse soit accepté. Il me semble que usuellement sur les sites de discussion on a le droit de poser une question si simple fut-elle sans se faire rembarer comme une sous-merde (d'autant plus quand c'est pour se voir dire que "oui une attaque contre sha2 existe : le bruteforce!", mais c'est pas la question).
[^] # Re: Chaussures du cordonnier
Posté par aiolos . Évalué à 4.
En gros, les SHA sont conçues pour être le plus rapide possible tout en étant très difficiles à inverser ou même à simplement trouver une collision. La seule solution pour "casser" un mot de passe est donc plus ou moins la recherche exhaustive, qu'on raffine avec un time-memory tradeoff sous la forme de rainbow tables.
L'idée derrière l'utilisation de fonctions de hachages dédiées au stockage des mots de passe, de type bcrypt, est d'avoir une fonction de hachage bien plus lente à calculer qu'un simple SHA. Ça permet de ralentir beaucoup les attaques par recherche exhaustive ; l'impact sur l'usage n'est pas si important puisque côté serveur tu ne le calcule pas ou une seule fois, et côté client une fois de temps en temps.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . Évalué à 1. Dernière modification le 07 août 2018 à 11:14.
Pour le côté serveur, ca dépend du nombre de connexion à gérer en même temps. Si justement c'est un gros site avec pas mal d'auth à faire en simultané, ca doit quand même utiliser pas mal de ressources, non ?
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par khivapia . Évalué à 8.
L'idée de ces fonctions c'est normalement qu'elles sont "réglables" en termes de ressources demandées.
Dans le cas de PBKDF + SHA2, les ressources impliquées sont du calcul (très peu de données, juste celles nécessaires au calcul de la fonction de hachage), c'est réglable avec le nombre d'itérations effectuées.
Les fonctions plus modernes comme Argon2 utilisent à la fois des ressources en calcul et en mémoire (forçant à conserver en mémoire une partie (réglable) des calculs effectués jusqu'à la fin). Ceci est très gênant pour des attaques force brute : plus que les ressources de calcul qui ont évolué (ou peuvent évoluer allant jusqu'à fondre des composants dédiés), les contrôleurs mémoire ont beaucoup évolué pour le débit mémoire mais assez peu pour la latence et les accès aléatoires.
Autrement dit : si avec un GPU on peut calculer beaucoup de hachés SHA256 ou Blake2 par seconde, on a très peu de mémoire cache et une forte latence mémoire (même si on a un gros débit mémoire). Du coup, on ne peut pas calculer tant que ça de hachés Argon2 par seconde.
In fine, il faut bien adapter le coût de la solution de sécurité au besoin de sécurité. Argon2 est flexible de ce point de vue.
[^] # Re: Chaussures du cordonnier
Posté par groumly . Évalué à 2.
Un login, c’est pas quelque chose que tu fais souvent. Login hein, pas validation de token/cookie de session (ou que sais je).
Même avec des centaines de login (réellement) concurrent, ce qui représente déjà un traffic plus que consequent, ça fait au final pas grand chose comme charge cpu.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Chaussures du cordonnier
Posté par modr123 . Évalué à -2.
si tu as acces a la bdd ca change quoi ?
tu cree un comptes tu changes le hash du compte que tu veux volé par ton hash et tu as le mot de passe
et tu remet apres une fois que tu as finis
[^] # Re: Chaussures du cordonnier
Posté par claudex . Évalué à 5.
Si tu as accès à la BDD et que le mot de passe est réutilisé, tu peux aussi utiliser pour te logger sur d'autres comptes. Ensuite, tu peux avoir accès à la BDD en lecture seule (via un backup par exemple).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Chaussures du cordonnier
Posté par Christie Poutrelle (site web personnel) . Évalué à 5. Dernière modification le 06 août 2018 à 18:27.
D'où l'importance du salt pour créer un hash du mot de passe. Avec un salt au niveau global, ça évite uniquement l'attaque par rainbow table, car il y a peu de chances que ton hash salté corresponde à d'autres déjà craqués et disponibles dans le jean-cloude, mais par contre n'a n'évite pas l'attaque brute force sur la base complète, qui à terme te permet en théorie de trouver l'intégralité des mots de passe de la base. Pour ça, il faut un salt différent par mot de passe de ta base (si le salt est stocké en clair, c'est pas grave), car dans ce contexte, même avec la base de donnée, pour retrouver l'ensemble des mots de passe il te faut temps potentiellement infini, car il faut mener une attaque très longue multiplié par le nombre de mots de passe dans la base, vu qu'ils ont tous un salt différent.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . Évalué à 1.
Est-ce que ca permet de le faire en un temps raisonnable ? Si le bruteforce trouve les mdps en 15 ans, ca me dérange pas. J'en aurai changé d'ici là.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Christie Poutrelle (site web personnel) . Évalué à 5. Dernière modification le 07 août 2018 à 09:40.
Cet article est assez ancien maintenant, mais je recommande chaudement sa lecture attentive, et jusqu'au bout https://crackstation.net/hashing-security.htm
Il y a des tas d'autres ressources pour ça, la réponse ici est aussi très intéressante: https://stackoverflow.com/questions/11624372/best-practice-for-hashing-passwords-sha256-or-sha512
D'ailleurs, tu remarqueras qu'aucun outil libre orienté web n'utilise SHA depuis bien longtemps pour le password hashing.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . Évalué à 2.
Merci pour la doc.
Bah en fait, si, SOGo par exemple.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Christie Poutrelle (site web personnel) . Évalué à 2.
Alors ils sont un peu en retard.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . Évalué à 3.
Ce ne sont pas les seuls, j'en avais rencontrés plusieurs dans ce cas là quand je regardais les groupwares existants. Les sha sont en fait les algo que j'ai vu le plus souvent proposés par les services web à auto-héberger. Souvent il y en a d'autres de proposés, dont md5, et plus rarement d'autres choses plus sécurisé.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Psychofox (Mastodon) . Évalué à 6.
On ne sait toujours pas qui tu accuses de quoi ? Tu sous-entends que l'auteur de ce journal n'applique lui-même pas cette politique de ne pas utiliser des algorithmes de hashage de mots de passe ?
[^] # Re: Chaussures du cordonnier
Posté par Philip Marlowe . Évalué à 10.
Zenitram a dû beaucoup sécher les cours d'expression écrite dans sa prime jeunesse. Ce qui fait que parfois il peut dire des choses intéressantes, mais qu'on ne peut pas en être sûr du premier coup. Il faut souvent des explications annexes, malheureusement encore trop fréquemment cryptiques. Sans compter qu'il a ses idées fixes et ses phobies. Le barbu en est une. Certainement un cas passionnant pour un psychanalyste.
[^] # Re: Chaussures du cordonnier
Posté par wilk . Évalué à 4.
Je sais pas vous mais je ne suis pas sûr non plus de stocker mes propres idées en clair dans ma tête. C'est pour ça qu'on cause d'ailleurs, dans l'espoir qu'un interlocuteur aura la clé de décryptage.
[^] # Re: Chaussures du cordonnier
Posté par Philip Marlowe . Évalué à 3.
D'accord avec votre affirmation (ne pourrions-nous nous tutoyer ?) mais il y a une différence entre des idées non encore ordonnées, en instance de clarification, et des affirmations péremptoires assénées de façon amphigourique.
[^] # Re: Chaussures du cordonnier
Posté par Big Pete . Évalué à 1. Dernière modification le 06 août 2018 à 17:34.
Visiblement il en a après l'IETF qui utilise GNU/mailman (un truc de barbus) pour ses lists et du coup, le mot de passe est échangé en clair par mail. Voir http://www.list.org/mailman-member/node15.html
C'est juste que comme normalement on s'inscrit par mail à ce genre de système, de toute façon, si il y a un mot de passe t'es bien obligé de lui envoyé a un moment donné. Du coup, c'est pas sur, mais c'est pas grave, c'est juste pour gérer l'abonnement à une ML. Bon après si tu utilise ce même mot de passe sur ton compte en banque ou pour le contrôle de la force de dissuasion nucléaire de ton pays, ça craint, effectivement.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Chaussures du cordonnier
Posté par claudex . Évalué à 3.
Il n'empêche que c'est une pratique dégueulasse. Et qui fait que je n'utilise pas mailman. Même si effectivement, ce n'est pas critique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Chaussures du cordonnier
Posté par Big Pete . Évalué à 10. Dernière modification le 07 août 2018 à 09:50.
Cette histoire, c'est surtout un très bon exemple du problème que l'on peut avoir avec la sécurité en général. A mon avis, beaucoup de personne on du mal a comprendre que la sécurité, ce n'est pas un produit, un logiciel ou même seulement une question de bonnes pratiques. C'est surtout une démarche visant a évaluer les risques associé a une activité et prendre des mesures visant à le réduire. C'est une des raison pour lequel il parait normal a tout le monde de ne pas porter de casque en voiture ou a pied, alors que cela semble évident lorsque l'on fait de la moto.
Pour ce qui est de mailman, si tu pars du cas d'usage, il s'agit juste de gérer son abonnement à une liste de messagerie publique.
A la base sur ces listes, il suffisait généralement d'envoyer un mail avec subscribe ou unsubscribe et "pouf" tu étais abonné ou désabonné. Bon compte tenu de la nature du mail et de l’extrême facilité de falsifié son adresse d’émetteur, il y a forcément des petits malins qui se sont amusés à désabonner des gens suite, par exemple, à une discussion un peu houleuse.
Du coup, l'idée est venue naturellement de mettre en place un système de mail de confirmation. Il y a encore beaucoup de liste qui sont comme ça. Mais le truc c'est qu'en cas d'abus l'utilisateur reçoit des mail de confirmation alors qu'il n'a rien fait, et ça l’inquiète. Comme il ne comprend pas, il est tenté d'envoyer un mail à l'admin de la liste pour éclaircir la situation. Bon, quand tu gère des listes par centaine avec des dizaines de milliers d'abonnés, c'est le genre de truc qui fini par devenir pénible.
Viens alors l'idée d'envoyer un code lors de l'inscription du type, qu'il doit spécifié pour valider une demande de désabonnement par la suite. Aucun intérêt à le stocker sous forme de hash, de toute façon tu es bien obligé de l'envoyer par mail. Bref, le seul tord de mailman, à mon avis dans cette histoire, c'est d’appeler ça un mot de passe. Il suffirait, je pense, de l’appeler "référence d'abonnement" pour éviter le genre de mal-entendu à l'origine de cette discussion.
Pour ce qui est de la sécurité du mail, il n'y a pas vraiment d'alternative à GPG, a mon avis. Mais bon, si il faut sortir l'artillerie lourde pour juste gérer son abonnement à une ML qui est de tout façon publique, ça n'a pas trop d’intérêt, ce serait juste chiant comme le serait le fait de porter un casque de moto en voiture. Cela aurait surtout de l’intérêt quand tu veux assurer de ton identité réelle les autres membres de la liste. Pour gestion de l'abo, un code donné à l'inscription suffit pour éviter les abus, dans la très grande majorité des cas.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Chaussures du cordonnier
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 07 août 2018 à 10:04.
OK.
L'erreur de Free à l'origine du journal aussi donc (c'est juste pour gérer l'abo de Free, c'est bon arrêtez avec votre sécurité, ayez une démarche visant a évaluer les risques associé a une activité et prendre des mesures visant à le réduire, vraiment…)
Note : le pass de Mailman n'est pas une référence, car il est personnalisable (on peut désactiver la personnalisation mais peu le font). pass qui peut être réutilisé par l'utilisateur ailleurs, donc la faille est dans le "pas important" qui est un jugement qui ne prend pas en compte les usages et dont la réalité n'est pas connue : ce qu'on fait fuiter est peut-être important, tu ne sais pas)
C'était tout le sens de mon commentaire initial : le problème à la base n'est pas Free, mais la tonne de gens qui pensent qu'on peut mettre les pass en clair suivant des critères arbitraires non vérifiables (genre "ce n'est pas important" alors qu'on ne sait pas où se balade ce pass ailleurs), et qui font de l'analogie avec des casques chiants alors que saler et hasher un pass n'est pas le plus chiant à faire quand même, ça n'emmerde personne à part un peu de code à faire. Les réponses ici ne font que confirmer la problématique sur la sécurité des pass, et légitime la gestion des pass par Free. C'est "juste" étonnant que les gens ne répondent pas directement à l'auteur du journal pour lui dire "non, mais arrête ton char, ça va ce n'est pas important c'est une gestion de compte et c'est tout".
Bref, on a une sacrée éducation à faire chez les "passionnés" déjà pour avoir un discours cohérent avant d'aller titiller les entreprises… Certes, on peut faire les deux en même temps, mais il ne faut pas oublier que quand on essaye de parler à Free ils pourront avoir comme réponse "c'est juste pour gérer l'abo, la sécurité est adaptée" pas facile à combattre vu que pas mal de passionnés ont ce discours.
[^] # Re: Chaussures du cordonnier
Posté par Big Pete . Évalué à 5.
Bon, peut-être qu'on se comprend mal. Mais de toute façon tu communique avec mailman par mail. Il faudrait être idiot pour lui envoyé un mot de passe de compte en banque, et cela indépendamment du fait qu'il soit stocké sous forme de hash coté mailman. Il va se retrouver en clair sur un tas de serveur de mail sur le chemin, dans le dossier "envoyé" de compte imap, sur ton disque dur, etc …
Dans le cas d'une application web, c'est différent, on envoie le mot passe via un canal sûr (comme https) et il se retrouve sur le serveur uniquement en mémoire le temps de calculer le hash. Dans ce use case le mot de passe n'est normalement jamais stocké en clair dans une mémoire de masse, et tu peux garantir un certain niveau de sécurité en te basant sur le principe (souvent faux malheureusement) que ce mot de passe n'est stocké que dans le cerveau de son utilisateur.
Après, si tu veux que je te réponde au sujet de la croisade que tu mènes contre les geek barbus qui ferais mieux de s'occuper de leur barbes plutôt que de chercher des poux dans celle des autres, j'avoue que cette question ne m'intéresse pas et que je n'ai pas particulièrement d'avis pertinent à défendre sur le sujet. Cela fait quelque temps déjà que je ne joue plus personnellement au chevalier errant des internets.
Cette discussion m’intéresse uniquement car elle me parait être révélatrice d'un problème de compréhension du concept même de sécurité en tant que processus d'analyse/réponse à des risques, sujet qui me tiens un peu à cœur.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Chaussures du cordonnier
Posté par claudex . Évalué à 5.
Oui, je suis bien au courant qu'il faut prendre en compte la probabilité d'occurence et l'impact. Mais même en les prenant en compte, ça n'est toujours pas acceptable. Surtout que le hash de mot de passe, c'est "gratuit". Il y a plusieurs qui font que ce n'est pas une bonne idée, même si le transport est en clair (la bonne pratique de hacher les mots de passe existait déjà du temps où tout le monde faisait de l'HTTP). Tu peux toujours avoir le cas de la personne qui ne sait pas que le mail est en clair et utilise le mot de passe de sa banque ou de quelqu'un de distrait. En plus, ça donne l'habitude aux gens d'avoir le mot de passe en clair, ce qui n'est pas une bonne chose.
Quand le contournement est aussi simple que hacher un mot de passe, il n'y a pas d'excuse. On ne demande pas de stocker les données dans une DB chiffrée avec un HSM.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Chaussures du cordonnier
Posté par Big Pete . É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.
[^] # Re: Chaussures du cordonnier
Posté par claudex . Évalué à 5.
Ce n'est pas parce qu'il est transmis par mail qu'il est lisible par tous. D'ailleurs, il y a plus de chance que quelqu'un tombe sur la base de mot de passe qu'il ait accès à tous les mails qui circulent à destination du serveur l'hébergeant. Donc, ce n'est pas une protection dans le vide.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Chaussures du cordonnier
Posté par Zenitram (site web personnel) . É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.
[^] # Re: Chaussures du cordonnier
Posté par groumly . Évalué à 4.
Le problème c’est pas tant le hash, comme tu l’as clairement expliqué, mais plutôt d’appeler ça un mot de passe, voire carrément de permettre à l’utilisateur de le choisir en premier lieu.
Ca rend les gens confus, et va en tenter plus d’un de réutiliser leur bon vieux mot de passe favori.
C’est un autre aspect de la sécu ça, accepter que les humains sont d’une part fainéant et d’autre part font des conneries consciemment, et prendre ça en compte dans le design.
On a beau répéter aux gens des dizaines de fois de pas réutiliser les mots de passes, on a maintenant quelques décennies d’experience sur des centaines de millions de personnes qui nous prouvent que, Ben si, en fait, ils les réutilisent et plutôt 2 fois qu’une (en plus de choisir des mots de passes à la con).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Chaussures du cordonnier
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 06 août 2018 à 17:48.
Du coup pour Free, c'est pas sur, mais c'est pas grave, c'est juste pour gérer l'abonnement à chez toi et ça n’intéresse pas foule.
C'est justement le soucis : vous décidez alors de ce qui est grave ou pas, en fonction de vos critères. Qui ne sont pas le mêmes que les autres.
En disant "c'est pas grave" pour X, vous légitimez que Free n'a pas de raison de changer.
Soyez cohérents, si vous acceptez votre jugement pour quand il faut chiffrer ou pas, acceptez le jugements d'autres.
"rigolo" cette façon de conspuer une entité et pas une autre pour exactement le même soucis, suivant que l'entité plaît ou pas.
Bref, le soucis n'est pas Free, qui n'est qu'une conséquence de discours "c'est pas grave" à d'autres endroits. Le soucis et que pas mal de monde dit que ce n'est pas grave dans les cas qui leur plaisent, alors que la réponse devrait de toujours chiffrer (non reversible, salé…), car on ne sait pas ce que l'utilisateur utilise comme pass (le même à d'autres endroits? Et même, on n'a pas à connaître un pass point). Ici, la réaction peut être que si des geeks qui développent Mailman, et des utilisateurs geek de Mailman trouvent ça pas dérangeant, pourquoi devrais-je faire mieux alors que j'ai des données pas bien plus importantes (de mon point de vue, le votre n'a pas d’intérêt)?
Ma critique initiale est que le journal devrait se concentrer plus sur l'origine du problème qu'un n-ième exemple pas bien méchant (à peine plus que mailman) de conséquence, si l'idée est d'apporter une pierre à l'édifice. Ici, on ne fait que se faire plaisir à attaquer un "méchant pas gentil" en évitant soigneusement de toucher au fond du problème (le fait que pas mal de monde trouve normal de stocker des pass en clair, même des moules LinuxFr).
[^] # Re: Chaussures du cordonnier
Posté par Big Pete . Évalué à 3.
Mais non, de la manière dont je comprend le pb, dans le cas de mailman, c'est le canal de transmission qui est en clair (le mail). Du coup, même si tu ne stocke pas le mdp en clair, il faut quand même l'envoyé via un canal non sécurisé (le pire de tous, le mail). du coup pour la securité du mot de passe c'est mort, de toute façon.
Bon après, ils pourraient faire le choix de ne pas proposé de gérer l'abonnement par email, mais uniquement via une autre interface style https. Ce serait plus sur, mais ce n'est pas équivalent du point de vue fonctionnel.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Chaussures du cordonnier
Posté par Psychofox (Mastodon) . Évalué à 3.
C'est qui vous ?
[^] # Re: Chaussures du cordonnier
Posté par Sufflope (site web personnel) . Évalué à 3.
Bah déjà au moins
(16 moinseurs du message original U 7 moinseurs du second).[^] # Re: Chaussures du cordonnier
Posté par eingousef . Évalué à 3.
et m…!
Je reviens, je dois faire un truc _o/
*splash!*
[^] # Re: Chaussures du cordonnier
Posté par Big Pete . Évalué à 2.
Tu devrais. Perso j'en ai une, c'est très pratique pour le stockage. C'est un genre de cloud poilu. Je met mes mots de passe dedans, entre les miettes de sandwich imbibées de bière.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Chaussures du cordonnier
Posté par syntaxerror . Évalué à -2.
Le mot de passe mailman… comment dire? non rien!
# ton mot de passe, mais pas que
Posté par syntaxerror . Évalué à 2.
Free renvoie son mot de passe à l'abonné, mais aussi tous ceux des comptes secondaires associés (par exemple, les membres de la famille)
# C’est Free, mais c’est pas grave
Posté par Arthur Accroc . Évalué à 10.
Free a aussi longtemps traîné les pieds avant de mettre en place le chiffrement pour POP/IMAP, mais ça, quand même, ils ont fini par le faire.
Par contre, pour mettre à jour sa page web, c’est toujours FTP — pas de sftp ou FTPS — ou http (pas de https non plus !).
Évidemment, pour les consulter, pas de https.
Et dernièrement, Free s’est fait pointer comme un des gros acteurs à ne pas avoir mis en place le chiffrement des communications entre serveurs SMTP.
Manifestement, la sécurité des mots de passe et la confidentialité des données des utilisateurs, ce n’est pas leur priorité.
Cela dit, il y a une cohérence : si tu mets à jour ta page web à distance, et que tu te fais sniffer ton mot de passe, c’est moins grave qu’il soit stocké en clair chez Free…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: C’est Free, mais c’est pas grave
Posté par modr123 . Évalué à 1.
et orange c'etait mieux ?
quand tu te connectait via ta connexion pas besoin de mot de passe pour acceder a ton compte
si tu as le wifi sans mot de passe et bien tout le monde se connectant a ta connexion avait acces a tes couriers
[^] # Citron
Posté par Arthur Accroc . Évalué à 6.
Fan de Free ou déçu d’Orange ?
Je n’ai jamais dit ça.
Le lourd passif d’Orange (dont je n’ai malheureusement pas retenu tous les détails, mais j’ai par exemple retrouvé ça) me dissuade de passer chez eux. Peut-être cela s’est-il amélioré, mais jusqu’à quel point ?
Chez Free, ce sont les choix techniques fournis à l’utilisateur qui sont discutables. Chez Orange, c’est souvent l’implémentation qui a péché.
Autant il sera facile de voir si les choix techniques de Free s’améliorent, autant on pourra toujours douter de la sécurité de l’implémentation chez Orange.
Cela dit, tu as surtout parlé de problèmes passés chez Orange. Si tu es au courant de problèmes actuels, rien ne t’empêche de faire un journal, comme modr123… Un historique des problèmes passés pourrait être intéressant aussi.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Citron
Posté par modr123 . Évalué à 3.
le mot de passe c'est aussi en clair chez orange mais par la poste ou sms :)
je n'ai pas le wifi chez moi donc jamais concerné par ça
# Le tec aussi
Posté par Philippe M (site web personnel) . Évalué à 10.
Dernièrement j'ai eu l'intervention d'un technicien free chez moi. Je regarde avec lui les résultats des tests et mesures sur son téléphone (celui de free). A un moment il passe sur une page contenant mes infos de ligne mais aussi infos de dossier et surprise ma clé wifi visible comme ça. Je lui fais la remarque sans le mettre en cause et il me dit qu'effectivement c'est pas top niveau confidentialité.
Donc les tech peuvent collecter toutes les clés wifi des clients chez qui ils interviennent… J'ai trouvé ça très moyen :(
Born to Kill EndUser !
# Autre possibilité ?
Posté par TilK . Évalué à 2.
Il pourrait y avoir une autre possibilité :
Leur base pourrait contenir ton mot de passe hashé (pour l'authentification) ainsi qu'une version chiffrée en utilisant comme clef la réponse à ta question secrète (utilisé lorsque l'on perd son mdp).
De cette façon, le mot de passe n'est pas stocké en clair, ni la réponse à ta question secrète (qui au niveau sécurité est aussi importante), et ils ne peuvent pas retrouver ton mot de passe sans une intervention de ta part (livraison de la réponse à la question secrète).
On pourrait rajouter également un sel à ton mot de passe pour valider légèrement ta réponse à la question secrète : lorsque l'on décode ton mot de passe avec la réponse, si la solution ne contient pas le hash, cela veut dire que la réponse à la question secrète est fausse.
Je me doute qu'il y a pas de chances que ce soit implémenté de cette façon, mais je me demande qu'elle serait alors la sécurité de cette solution. Des idées ?
[^] # Re: Autre possibilité ?
Posté par oinkoink_daotter . Évalué à 10.
Les questions secrètes ça devrait être interdit (un peu comme MD5, et non, pas de "oui mais"). En plus d'avoir une entropie de merde et reposer sur des informations publiques, ça pose des problèmes d'encodage, de majuscules, etc. Du coup faut normaliser, du coup encore moins d'entropie, etc.
Cela posé, le problème de ta solution, c'est que tout repose sur ta question secrète, sécurité du maillon le plus faible, toussa. Si qqn met la main sur la base, c'est encore plus facile de bruteforcer le mot de passe chiffré car l'entropie de ce qui a servi à chiffrer est vraiment pourrave. Par exemple si la question est la ville de naissance de quelqu'un, tu as une très grande chance que ce soit une des 30000 communes françaises. Si la question est une date de naissance, tu as, à la grosse, 36525 possibilités si c'est tapé sous la forme xx/yy/zzzz.
Du coup, on peut envisager un autre mot de passe dans les réponses aux questions secrètes :-).
[^] # Re: Autre possibilité ?
Posté par mahikeulbody . Évalué à 4.
Quand je ne peux éviter les questions secrètes, je fournis des réponses qui n'ont rien à voir avec la choucroute (genre "plat préféré" réponse "bleublancrougeX1Y234") et, bien sûr, je les décris dans une note de l'entrée keepass correspondante.
Ce qui revient à mettre un autre mot de passe dans les réponses secrètes, comme tu le suggères.
[^] # Re: Autre possibilité ?
Posté par kna . Évalué à 6.
Alors, oui, si la question secrète seule te permet de récupérer ton mot de passe, c'est mal… Mais tu peux avoir le cas où la question secrète ajoute une sécurité en plus.
Typiquement, la plupart des services te permettent de t'envoyer un nouveau mot de passe par mail si tu perds ton mot de passe. Chez certains (par exemple Gandi), ils te demandent la réponse à la question secrète pour t'envoyer un nouveau mot de passe. Du coup, pour récupérer un mot de passe, il faut que tu aies à la fois accès à la boite mail de contact et que tu connaisse la réponse à la question secrète.
Dans ce cas précis, ça me parait pas déconnant. Et c'est même plus securisé que te renvoyer un mot de passe via un simple clic sur « Mot de passe perdu ».
# Les mdp chiffrés ne permettent pas les protocoles d'authentification interactive classiques
Posté par benoar . Évalué à 10.
À chaque fois c'est le même débat qui tourne en boucle, sans jamais personne qui n'ait réellement eu entre les mains un tel système à gérer…
Avoir des bases de mot de passe chiffrées empêche toute authentification interactive « classique », qui permet de ne pas faire circuler le mot de passe sur le réseau, genre CHAP (rappelez-vous que Free à la base offrait des accès RTC où on s'authentifier avec du CHAP sur PPP…). Idem pour toute authentification interactive incluse dans EAP, pour reprendre un protocole un peu plus moderne. C'est également, je pense, une raison pour laquelle les gens semblent aimer le LDAP qui impose la méthode d'authentification avec une méthode de hashage fixée, et ne permet pas l'authentification interactive comme le permettrait RADIUS, qu'on mettrait normalement devant un LDAP.
Certes, aujourd'hui pour palier à la non-confidentialité des protocoles de vérification de mot de passe faisant passer le secret en clair comme PAP et pratiquement toutes les authentifications web « modernes », on ajoute du TLS en dessous et « tout va bien » ; c'est valable aussi bien pour le web que pour tout un paquet d'autres protocoles (comme EAP-TLS pour celui cité ci-dessus). Mais ces protocoles d'authentification sans gestion de la confidentialité étaient à l'origine pas très bien vus, et tous basés sur le principe de partage de secret identique, sans challenge.
Sans parler du fait qu'il existe des protocoles modernes (d'ou mon qualificatif de « classique » utilisé plus haut, par opposition) basés sur les mot de passe fait expressément pour ne pas avoir de base en clair, comme SCRAM https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism mais que tout le monde a l'air de s'en foutre.
Et bien sûr, tout cela en évitant l'éléphant dans la pièce : pourquoi a-t-on toujours autant d'histoires de mot de passes, avec une croissance et une complexité grandissante dans leur gestion, quand depuis des décennies on annonce l'avènement de l'authentification par cryptographie asymétrique ?!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.