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)
#1
mais firefox ou chromium même sur un windows xp, ça ne supporte plus SSLv3 (?)
#2
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 " />
#3
#4
pour Free par contre c’est juste intolérable… " />
#5
“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)
#6
Free devrait bridé les mots de passes " />
#7
#8
#9
#10
#11
Je n’ai jamais compris comment un hash peut être non réversible….
#12
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 ?
#13
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.
#14
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…
#15
#16
#17
“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.
#18
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.
#19
J’ai jamais compris l’utilité de brider les mots de passe, que ce soit par la taille ou par des caractères inutilisables.
#20
ç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).
#21
La photo d’illustration " />
#22
#23
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.
#24
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!
#25
MD5 n’est plus considéré comme sûr. (problèmes de collisions)
#26
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.
#27
Si le mail est envoyé en clair, n’importe quel serveur sur le chemin entre le site web et ta messagerie peut l’intercepter.
#28
#29
Oui tu as raison. Je suis allé trop vite dans la rédaction de ma réponse.
#30
Une fonction de hash parfaite ne serait pas réversible, mais quand on connait une valeur de hash:
#31
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
#32
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.
#33
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à@”{~#$*µ%!” " />
#34
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?
#35
Arrêtez de vous prendre la tête, tout est expliqué ici…
https://blog.imirhil.fr/2015/10/27/stockage-mot-passe.html
#36
Oui effectivement. Par contre, la chaine aléatoire, elle est bien stockée quelque part? Et donc “hackable”?
#37
Problème des collisions, oui.
Sinon, l’article que vient de poster Aeris22 (#35) résume les bonnes pratiques.
#38
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)
#39
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.
#40
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 " />
#41
J’allais poster ton article ;-)
#42
#43
#44
#45
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…
#46
Je me tâte à modérer pour auto-promo " />
#47
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.
#48
#49
Tu peux supprimer ton commentaire qui est une ineptie totale ?
hash != chiffrement
Merci d’avance,
#50
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 " />
#51
Et si à un moment donné les entreprises forçaient leurs clients a utiliser des protocoles / procédures plus sécurisés ?
Sans déconner …
#52
#53
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…
#54
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… " />
#55
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.
#56
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.
#57
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.
#58
Me fait penser à ces entreprises qui me disent ne pas avoir besoin de logiciels de sécurité.
#59
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.
#60
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
#61
#62
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.
#63
#64
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.
#65
>
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… :/
#66
#67
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é”
#68
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.
#69
#70
en parlant de passoire totalement scandaleuse …
https://www.ssllabs.com/ssltest/analyze.html?d=assure.ameli.fr
magnifique ^^
#71
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).
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 :https://fr.wikipedia.org/wiki/Salage_(cryptographie)
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.
#72
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 " />
#73
#74
Si elles n’ont pas de logiciels, elles ont raison " />
#75
#76
Pas mal " />
Par contre, celui-ci est plutôt rassurant:
https://www.ssllabs.com/ssltest/analyze.html?d=www.impots.gouv.fr
#77
#78
Pour revenir sur les mots de passe … ameli les bride à 13 caractères " />
Et le ponpon ? Il faut utiliser des chiffres uniquement " />
#79
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”…
#80
ah oui ça le coup des fameux caractères only, une belle aberration !
#81
#82
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 " />
#83
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 ?
#84
#85
Ç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…
#86
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”)
#87
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…
#88
#89
#90
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.
#91
#92
#93
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.
#94
et un accès mot de passe par un lecteur biométrique + un code de déverrouillage en cas de non fonctionnement ?
#95
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.
#96
#97
" />
#98
#99
#100
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…
#101
#102
Si tu prends une empreinte, la taille du mot de passe ne joue pas.
La taille de l’empreinte est fixe. " />
EDIT : bbqed " />
#103
L’authentification par biométrie est une très mauvaise idée, pour deux principales raisons :
#104
Connaitre un mot de passe donne souvent des indications sur les autres, ou des fois il est identique.
#105
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.
https://www.nextinpact.com/news/91637-il-est-possible-reconstituer-empreinte-dig…
#106
#107
Que penser de ça :
http://hpics.li/218c4cb
#108
#109
On peut en penser que ton lien n’inspire pas confiance, vu qu’il est réduit et présenté sans contexte :)
#110
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
#111
#112
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 “
#113
Dam, je me suis fait repérer " />
#114
Ç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…
#115
Bien vu !
http://img11.hostingpics.net/pics/767248polemploi.png
#116
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).
#117
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.
#118
Faudrait aussi (surtout?) améliorer la lecture des messages d’erreur par les utilisateurs.
Mais je n’ai rien pour ça " />
#119
Je pense que cela pose un problème d’utilisation au final, puisque tu dois toujours avoir le fichier de clé avec toi.
#120
Ça marche peut-être aussi en saisissant n’importe quoi " />
#121
Les vieux souvenirs persistants qui paraissent proches !
#122
Une prise d’otage et la personne à authentifier est bien vivante.
#123
L’ANSSI peut-être.
#124
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.
#125
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.
#126
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.
#127
#128
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.
#129
#130
Eh bien, j’en ai fait des fautes sur ce commentaire. ça m’apprendra à aller vite dans mes réponses.
#131
#132
#133
#134
#135
#136
#137
C’est ce que je dit, en substance. Surtout sur la fin : la puissance des pc monte => on change d’algo :)
#138
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 ?
#139
#140
#141
c’est pour ça que Windows Hello n’est compatible qu’avec 3 ou 4 webcam seulement à l’heure actuelle ;)
#142
#143
#144
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)
#145
#146
#147
vu les carac du bestiaux, c’est pas si cher que ça si tu en as le besoin (rappel: 4K et HDR…)
#148
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…
#149
#150
#151
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 !
#152
#153
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…
#154
#155
#156
Au moins, on peut constater la bonne homogénéité de la communication de Free, quelque soit le domaine .
:o
#157
#158
#159
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)”.
#160
#161
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).
#162
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).
#163
#164
#165
#166
#167
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 ?
#168
#169
#170
Sinon ceux qui veulent médire des sites gouvernementaux peuvent aller voir ici :https://www.openbugbounty.org/search/?search=gouv.fr&type=host
#171
Bases de données client et tout
#172
#173
#174
#175
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.
#176
#177
#178
#179
Des trucs genre CRAM-MD5https://en.wikipedia.org/wiki/CRAM-MD5
#180
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 :(
#181
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!!