Mot de passe en clair dans un email, SSLv3 : EBP s’explique
La CNIL en PLS
Pour assurer la sécurité de vos mots de passe, la CNIL recommande aux services en ligne de ne pas les stocker et de leur préférer une « empreinte » (ou hash). Mais nombreux sont ceux qui n'en font qu'à leur tête comme Free ou encore EBP. Contacté par nos soins, ce dernier s'explique et annonce du changement.
Sur Internet, les fuites de données personnelles sont malheureusement monnaie courante et les causes peuvent être multiples. S'il n'est pas possible de garantir une sécurité absolue, les sites et services doivent respecter certaines règles afin de limiter les dégâts en cas de problème.
La CNIL recommande de stocker une empreinte, EBP et Free ne le font pas
L'une d'elles concerne la conservation des mots de passe. Ce dernier ne doit ainsi jamais être stocké, et surtout pas en clair. La CNIL explique ainsi qu'il « doit être transformé au moyen d’une fonction cryptographique non réversible et sûre, intégrant l’utilisation d’un sel ou d’une clé ».
On parle ainsi d'une empreinte, qui permet au site de vérifier que vous tapez le bon mot de passe lorsque vous tentez de vous connecter, sans avoir à le stocker. C'est cet élément que récupèreront les pirates en cas de fuite. Ils ne pourront donc normalement pas retrouver votre mot de passe original (c'est pour cela que l'on parle de fonction non réversible).
Problème, certains n'appliquent toujours pas cette règle de base qui ne date pourtant pas d'hier. Fin 2012 déjà, nous avions tiré la sonnette d'alarme sur le sujet. Si le sujet revient sur le devant de la scène de manière récurrente, deux sociétés françaises sont à leur tour pointées du doigt pour une telle pratique : EBP et Free.
La méthode simple pour savoir si une société stocke ses mots de passe de manière réversible est d'utiliser la fonctionnalité de mot de passe oublié. S'il vous est renvoyé par email, c'est forcément le cas. Il transitera d'ailleurs en clair à travers différents serveurs et sera stocké dans votre boite email si vous ne faites pas attention à supprimer le message.
Voici des captures d'écran des deux mails reçus dans les deux cas qui nous occupent aujourd'hui :
Silence radio chez Free, EBP assume et s'explique
Nous avons évidemment contacté les deux sociétés afin d'avoir des explications sur ce point. Pour le moment, Free n'a pas souhaité répondre à nos questions, contrairement à EBP avec qui nous avons pu échanger sur le sujet.
La société nous indique qu'il s'agit d'un choix délibéré, mais qu'un changement est en cours. Elle précise qu'elle ne stockait qu'une empreinte du mot de passe auparavant, mais qu'elle a décidé de changer son fusil d'épaule il y a environ un an : « nos clients – surtout des TPE/PME – avaient du mal à faire réinitialiser leur mot de passe. On avait pas mal de demandes au service technique ».
Une explication que l'on retrouve souvent sur cette question. En effet, l'utilisateur préfère en général disposer d'une option facile pour retrouver un mot de passe qu'il oublie souvent. Le recevoir par email sur simple demande a beau être un « drame » en terme de sécurité, il a l'avantage d'être rapide. EBP a donc fait le choix de « privilégier l'aspect client à l'aspect sécurité ».
Si le mot de passe en clair est stocké sur ses serveurs, il est chiffré précisent nos interlocuteurs. Pour cela, EBP utilise l'algorithme RSA avec une clé sur 2048 bits, combiné avec une procédure maison. « On ne chiffre pas que le mot de passe, on met d'autres informations, qui n'ont rien à voir avec le client ou qui sont en relation avec le client. Cela permet d'avoir un mot de passe assez complexe même si celui du client est assez simple ce qui permet d'éviter les attaques par force brute » nous explique le directeur des systèmes d'information (DSI).
Problème, dans le cas où la base de données et les clés tombent entre de mauvaises mains, ou bien en cas de problème sur les serveurs d'EBP, les mots de passe en clair peuvent être récupérés. « C'est bien la faiblesse du système » confesse notre interlocuteur.
Mais va changer de procédure pour ne stocker que des empreintes
Suite aux recommandations du 27 janvier de la CNIL « on s'est reposé la question » et la décision a été prise « d'arrêter d'envoyer les mots de passe en clair », cela passera par une procédure permettant d'en créer un nouveau. D'ici deux semaines cela devrait être en place.
Les responsables nous confirment au passage que tous les mots de passe chiffrés qui sont actuellement dans les bases de données seront effacés et remplacés par des hash générés via un algorithme irréversible.
Quid de SSLv3 et RC4 toujours supportés par le site ?
Comme l'ont remarqué certains sur Twitter, EBP accepte encore de (très) vieux protocoles sur son site, alors qu'ils présentent pourtant des risques importants pour la sécurité à cause de la présence de failles. Nous pouvons ainsi citer SSLv3 et RC4, deux protocoles pour lesquels l'IETF a émis des notices d'informations en 2015 pour expliquer clairement qu'ils ne devraient plus être utilisés (voir ici et là).
Là encore, la réponse des responsables est dans la lignée de celle pour les mots de passe : « Quand on a fait une tentative sur un site annexe pour enlever SSLv3 on s'est aperçu qu'on avait encore beaucoup de clients qui avaient des navigateurs de type Internet Explorer 8 ou 9 qui n'avaient pas le niveau de patch nécessaire, et ça nous posait des problèmes ». Encore une fois, il s'agit donc de faire passer l'aspect client avant celui de la sécurité.
La décision a donc été prise de conserver SSLv3 et de refaire des mesures périodiquement (tous les six mois par exemple) afin d'évaluer le terrain. Pour résumer, « on a bien en tête que SSLv3 doit être supprimé, mais pour l'instant on rencontre un peu de difficulté avec certains clients » nous explique EBP. La situation est exactement la même pour le protocole RC4.
« On ne peut pas couper les clients »
Nous avons alors demandé si la société faisait ou comptait faire de la prévention ou de l'éducation auprès de ses clients afin de les informer des risques et de les pousser à migrer. « Oui, on essaye de les éduquer, mais c'est très difficile et on ne peut pas les couper », surtout lorsqu'ils génèrent encore un trafic important sur le site.
Comme toujours en pareille situation, c'est malheureusement le maillon le plus faible de la chaine qui définit le niveau de sécurité de l'ensemble. Les autres clients sont prévenus.
Commentaires (181)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 10/02/2017 à 16h37
Mais c’est pas du bon hachage, même en dehors du cadre de la sécurité.
" />
Pour compléter mon message, un exemple de hachage simple d’un seul caractère serait de coder le caractère par la longueur des traits qui le compose (avec une certaine police/taille). Avec cette méthode, il y a peu de chance d’avoir des collisions (ou alors on peut trouver/créer une police qui n’en crée pas), l’empreinte est facile à mesurer si on connaît le caractère, par contre si je donne une empreinte (une longueur) il n’est pas possible de savoir à quel caractère elle correspond sans réaliser une attaque par bruteforce (se taper le calcul de l’empreinte pour chaque caractère jusqu’à trouver le/un bon).
Après si on limite la taille de l’empreinte, et qu’on autorise une taille infinie en entrée, il y a aura en effet forcément des collisions (mais, j’insiste, ce n’est pas que pour cette raison que c’est non inversible). Mais pour avoir une bonne fonction de hachage il faut alors qu’elle soit homogène (qu’elle réduise les risques de collisions).
Le 10/02/2017 à 16h40
Ce n’est pas à moi qu’il faut expliquer tout ça, je le sais :-) . J’ai juste foiré sur l’histoire de trouver plein de mots de passe qui correspondraient au hash, alors qu’il en suffit d’un seul.
J’expliquais le côté non inversible avec un exemple le plus simple possible. C’est évident que les collisions sont nombreuses sur un seul octet à l’arrivée :-) , et que la fonction est triviale (si je te donne un hash tu trouves très rapidement une chaîne qui convient).
Le 10/02/2017 à 17h08
Le 10/02/2017 à 17h23
Le 10/02/2017 à 17h38
Le 10/02/2017 à 18h22
Le 10/02/2017 à 18h39
Et je ne parle même pas de mon FAI (dont je tairai le nom parce que je ne veux pas qu’un petit malin s’y attaque
" />, juste que ce n’est pas en France) qui limite la longueur des mots de passe à 10 caractères sans aucun caractère spécial (minuscules, majuscules et chiffres uniquement)… Ça donne envie.
Quant à Free, pas surpris du tout. Je veux dire: y’a du SSL sur la page de login de Zimbra depuis quoi… 2 ou 3 ans, seulement ?
Le 10/02/2017 à 18h39
Le 10/02/2017 à 19h47
Le 10/02/2017 à 22h31
Sinon ceux qui veulent médire des sites gouvernementaux peuvent aller voir ici :https://www.openbugbounty.org/search/?search=gouv.fr&type=host
Le 11/02/2017 à 01h06
Bases de données client et tout
Le 11/02/2017 à 05h31
Le 11/02/2017 à 08h55
Le 11/02/2017 à 09h11
Le 12/02/2017 à 23h24
Free acceptes encore les connections POP3 et IMAP non sécurisées (ports 110 et 143) c’est à débattre de l’utilité de garder ces protocoles qui ne servent que pour la compatibilité avec des vieux organizers et autres non smartphones (et dans les entreprises qui bloquent le SSL), mais en attendant il est préférable que Free stocke les mots de passes en CLAIR !
En effet garder les mots de passes plutôt que leur empreinte permet de faire du challenge authentication et éviter de faire transiter le mot de passe lui-même sur le réseau.
Donc non le mot de passe en clair n’est pas le mal absolu, tout dépend du canal :
Canal sécurisé : On stocke l’empreinte mais le mot de passe sera transmis sur le réseau (osef le canal est sécurisé)
Canal non securisé: On stocke le mot de passe et on fait du challenge authentication pour eviter qu’il se balade en clair sur le réseau.
Le 13/02/2017 à 07h59
Le 13/02/2017 à 08h00
Le 13/02/2017 à 08h10
Le 13/02/2017 à 09h09
Des trucs genre CRAM-MD5
Wikipedia
Le 13/02/2017 à 09h18
ah, merci, je ne connaissais pas ce fonctionnement :)
effectivement, ça peut justifier d’avoir le MdP en clair en base, mais bon, quand on voit le nombre de bases de données volées ces derniers temps, ça fait quand même peur :(
Le 14/02/2017 à 08h26
Si j’ai bien compris ton explication: on n’utilise pas TLS/SSL donc on stocke le mot de passe en clair.
C’est pas la double peine ??
Déjà ta correspondance se balade à poil sur le réseau, mais en plus le jour où ton fournisseur se fait pirater, c’est openbar!!
Le 09/02/2017 à 15h47
Si le mot de passe est bidon, en cherchant le hash sur internet, tu le trouves .
" />
Pour cela que les bons systèmes collent au bout de ton mdp une chaine aléatoire (mais qui ne change que quand tu changes/génère ton mot de passe) et que toi tu ne voit pas..
Plus facile de trouver sur internet / dans des tables pré-calculées le hash de “toto” que le hash de “toto2d4fg09è|_9à@”{~#$*µ%!”
Le 09/02/2017 à 15h48
Je viens de comprendre comment tout ça marche
" />
Mais du coup, il peut y avoir des doublons? Par exemple avec ton exemple ABCDEF, FABCDE obtiendra le même résultat?
Le 09/02/2017 à 15h49
Arrêtez de vous prendre la tête, tout est expliqué ici…
https://blog.imirhil.fr/2015/10/27/stockage-mot-passe.html
Le 09/02/2017 à 15h50
Oui effectivement. Par contre, la chaine aléatoire, elle est bien stockée quelque part? Et donc “hackable”?
Le 09/02/2017 à 15h51
Problème des collisions, oui.
Sinon, l’article que vient de poster Aeris22 (#35) résume les bonnes pratiques.
Le 09/02/2017 à 15h55
Le fait que le sel (la chaîne aléatoire en question) soit connue ne représente pas de risque. Par contre, en crypto, ne réinventez pas la roue, et suivez aveuglément les conseils des experts (Aeris, en l’occurrence, est une source sûre)
Le 09/02/2017 à 15h55
Tu peux avoir le même hash pour plusieurs mot de passe donc tu ne peux pas déterminer à quoi correspond le hash.
Si ma fonction de hash remplace tous les A par des B mais replace aussi tous les C par des B, je pourrais avoir ABC -> BBB, ou CBA -> BBB du coup à partir de BBB, je suis incapable de déterminer si il a été généré à partir de ABC ou CBA. Bon c’est plus compliqué que ça mais c’est une fonction à sens unique. Si je te dis que ton hash c’est 1 et que je l’ai calculé avec cosinus tu ne peux pas ma dire si je l’ai calculé à partir de 0 ou 2pi ou n2*pi.
Bref je suis pas expert, mais si je dis pas de connerie c’est l’idée.
Le 09/02/2017 à 16h00
Oui bien entendu le sel est souvent stocké à coté du hash dans la base.
" />
" />
Mais déjà si il est propre à l’utilisateur cela complique la vie du mec qui a piraté la base.
Le simple fait de rajouter un sel complexe …. suffit à multiplier le temps et la puissance de calcul nécessaire pour le pirate.
Ce temps peut être mis à profit pour découvrir l’intrusion et demander aux utilisateurs de changer leurs mots de passe .. et rendre les efforts du pirate inutile vu qu’il va se retrouver avec des mdp qui ont changés
C’est difficile de faire un système inviolable, on fait tout pour gagner du temps
Le 09/02/2017 à 16h01
J’allais poster ton article ;-)
Le 09/02/2017 à 16h01
Le 09/02/2017 à 16h04
Le 09/02/2017 à 16h05
Le 09/02/2017 à 16h07
Là encore, la réponse des responsables est dans la lignée de celle pour les mots de passe : « Quand on a fait une tentative sur un site annexe pour enlever SSLv3 on s’est aperçu qu’on avait encore beaucoup de clients qui avaient des navigateurs de type Internet Explorer 8 ou 9 qui n’avaient pas le niveau de patch nécessaire, et ça nous posait des problèmes ». Encore une fois, il s’agit donc de faire passer l’aspect client avant celui de la sécurité.
C’est vraiment une excuse à la con… Un client, quelque soit son niveau, tu lui dis d’installer firefox pour venir sur ton site, il va pleurnicher 5 min et après ça va rouler… Et quand bien même tu en as encore 10 ou 15% dans ce cas, c’est pas une raison pour mettre 100% des clients en insécurité.
Et quand on voit les concessions qu’ils font sur un sujet aussi basique pour des raisons aussi bêtes, je n’ose pas imaginer l’état de leur SI ou du code face à la problématique du budget. Ca doit pas être beau à voir…
Le 09/02/2017 à 16h08
Je me tâte à modérer pour auto-promo
" />
Le 09/02/2017 à 16h09
Mot de passe en clair en 2017 ??
" />
C’est pas comme s’il y avait des fonctions/bibliothèques de crypto dans tous les langages.
Le 09/02/2017 à 16h09
Le 09/02/2017 à 17h57
>
Un peu leger, le fait de ne pas renvoyer le mot de passe en clair ne signifie pas que la société ne le possède pas tout comme le fait de l’ envoyer ne signifie pas qu’il est stocké en clair… :/
Le 09/02/2017 à 17h57
Le 09/02/2017 à 17h59
Arf message tronqué…
Je répondais à:
“La méthode simple pour savoir si une société stocke ses mots de passe de manière réversible est d’utiliser la fonctionnalité de mot de passe oublié”
Le 09/02/2017 à 18h13
ceux qui veulent privilégier la sécurité ont évidemment raison. Mais dans le monde, avoir raison ne signifie pas que ca se passe comme on voudrait
Comme souvent, il faut qu’il y ait un GROS truc qui se passe pour que les mises à jour se fassent (des piratages, par exemple)
C’est con mais ca marche pareil partout, quel que soit le sujet, en fait.
Et encore, la, je pense aux grosses boites, celles qui peuvent sans soucis claquer les 500K nécessaire à l’évol (prix au pif, mais disons qu’un consultant sénior coute 150K par an, multipliez en jour / homme selon la taille du projet, + cout d’infra)
Les PME qui n’ont pas prévu, bien qu’elles aient moins à dépenser car moins grosses mises à jour souvent, ne peuvent juste pas se permettre.
Encore une fois, je cherche pas à excuser, mais c’est un peu comme le terrorisme, je le redis, pour que ca bouge, c’est pas juste un règlement européen dont personne entendra parler (ou ne fera attention).
Faudra attendre de gros incidents, donc c’est bien les utilisateurs qui vont trinquer en premier. Comme actuellement, a chaque fois qu’on entend parler de fuite de données, en fait
Du coup, quelque part, remercions les boites qui effectivement veulent bien répondre comme EBP, et les gens qui pointent ce genre de faille. Mais je le redis, des clients comme Free par contre, ils en auront rien-à-carrer.
Le 09/02/2017 à 18h14
Le 09/02/2017 à 18h24
en parlant de passoire totalement scandaleuse …
https://www.ssllabs.com/ssltest/analyze.html?d=assure.ameli.fr
magnifique ^^
Le 09/02/2017 à 18h31
C’est pour ça qu’en plus le mot de passe est salé (d’ailleurs c’est bien precisé dans l’article que la CNIL recommande le salage).
Wikipedia
Donc ta base de donnée te permettra de récupérer le mot de passé salé, ce qui ne t’avance pas si tu ne connais pas le sel (qui normalement est géré à part). De plus même si tu connais la méthode de salage, ça rend inutilisable ta table arc-en-ciel (et sans table arc-en-ciel la force brute demande normalement des moyens qui ne sont à la portée que d’organisation type étatiques, soit en ayant un temps de calcul énorme à dispo, soit en ayant une quantité de mémoire gigantesque). Je te laisse lire ça :
D’autre part, comme le fait remarquer gogo77 les tables de hachages peuvent avoir des collisions (= même hash pour deux sources différentes). Le salage permet là aussi d’éviter qu’un mot de passe different soit utilisé avec le même résultat (la probabilité que 2 mots de passes aient la même empreinte avec un même salage étant encore plus faible que la probabilité d’une collision à la base, tu as plus de chances de rentrer le bon mot de passe au hasard du premier coup…).
De la même façon comme avec le salage 2 personnes ayant le même mot de passe ont un hash différent, ça évite les attaques fréquentielles (genre s’apercevoir que 20% des hashs sont identiques et les attaquer avec “qwerty” ou “12345678”.
Enfin ça évite également le repérage des faiblesses statistiques que tu évoques, puisque même s’il y en a une (et en général elles sont chaudes à mettre en oeuvre, sinon l’algo de hash est considéré comme obsolete) elles ne permettent que de remonter au mot de passe + sel.
Bref, le chiffrement c’est comme le beurre : ça n’a d’intérêt qu’avec le sel, sinon c’est tout juste bon à être mis à la poubelle.
Le 09/02/2017 à 18h42
Je pense que ce commentaire était à caractère humoristique, et qui illustre un peu l’état d’esprit des petites boites (et je sais de quoi je parle…)
" />
En tous cas, il m’a bien fait rire
Le 09/02/2017 à 18h51
Le 09/02/2017 à 19h01
Si elles n’ont pas de logiciels, elles ont raison 
" />
Le 09/02/2017 à 19h03
Le 09/02/2017 à 19h07
Pas mal
" />
Par contre, celui-ci est plutôt rassurant:
https://www.ssllabs.com/ssltest/analyze.html?d=www.impots.gouv.fr
Le 09/02/2017 à 19h11
Le 09/02/2017 à 19h25
Pour revenir sur les mots de passe … ameli les bride à 13 caractères
" />
" />
Et le ponpon ? Il faut utiliser des chiffres uniquement
Le 09/02/2017 à 19h33
Sympa ces listes, par contre je ne sais pas si c’est à jour, mais pour l’exemple de impots.gouv.fr et www.impots.gouv.fr je trouve “No SSL/TLS”…
Le 09/02/2017 à 19h35
ah oui ça le coup des fameux caractères only, une belle aberration !
Le 09/02/2017 à 15h35
“Oui, on essaye de les éduquer, mais c’est très difficile et on ne peut pas les couper”
C’est bizarre parce que lorsqu’il s’agit de ne pas mettre à jour ses anciennes versions pour les mettre en conformité avec la loi Française, et ainsi forcer l’achat plein tarif d’une nouvelle version, là y’a moins de scrupules, enfoirés.
Le 09/02/2017 à 15h35
Je pense que si on t’en envoie un nouveau, c’est le même problème.
Les techniques de hash que je connais (md5, sha) rendent impossible la manipulation inverse.
En gros, si ton mot de passe est “toto”, en base de données, le site devrait stocker “31f7a65e315586ac198bd798b6629ce4903d0899476d5741a9f32e2e521b6a66” (SHA256).
Par contre, personne ne pourra te dire que “31f7a65e315586ac198bd798b6629ce4903d0899476d5741a9f32e2e521b6a66” est égal à “toto”, il n’y a pas de méthode inverse.
Le 09/02/2017 à 15h35
J’ai jamais compris l’utilité de brider les mots de passe, que ce soit par la taille ou par des caractères inutilisables.
Le 09/02/2017 à 15h36
ça, c’est pour chiffrer une donnée (algorithme RSA).
Le hashage, c’est différent (SHA1, MD5, DES… - les deux derniers ne doivent plus être utilisés car ils ne sont plus fiables toutefois).
Le 09/02/2017 à 15h38
La photo d’illustration
" />
Le 09/02/2017 à 15h38
Le 09/02/2017 à 15h39
Ben si on t’envoie un nouveau il suffit que le site en génère un au hasard, genre “nouveaumotdepassetropbien111!” , te l’envoie en clair puis le stocke hashé, je ne vois pas le soucis. Une fois envoyé par contre le site n’aura plus accès à ce mot de passe en clair.
Le 09/02/2017 à 15h40
En effet, après réflexion tu as raison, il suffit d’une fonction qui génère un mot de passe et insère le hash en base!
Le 09/02/2017 à 15h40
MD5 n’est plus considéré comme sûr. (problèmes de collisions)
Le 09/02/2017 à 15h41
SHA1 non plus ne doit pas être utilisé. Pour être précis, la bonne pratique aujourd’hui est d’utiliser une fonction de dérivation, et non plus une simple empreinte.
Le 09/02/2017 à 15h41
Si le mail est envoyé en clair, n’importe quel serveur sur le chemin entre le site web et ta messagerie peut l’intercepter.
Le 09/02/2017 à 15h42
Le 09/02/2017 à 15h42
Oui tu as raison. Je suis allé trop vite dans la rédaction de ma réponse.
Le 09/02/2017 à 15h42
Une fonction de hash parfaite ne serait pas réversible, mais quand on connait une valeur de hash:
Le 09/02/2017 à 15h43
Oui, j’ai vu ça. La meilleure méthode c’est sans doute de rajouter une chaîne de caractères fixe au mot de passe, par exemple “baleine” + un hash en sha256
Le 09/02/2017 à 15h45
Oui. On appelle ça un “sel”. Les techniques plus avancées utilisent des algorithmes qui ont un coût en temps tel que bcrypt. Cela dans le but de faire exploser en temps les attaques par force brute ou autre génération de tables arc-en-ciel.
Le 10/02/2017 à 06h50
Le 10/02/2017 à 07h43
Le 10/02/2017 à 08h18
Le 10/02/2017 à 08h51
Je me souviens d’un site (un jeu par navigateur, vers 2001-2002) qui demandait un mot de passe unique
" />
C’est à dire que deux utilisateurs ne pouvaient pas avoir le même mot de passe…
Le 10/02/2017 à 08h56
Le 10/02/2017 à 09h05
Si tu prends une empreinte, la taille du mot de passe ne joue pas.
" />
" />
La taille de l’empreinte est fixe.
EDIT : bbqed
Le 10/02/2017 à 09h15
L’authentification par biométrie est une très mauvaise idée, pour deux principales raisons :
Le 10/02/2017 à 09h21
Connaitre un mot de passe donne souvent des indications sur les autres, ou des fois il est identique.
Le 10/02/2017 à 09h26
la biométrie doit être utilisé seulement pour remplacer le champs login mais pas le mot de passe, car c’est une donné que tu ne peux pas modifier et facilement récupérable.
Next INpact
Le 10/02/2017 à 09h34
Le 10/02/2017 à 09h36
Que penser de ça :
http://hpics.li/218c4cb
Le 10/02/2017 à 09h38
Le 10/02/2017 à 09h41
On peut en penser que ton lien n’inspire pas confiance, vu qu’il est réduit et présenté sans contexte :)
Le 10/02/2017 à 09h43
Je crois qu’il existe des techniques pour vérifier qu’il s’agit d’un vrai doigt vivant et pas d’une fausse empreinte.
On parle pas mal d’identification a l’aide des réseaux veineux des doigts
Le 10/02/2017 à 09h57
Le 10/02/2017 à 10h00
As-t-on des stats sur ces personnes qui utilisent encore des navigateurs tout pourris pour que des sites institutionnels laissent de tels lacunes??
C’est dommage que dans le protocole SSL/TLS, il y a pas un message (différent du message d’alerte du navigateur) du style: “Votre OS/navigateur est trop vieux, ne pouvons pas vous connecter en sécurité à ce site web “
Le 10/02/2017 à 10h08
Dam, je me suis fait repérer
" />
Le 10/02/2017 à 10h23
Ça existe. Ça s’appelle NO_CYPHER_OVERLAP, mais faudrait juste améliorer la page d’erreur :P
https://null.badssl.com/
Pour le pourcentage, on parle de quelques pourcents maximum. À vu de pif je dirais même moins de 1%…Ça ne concerne globalement que IE8 sous XP…
Le 10/02/2017 à 10h26
Bien vu !
http://img11.hostingpics.net/pics/767248polemploi.png
Le 10/02/2017 à 10h40
Je ne compte plus le nombre de site qui m’ont envoyé mon login et mot de passe après une inscription (et désinscription du coup derrière).
Le 10/02/2017 à 10h54
Si on voit que la gestion de mots de passe d’une société est catastrophique mais qu’elle ne fait rien quand on la contacte ? qui voir à ce moment la ?
J’ai déjà constaté un tel cas et je sais pas vers qui rapporter l’info.
Le 10/02/2017 à 10h57
Faudrait aussi (surtout?) améliorer la lecture des messages d’erreur par les utilisateurs.
" />
Mais je n’ai rien pour ça
Le 10/02/2017 à 11h37
Je pense que cela pose un problème d’utilisation au final, puisque tu dois toujours avoir le fichier de clé avec toi.
Le 10/02/2017 à 11h38
Ça marche peut-être aussi en saisissant n’importe quoi
" />
Le 10/02/2017 à 11h40
Les vieux souvenirs persistants qui paraissent proches !
Le 10/02/2017 à 11h43
Une prise d’otage et la personne à authentifier est bien vivante.
Le 10/02/2017 à 11h46
L’ANSSI peut-être.
Le 10/02/2017 à 11h57
le coeur de cible de cette boite est l’artisanat, pas pour rien si toutes les boites de batiment que je connais tournent avec. Et dans le meilleur des mondes les gens écoutent, se forment, font évoluer leur matériel informatique qui ne leur sert à rien sauf à faire les devis et la compta et les licornes pètent des fleurs et chient des arcs en ciel.
Mais ça c’est un rêve, dans mon monde le maçon se lève à 5h, passe sa journée à faire un boulot archi physique, rentre chez lui à 17h-18h, se tape sa compta et ses devis commande sa came pour les chantiers, tout en s’arsouillant la tronche avec moult ricard et n’en a rien à branler, mais alors vraiment rien de son informatique…..a si, faut pas que ça change.
Le 10/02/2017 à 12h16
Juste après une inscription, c’est pas forcément trop grave (à part le mdp qui passe en clair dans l’email).
Il n’est peut être pas gardé en clair dans la bdd après.
Le 10/02/2017 à 12h51
Sauf que là, dans le cas d’un produit web, les choix impactent tout le monde. Et en l’occurrence, mettent les données de tout le monde en danger. Ce qu’une boîte fait, avant tout, c’est proposer quelque chose : un produit, un usage… la boîte est censée connaître le métier, et apporter les bonnes pratiques. Faire le choix de nier toute sécurité (car c’est réellement le cas ici) au bénéfice de la méconnaissance des clients relève uniquement de la paresse intellectuelle, et de la méconnaissance de la sécurité informatique.
Le 10/02/2017 à 12h58
Le 10/02/2017 à 13h20
mais je le sais parfaitement je suis développeur, mais tu as dans certains secteurs de l’économie une putain d’inertie, ou il faut limite violer leurs femmes, tuer leurs gosses, manger leurs chiens et foutre le feu à leur baraque pour qu’ils bougent, et encore j’en suis même pas sur.
Le 10/02/2017 à 14h40
Le 10/02/2017 à 14h48
Le 10/02/2017 à 14h53
vu les carac du bestiaux, c’est pas si cher que ça si tu en as le besoin (rappel: 4K et HDR…)
Le 10/02/2017 à 15h05
C’est compliqué. Parce que justement, tu n’arrives pas à te connecter au serveur en face. Et que tu n’as strictement aucune idée de pourquoi ça merde…
Tout ce que ton navigateur sait, c’est qu’il n’a pas pu négocier avec le serveur en face. La raison réelle restera éternellement inconnue…
Le 10/02/2017 à 15h13
Le 10/02/2017 à 15h23
Le 10/02/2017 à 15h29
Faut peut-être arrêter de raconter n’importe quoi à un moment donné hein :)
Le sel est un paramètres qui doit nécessairement être en clair et stocké dans la db. Généralement il est même concaténé en tête du hash avant d’être stocké dans la base.
Il n’y a aucune limite haute à casser un hash, il suffit de trouver un mot de passe (pas forcément le véritable d’ailleurs) qui collisionne sur le même hash que celui indiqué dans la base. Il n’y aura même pas de candidat potentiel, vu que tu as la certitude de pouvoir t’authentifier avec à partir du moment où son hash correspond à celui en base de données.
S’il n’y a pas de sel, je ne me galère du coup même pas à faire une attaque par dictionnaire, mais je génère juste des tonnes de hash sur des tonnes de valeurs totalement aléatoires. En effet, comme ci-dessus, je m’en fous de trouver ton mot de passe, j’ai juste besoin d’en trouver un qui collisionne le hash de la base (il y a de très fortes probabilités que ça soit réellement le bon mot de passe, mais ce n’est pas garanti puisqu’un hash n’est pas bijectif mais uniquement surjectif). S’il y a un sel, je dois juste procéder utilisateur par utilisateur au lieu d’attaquer tous les hash en même temps.
Et si tu as choisis un mot de passe trop faible (et qu’il n’y a pas de sel), il y a même une chance non négligeable que le hash de ton mot de passe soit déjà connu (rainbow table) et donc que le casser prenne quelque chose comme 50ms.
En plus, ces calculs sont fait offline, donc toute parade anti-bruteforce mise en place par le site en question seront totalement inefficaces. Je bruteforcerais sur ma machine jusqu’à trouver une collision, et je m’authentifierais une seule et unique fois sur le site en question avec le mot de passe trouvé, qui validera obligatoirement l’accès au compte.
Bref, une base de données dans la nature mal hashée ou salée, c’est juste une véritable bombe à retardement et rien ni personne ne peut plus rien y faire. Le seul conseil qui vaille est d’alors changer immédiatement son mot de passe (ou de cesser d’utiliser le service jusqu’à ce qu’ils aient un hash suffisamment sécurisé), et de le changer aussi partout ailleurs où on l’avait utilisé.
On ne devrait jamais utiliser 2× le même mot de passe sur 2 services différents justement parce qu’en cas de fuite d’une base de données, les probabilités sont élevées que le service n’ait pas pris au sérieux la sécurité et ait stocké vos mots de passe au pire en clair au mieux hashé sans sel. Une fois le pass collisionné, soyez sûr qu’un attaquant ira tester le couple login/mot de passe obtenu sur tous les autres services qui lui passeront sous la main !
Le 10/02/2017 à 15h39
Le 10/02/2017 à 15h43
Sûr et certain, il est présent dans la propriété “value” de la balise “input” directement dans le HTML de la page. Ca perturbe d’ailleurs le gestionnaire de mot de passe…
Le 10/02/2017 à 15h45
Le 10/02/2017 à 15h46
Le 10/02/2017 à 15h54
Au moins, on peut constater la bonne homogénéité de la communication de Free, quelque soit le domaine .
:o
Le 10/02/2017 à 16h14
Le 10/02/2017 à 16h21
Le 10/02/2017 à 16h29
Je suis d’accord, c’est pour ça que j’ai précisé au passage concernant ma super fonction de hachage, qui est effectivement inversible facilement : “(ça ne convient pas en vrai pour la sécurité mais c’est du hachage)”.
Le 10/02/2017 à 16h33
Le 09/02/2017 à 15h15
mais firefox ou chromium même sur un windows xp, ça ne supporte plus SSLv3 (?)
Le 09/02/2017 à 15h17
c’est évident que le maçon avec son PC sur Windows XP sans mise à jour avec IE par défaut (et il doit pas être seul dans cet état), il doit pouvoir continuer à utiliser les services de son outil de facturation, sinon il risque de gueuler.
" />
La situation n’est pas simple parce qu’il y a un réel risque de sécurité pour lui, mais aussi pour les autres clients d’EBP.
On peut pas lui imposer de changer d’ordinateur mais c’est ce qu’il comprendra qu’il faut faire si on lui dit qu’il est trop vieux pour se connecter à ses outils de facturation. Et ça a un coût non négligeable.
en gros, c’est de la faute aux constructeurs de matos informatique qui n’ont pas fait d’obsolescence programmée sur ces matériels
Le 09/02/2017 à 15h21
Le 09/02/2017 à 15h25
pour Free par contre c’est juste intolérable…
" />
Le 09/02/2017 à 15h26
“je suis sur un chantier, je ferais ça en rentrant” et ça pendant 10 ans…
" />
(et je troll à peine: j’ai fait du dépannage pour des TPE, on est pas loin de ça)
Le 09/02/2017 à 15h26
Free devrait bridé les mots de passes
" />
Le 09/02/2017 à 15h27
Le 09/02/2017 à 15h27
Le 09/02/2017 à 15h28
Le 09/02/2017 à 15h28
Le 09/02/2017 à 15h29
Je n’ai jamais compris comment un hash peut être non réversible….
Le 09/02/2017 à 15h30
La méthode simple pour savoir si une société stocke ses mots de passe de manière réversible est d’utiliser la fonctionnalité de mot de passe oublié. S’il vous est renvoyé par email, c’est forcément le cas.
Ce passage me semble peu clair.
Quand tu dis “s’il vous est renvoyé par mail”, tu veux dire si on reçoit de nouveau le même mdp ? Ou bien tu parles aussi du cas qui t’envoie un nouveau mdp ?
Le 09/02/2017 à 15h31
Et bien je sais pas, étudie les maths ?
Pour être un poil plus constructif : trouve une dalle de béton fraiche, saute dedans pieds nus, et laisse sécher. On pourra aisément vérifier que ce sont bien tes empreintes, mais à partir des seules empreintes il ne sera pas possible de te reconstituer, toi.
Le 09/02/2017 à 15h31
Je crois que même IE7 supporte TLS1.0, je pense par défaut.
Il faut donc vraiment un Windows XP pas du tout à jour, l’excuse me semble un peu bidon…
Le 09/02/2017 à 15h33
Le 09/02/2017 à 15h34
Le 09/02/2017 à 16h09
Tu peux supprimer ton commentaire qui est une ineptie totale ?
hash != chiffrement
Merci d’avance,
Le 09/02/2017 à 16h16
free c’est pas de leur faute ils ne peuvent pas acheter des serveurs pour crypter les mots de passe, ils ont tout mis dans la fibre
" />
Le 09/02/2017 à 16h17
Et si à un moment donné les entreprises forçaient leurs clients a utiliser des protocoles / procédures plus sécurisés ?
Sans déconner …
Le 09/02/2017 à 16h19
Le 09/02/2017 à 16h24
C’est le genre de truc qui me fait grimper au plafond, quand tu fais “mot de passe oublié”, et qu’on te répond 5 secondes après par mail :
" />
“Ah, votre mot de passe c’est ça : XXXXX”
Un jour, ne sais plus sur quel site, j’avais même envoyé un mail pour leur dire que c’était inadmissible.
On m’a rappelé peu de temps après, la personne ne comprenait pas pourquoi c’était mal…
Le 09/02/2017 à 16h38
Dans mon ancienne boîte c’était comme ça. Ce choix avait été fait pour satisfaire les utilisateurs qui trouvaient trop compliqué de réinitialiser leur mdp (par le dev qui était là avant moi, moi j’aurais jamais accepté de coder ça)
" />
Du coup les mecs au lieu d’appeler le support pour dire “je comprends pas comment on réinitialise le mdp” ils appelaient pour dire “vous pouvez me donner mon mdp svp?” (bah oui parce que même après ça ils continuaient d’appeler le support plutôt que d’utiliser la fonction de récupération par mail)
Du coup plusieurs fois par jour j’entendais mes collègues dire à voix haute le mdp des utilisateurs par téléphone…
Le 09/02/2017 à 16h50
Comme je disais à David_L sur twitter (auto promo?
" /> ) perso, ca fait plus de dix ans que j’enchaine des clients en tant que consultant, généralement de très grosses boites…
et l’aspect client qui est cité dans cet article est privilégié à 99.99%
j’ai eu entre autre joyeuseté : des numéros de CB en clair (avec date et cryptogramme hein) dans des fichiers CSV. (dans une filiale d’une banque Fr; pas chez la PME du coin). Ca a été découvert, remonté à la direction, 3 mois après j’ai eu droit à un “Osef” . certes, il s’agit de flux interne mais que j’avais sur mon poste de travail (et que je pouvais faire sortir sur clé USB, bref)
Autre entreprise : le service client me demandais des mots de passe que les clients oubliaient (pas denvoi auto). MDP que j’inventais (ex “A6rueZ” pour faire style ca a été auto généré, passais en MD5, copiait en prod dans la BDD, et transmettais) - Donc et le SAV, et moi, et le client avait tout en clair
des exemples comme ca, j’en ai à la pelle, chez chaque client, toutes de grandes entreprises francaises.
C’est pareil pour tous les consultants, quasiment. (c’est pas pour rien que les sites / tweet genre “les joies du code” plaisantent avec les commit en prod et autre)
Non, vraiment, la sécurité, on y est pas encore, point de vue entreprise le service marketing aura toujours le dessus sur la DSI. Et les rares fois ou on est appuyé par un chef, y a toujours un N+1 quelque part qui nous dira que non, c’est pas grave.
Le 09/02/2017 à 16h57
Pour la taille, ça vient des administrateurs de base de données qui gardent leurs habitudes des années 80 et essayent d’économiser quelques octets par enregistrement dans une table.
Cela dit, les mots de passe (et tous les champs en fait) doivent quand même avoir une limite, sinon t’as des rigolos qui vont t’envoyer des mots de passe qui prennent plusieurs Mo à stocker, ça va vite s’accumuler.
Quant aux caractères interdits, parfois alors qu’ils sont dans les 128 premiers de la table ASCII et donc ne prenne pas plus de place en base, ça me laisse perplexe.
Le 09/02/2017 à 17h07
Perso je surfacture pour “système obsolète” après trois avertissements lors des interventions, je propose une remise sur la main d’oeuvre pour migrer les vieilles machines aussi.
Le 09/02/2017 à 17h20
Me fait penser à ces entreprises qui me disent ne pas avoir besoin de logiciels de sécurité.
Le 09/02/2017 à 17h20
sauf que maintenant enfin plutôt l’année prochaine ça coûte beaucoup plus cher de pas prendre soin des données perso de ses utilisateurs.
" />
du coup la DSI elle aura vachement plus de poids dans la décision quand il s’agira de hasher les pass des clients.
mais +1 oui, c’est un peu bagdad.
Le 09/02/2017 à 17h26
Tant qu’ils se prendront pas une amende, un scandale… rien ne sera fait hein
Le SEPA c’est obligatoire et on a mis quoi, 2 fois le temps initial pour mettre ce type d’evol en place ?
Ok je prend pas un exemple des plis simple mais faut bien voir que faire evoluer un SI ou un logiciel, a fortiori en securité, ca n’a aucun interet pour les boites
Malheureusement !
Mais bref, le temps que ces directives soient mises en place on a le temps de voir venir. Comptez 5 ans facile
Le 09/02/2017 à 17h28
Le 09/02/2017 à 17h29
ben disons qu’effectivement, essayer d’ajouter de la sécu sur un SI qui n’en a pas (et qui n’a pas été pensé pour ça), c’est un putain de délire, d’où la volonté de sécurité “by design” du règlement européen.
Le 09/02/2017 à 17h47
Le 09/02/2017 à 17h56
Le fait de dire “oui mais faut écouter les clients, c’est pas leur métier, chez eux ça tourne bien avec de vieux logiciels et ils ne comprennent pas pourquoi il faudrait changer”, c’est grâce à cette mentalité qu’IE6 a mis 10 ans à mourir, en bloquant le web (qui était prêt mais qu’on ne pouvait pas - facilement - utiliser les technos modernes), parce qu’IE7 se voulait compatible, et IE8 aussi, etc..
Je veux bien qu’on laisse du temps, mais au bout d’un moment il faut bien évoluer. A vouloir toujours attendre d’être prêt, on finit par ne jamais changer, et on laisse de trous de sécu béants. Et il ne faut pas croire qu’on ne sera ps tenu pour responsable derrière.
Le gars qui veut un mot de passe en clair car sinon il l’oublie, il n’a qu’à le coller sur sa boîte aux lettres. Je garantis que 3 jours après, quand tout le monde se sera connecté sur ses mails, il comprendra qu’il faut faire un effort. Le changement n’exclut pas de faire de la pédagogie, mais l’infantilisation ne fait qu’ajouter de la dette technique et des risques qui se payeront chers tôt ou tard.
Le 09/02/2017 à 19h51
Le 09/02/2017 à 20h43
perso je me demande pourquoi nous ne pouvons toujours pas s’authentifier par un fichier clé ? je clique sur parcourir je sélectionne le bon fichier de 4096 bits signé par gpg et hop; genre nextinpact.txt
" />
avec ssh ca change vraiment la vie l’authentification par certificat, yapluka ne pas perdre la clé usb
Le 09/02/2017 à 20h58
Puisque j’ai appris plein de choses sur les mots de passe avec les commentaires (merci!), je pose ma petite question à mon tour :
Sur le site du monde, mon mot de passe est “toto”. Mais en fait si je mets “toto85” ou n’importe quoi d’autre après, le mot de passe fonctionne toujours. Ca me semble bizarre. Je n’ai jamais eu d’explication. Ca parle à quelqu’un ce bug ? Est-ce une erreur ou une faiblesse ?
Le 09/02/2017 à 21h07
Le 09/02/2017 à 21h08
Ça sent une énorme faiblesse.
Déjà ça veut dire qu’ils stockent le mot de passe en clair.
Et qu’en plus de ça, ils font un test à la con en ajoutant lettre par lettre jusqu’à arriver à la fin ou à ce que ça passe…
À pleurer…
Le 09/02/2017 à 21h12
ah oui y a ça aussi
" /> (le rire est feint, la panique est réelle si c’est ça… bon ça rentre dans mon cas “pas exactement ça mais j’accepte le mdp”)
Le 09/02/2017 à 22h12
C’est le cas chez LDLC aussi, ou bien c’était encore le cas y’a pas longtemps.
J’ai encore les mails de récupération de mot de passe avec le mdp en clair dedans…
Le 09/02/2017 à 22h45
Le 10/02/2017 à 00h09
Le 10/02/2017 à 00h21
Le recevoir par email sur simple demande a beau être un « drame » en terme de sécurité, il a l’avantage d’être rapide
En même temps, il faut parfois relativiser le “drame” dans la pratique. Un système d’authentification ne signifie pas toujours qu’il y a quelque chose de critique derrière.
Le 10/02/2017 à 01h14
Le 10/02/2017 à 06h01
Le 10/02/2017 à 06h10
Remarque très pertinente, mais du coup s’il y a des limites sur le mot de passe, c’est qu’il doit probablement être stocké dans la base.
Le 10/02/2017 à 06h41
et un accès mot de passe par un lecteur biométrique + un code de déverrouillage en cas de non fonctionnement ?
Le 10/02/2017 à 06h46
Il y a toujours une utilité à voler les données personnelles. L’argent est la première raisons, mais nuire arrive pas très loin derrière.
Il m’arrive souvent de me rendre compte qu’un site stocke le mot de passe en clair. Le pire est quand il pré-remplis les champs “mot de passe” avec le mot de passe actuel.
En général, je contact le site. Dans le pire des cas, je supprime mon compte ou si c’est pas possible, je met des infos bidons.
Le 10/02/2017 à 06h49
Le 10/02/2017 à 13h21
Le 10/02/2017 à 13h24
Eh bien, j’en ai fait des fautes sur ce commentaire. ça m’apprendra à aller vite dans mes réponses.
Le 10/02/2017 à 13h29
Le 10/02/2017 à 13h32
Le 10/02/2017 à 13h35
Le 10/02/2017 à 13h42
Le 10/02/2017 à 13h42
Le 10/02/2017 à 13h49
Le 10/02/2017 à 13h52
C’est ce que je dit, en substance. Surtout sur la fin : la puissance des pc monte => on change d’algo :)
Le 10/02/2017 à 14h08
Merci pour tout les réponses.
Mais du coup j’ai une autre question.
Dans le cas ou le hacker a eu accès au hash de mdp.
Et il connais l’algo utiliser.
Il doit pouvoir élaborer une liste limiter de candidates de mdp non ?
Le 10/02/2017 à 14h21
Le 10/02/2017 à 14h25
Le 10/02/2017 à 14h30
c’est pour ça que Windows Hello n’est compatible qu’avec 3 ou 4 webcam seulement à l’heure actuelle ;)
Le 10/02/2017 à 14h32
Le 10/02/2017 à 14h37
Le 10/02/2017 à 14h37
tu parles de Windows Hello en mort-né?
parce que ce n’est pas QUE ça (tu peux y associer d’autres facteur que la reconnaissance faciale) et c’est aussi un système relativement jeune donc il faut laisser le temps aux constructeur de sortir le matériel (justement Logitech viens de sortir une webcam compatible cette semaine)