Mot de passe en clair dans un email, SSLv3 : EBP s'explique

Mot de passe en clair dans un email, SSLv3 : EBP s’explique

La CNIL en PLS

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

09/02/2017 6 minutes
181

Mot de passe en clair dans un email, SSLv3 : EBP s'explique

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 : 

EBP mot de passe perdu mailFree mot de passe perdu mail

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à 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.

SSLv3  EBP 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.

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

La CNIL recommande de stocker une empreinte, EBP et Free ne le font pas

Silence radio chez Free, EBP assume et s'explique

Mais va changer de procédure pour ne stocker que des empreintes

Quid de SSLv3 et RC4 toujours supportés par le site ?

« On ne peut pas couper les clients »

Commentaires (181)


mais firefox ou chromium même sur un windows xp, ça ne supporte plus SSLv3 (?)

 


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 <img data-src=" />








Minikea a écrit :



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.





“Bonjour, vous vous connectez avec un navigateur obsolète depuis 10 ans. D’ici un mois, vous ne pourrez plus vous connecter au site pour des raisons de sécurité. Merci de télécharger le navigateur Firefox et de le maintenir à jour pour continuer à utiliser nos services.”



Tadaaaaaaaa. Le client est prévenu, il a largement le temps d’installer un foutu logiciel, Firefox pour XP est suffisamment récent pour supporter TLS1.2, tout le monde est content.



Et si le maçon est pas content, faut lui rappeler que vivre 15 ans dans le passé c’est pas une super bonne idée quand on est une entreprise.



pour Free par contre c’est juste intolérable… <img data-src=" />


“je suis sur un chantier, je ferais ça en rentrant” et ça pendant 10 ans… <img data-src=" />

(et je troll à peine: j’ai fait du dépannage pour des TPE, on est pas loin de ça)


Free devrait bridé les mots de passes <img data-src=" />








Neeko a écrit :



Et si le maçon est pas content, faut lui rappeler que vivre 15 ans dans le passé c’est pas une super bonne idée quand on est une entreprise.





Oui et non. Nous sommes une Société où le client est roi. Pourquoi les boîtes n’ont pas des politiques moins binaires que “je ne change rien tant que le dernier client n’a pas migré”? Ça arrange bien ces boîtes, je ne parle pas du DSI qui est un employé, mais de la Direction Générale, d’attendre le dernier. Au moins, comme ça ils ne changent rien et empoche du pognon.









Neeko a écrit :



“Bonjour, vous vous connectez avec un navigateur obsolète depuis 10 ans. D’ici un mois, vous ne pourrez plus vous connecter au site pour des raisons de sécurité. Merci de télécharger le navigateur Firefox et de le maintenir à jour pour continuer à utiliser nos services.”



Tadaaaaaaaa. Le client est prévenu, il a largement le temps d’installer un foutu logiciel, Firefox pour XP est suffisamment récent pour supporter TLS1.2, tout le monde est content.



Et si le maçon est pas content, faut lui rappeler que vivre 15 ans dans le passé c’est pas une super bonne idée quand on est une entreprise.







Comment apporter la paix dans le monde ? Avertir les utilisateurs que tuer c’est mal.



“Tadaaaaaaaa. Le client est prévenu”…………………









Neeko a écrit :



[…]

Et si le maçon est pas content, faut lui rappeler que vivre 15 ans dans le passé c’est pas une super bonne idée quand on est une entreprise.





Mais le maçon, il vient d’un monde ou pouvoir utiliser de vieux outils et de vielles techniques est bien









code a écrit :



Free devrait bridé les mots de passes <img data-src=" />





Y’a pas si longtemps c’etait le cas a 8carac



Je n’ai jamais compris comment un hash peut être non réversible….




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 ?


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.


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…








DUNplus a écrit :



Je n’ai jamais compris comment un hash peut être non réversible….





La plupart des algos sont basés sur le fait qu’on est globalement incapable de factoriser des grands nombres en facteurs premiers en un temps raisonnable. Si je te donne un produit de deux nombres premiers qui ont chacun 20 nombres, tu mettra un temps fou avant de pouvoir retrouver les deux nombres premiers en question.



C’est en gros la base.









eliumnick a écrit :



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 ?





Quand ils renvoient ton mot de passe actuel. Un reset de mot de passe c’est bon (ou mot de passe temporaire). Mais s’ils renvoient le mot de passe que toi tu as mis il y a 4 ans, c’est pas bon.









DUNplus a écrit :



Je n’ai jamais compris comment un hash peut être non réversible….





Il suffit d’utiliser une fonction surjective et non bijective.https://fr.wikipedia.org/wiki/Surjection



“Oui, on essaye de les éduquer, mais c’est&nbsp;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.


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.


J’ai jamais compris l’utilité de brider les mots de passe, que ce soit par la taille ou par des caractères inutilisables.


ça, c’est pour chiffrer une donnée (algorithme RSA).

&nbsp;

Le hashage,&nbsp; c’est différent (SHA1, MD5, DES… - les deux derniers ne doivent plus être utilisés car ils ne sont plus fiables toutefois).


La photo d’illustration <img data-src=" />








Xaelias a écrit :



Quand ils renvoient ton mot de passe actuel. Un reset de mot de passe c’est bon (ou mot de passe temporaire). Mais s’ils renvoient le mot de passe que toi tu as mis il y a 4 ans, c’est pas bon.







Au début je l’ai compris comme ca (renvoie du même mdp).







gachdel a écrit :



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.







Ben avec un nouveau mdp, ca me semble plus variable. Ok le nouveau peut être stocké en clair, mais il peut être juste envoyé dans le mail, avec l’empreinte stocké coté site.



Pake sinon, prenons le cas de Free. Quand tu t’inscris chez eux, ils te filent un login et un mdp. Ca reviendrait à dire que n’importe quelle société qui génère un mdp pour l’utilisateur stocke les mdp en clair.



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.


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!


MD5 n’est plus considéré comme sûr. (problèmes de collisions)


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.


Si le mail est envoyé en clair, n’importe quel serveur sur le chemin entre le site web et ta messagerie peut l’intercepter.








DUNplus a écrit :



Je n’ai jamais compris comment un hash peut être non réversible….





Des maths oui, avec des opérations non bijectives..



Ton MDP c’est ABCDEF. Maintenant que l’on attribue une valeur arbitraire à chaque lettre et qu’on les additionne.

Tu obtient un résultat, le hash . A partir du résultat tu retrouve comment ABCDEF?



Évidemment, c’est simplifié à l’extrême, les formules mathématiques sont bien plus complexes hein :)

&nbsp;

Tu ne connait ni la longueur du mdp initial ni les caractères qui le composent.

&nbsp;

Il reste donc a tester toutes les combi de caractères avec la formule de calcul pour tester si tu peut en trouver une qui donne le même résultat : l’attaque par force brute. Et tu ne retrouvera pas forcement le BON mot de passe, juste un qui passe , une collision !



Pour accélérer l’attaque on peut employer des dictionnaires.. les gens emploient souvent des mots.



Ce qui explique que l’on augmente la force d’un mot de passe en employant majuscules minuscules chiffres et caractères spéciaux et sa taille : à partir du hash, beaucoup plus de caractères différents / plus de possibilité de caractères à tester&nbsp; = grosse multiplication du temps de calcul.



C’est pour cela que les algo de hash sont dépréciés avec le temps : si ca devient trop facile de trouver des collisions , on passe à un autre. Le MD5 c’est finit normalement, et le SHA1 je croit aussi.



Oui tu as raison. Je suis allé trop vite dans la rédaction de ma réponse.


Une fonction de hash parfaite ne serait pas réversible, mais quand on connait une valeur de hash:





  • Déjà, on a une base pour faire de la force brute dans son coin sans attirer plus que ça l’attention du serveur

    &nbsp;

  • Si la fonction a une faiblesse, la valeur du hash laisse apparaitre (moyennant grosse prise de tête, mais ça, c’est fait une fois pour toute par les chercheurs du domaine) des indices sur la valeur initiale


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


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.


Si le mot de passe est bidon, en cherchant le hash sur internet, tu le trouves .

&nbsp;

Pour cela que les bons systèmes collent au bout de ton mdp&nbsp; 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à@”{~#$*µ%!” <img data-src=" />


Je viens de comprendre comment tout ça marche <img data-src=" />



Mais du coup, il peut y avoir des doublons? Par exemple avec ton exemple ABCDEF, FABCDE obtiendra le même résultat?


Arrêtez de vous prendre la tête, tout est expliqué ici…

https://blog.imirhil.fr/2015/10/27/stockage-mot-passe.html


Oui effectivement. Par contre, la chaine aléatoire, elle est bien stockée quelque part? Et donc “hackable”?


Problème des collisions, oui.



Sinon, l’article que vient de poster Aeris22 (#35) résume les bonnes pratiques.


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)


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 -&gt; BBB, ou CBA -&gt; 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.


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.

&nbsp;

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 <img data-src=" />



C’est difficile de faire un système inviolable, on fait tout pour gagner du temps <img data-src=" />

&nbsp;


J’allais poster ton article ;-)








GérardMansoif a écrit :



Oui et non. Nous sommes une Société où le client est roi.





En novembre 2016, j’ai ouvert 2 réclamations à EDF. Le personnel d’EDF m’a littéralement rit au nez. J’ai donc écrit un courrier au PDG d’EDF dans lequel je lui renvoyais tout le mépris que son personnel m’avait adressé. 7 jours plus tard, un employé missionné par le PDG d’EDF pour me satisfaire me contactait et 10 jours plus tard ce même employé m’annonçait avoir résolu les problèmes.

Ce n’est pas la première fois que je fais ce genre de chose, et je vous garantis que ça marche plutôt bien.

Si le client était roi, il n’aurait pas besoin d’écrire aux PDG pour obtenir le respect qu’il est en droit d’attendre.

&nbsp;









zhebulonn a écrit :



J’ai jamais compris l’utilité de brider les mots de passe, que ce soit par la taille ou par des caractères inutilisables.





Si tu avais déjà fait crasher un formulaire php de changement de mot de passe avec des $ et des “ dedans, tu comprendrais pourquoi certains caractères sont inutilisables :-)

Même si, bien sûr, la bonne solution est d’avoir un échappement correct.

&nbsp;









gordonzola a écrit :



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)





Pas trop aveuglément quand même :) L’intime compréhension, c’est toujours mieux :P





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…


Je me tâte à modérer pour auto-promo <img data-src=" />


Mot de passe en clair en 2017 ?? <img data-src=" />



C’est pas comme s’il y avait des fonctions/bibliothèques de crypto dans tous les langages.








David_L a écrit :



Je me tâte à modérer pour auto-promo <img data-src=" />





Oh, tu peux remplacer parhttps://gordon.re/developpement/mot-de-passe-pourquoi-comment.html si tu préfères <img data-src=" />



Tu peux supprimer ton commentaire qui est une ineptie totale ?



hash != chiffrement

&nbsp;

Merci d’avance,


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 <img data-src=" />


Et si à un moment donné les entreprises forçaient leurs clients a utiliser des protocoles / procédures plus sécurisés ?

Sans déconner …








KP2 a écrit :



C’est vraiment une excuse à la con… Un client, quelque soit son niveau







Alors toi, ça se voit que tu connais pas Carlouche, moi je le connais personnellement et c’est un coup à te manger un coup de pelle dans la tronche. D’ailleurs c’est pas lui qui fait la compta mais sa femme et elle est presque aussi douée que lui. Carlos junior s’y connaît beaucoup plus en informatique, il va sur facebook avec son smartphone!



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”&nbsp;<img data-src=" />



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…


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… <img data-src=" />


Comme je disais à David_L sur twitter (auto promo? <img data-src=" /> ) 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.





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.


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.


Me fait penser à ces entreprises qui me disent ne pas avoir besoin de logiciels de sécurité.


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. <img data-src=" />



mais +1 oui, c’est un peu bagdad.


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













ZoZo a écrit :



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.





C’est justement totalement débile si tes mots de passe sont hachés.

Une fois passés à la moulinette d’un sha512, ils feront TOUS 512 bits et ne contiendront que des caractères hexadécimaux (0-9A-F).

Même si en entrée tu lui as mis l’intégral des 2To de ta collection de porn ou que ton mot de passe contient des

sinogrammes encodés en UTF-8…



C’est même pour ça que tu peux être sûr qu’un site qui limite la taille du mot de passe ou les caractères utilisables ne stocke pas de manière sûre ce mot de passe dans sa base de données. Et même très certainement en clair…



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.








lanoux a écrit :



Alors toi, ça se voit que tu connais pas Carlouche, moi je le connais personnellement et c’est un coup à te manger un coup de pelle dans la tronche. D’ailleurs c’est pas lui qui fait la compta mais sa femme et elle est presque aussi douée que lui. Carlos junior s’y connaît beaucoup plus en informatique, il va sur facebook avec son smartphone!



Et donc ?



Parce qu’il y a des gens qui ne veulent pas se sortir les doigts (on remets en perspective, Kp2 parle de changer de … navigateur) il faut accepter de rester a des normes de sécurité obsolètes ?!



A un moment donné, ce genre de comportements c’est juste inacceptable …



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.


&gt;





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… :/








Juju251 a écrit :



Et donc ?



Parce qu’il y a des gens qui ne veulent pas se sortir les doigts (on remets en perspective, Kp2 parle de changer de … navigateur) il faut accepter de rester a des normes de sécurité obsolètes ?!



A un moment donné, ce genre de comportements c’est juste inacceptable …&nbsp;





&nbsp;

Surtout que ça met en danger tout le monde, y compris ceux avec des navigateurs plus ou moins à jour.



&nbsp;Parce que le serveur supporte des trucs pourris, je peux forcer les navigateurs à se rabattre sur ces trucs pourris alors que normalement ils auraient du utiliser quelque chose de plus fort.

Ou encore dans le cas de EBP, un de leur serveur supporte du SSLv2, je peux donc profiter de la faille DROWN même si votre navigateur ne supporte pas cette veille suite de chiffrement.



&nbsp;Dit autrement, si vous êtes sur le même réseau que moi (au pif au Starbuck du coin ou sur un wifi public), je peux plutôt « facilement » (c’est l’affaire de 2 ou 3 heures voire de quelques minutes pour les trucs les pires) avoir accès à vos cookies ou à votre mot de passe, et ainsi récupérer tous vos plans comptables ou les fiches de paies de tous vos employés. Même si votre navigateur Firefox est le plus à jour disponible…



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é”


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.








Xaelias a écrit :



La plupart des algos sont basés sur le fait qu’on est globalement incapable de factoriser des grands nombres en facteurs premiers en un temps raisonnable. Si je te donne un produit de deux nombres premiers qui ont chacun 20 nombres, tu mettra un temps fou avant de pouvoir retrouver les deux nombres premiers en question.



C’est en gros la base.





La réponse est pas mal, mais ne correspond pas du tout à la question !



Donc, en gros, elle ne vaut rien.



en parlant de passoire totalement scandaleuse …



https://www.ssllabs.com/ssltest/analyze.html?d=assure.ameli.fr



magnifique ^^


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.


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 <img data-src=" />








Sebdraluorg a écrit :



le fait de ne pas renvoyer le mot de passe en clair ne signifie pas que la société ne le possède pas





Certes



le fait de l’ envoyer ne signifie pas qu’il est stocké en clair



Non, mais qu’il est stocké avec un algo de chiffrement réversible, et non avec un algo de hash.

Ce qui signifie que si un hacker a réussi à récupérer l’emprunte du mot de passe chiffré, il a aussi pu récupérer la clé pour le déchiffrer.



Si elles n’ont pas de logiciels, elles ont raison&nbsp;<img data-src=" />



&nbsp;








garn a écrit :



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



J’aurais mis des phrases à caractère néo-nazi ou pédophile, pour faire flipper le type en face&nbsp;<img data-src=" />



Pas mal <img data-src=" />

Par contre, celui-ci est plutôt rassurant:

https://www.ssllabs.com/ssltest/analyze.html?d=www.impots.gouv.fr








haazheel a écrit :



Pas mal <img data-src=" />

Par contre, celui-ci est plutôt rassurant:

https://www.ssllabs.com/ssltest/analyze.html?d=www.impots.gouv.fr





Et d’ailleurs SSLLabs va bientôt changer leurs notations, et même les impôts vont virer au rouge à cause de 3DES qui n’est actuellement pas sanctionné.

https://blog.qualys.com/ssllabs/2016/11/16/announcing-ssl-labs-grading-changes-f…

&nbsp;

Si vous voulez vous faire peur :

&nbsp;

https://imirhil.fr/tls/#Banques%20en%20ligne

https://imirhil.fr/tls/gouv.fr.html



/me va encore se faire gronder par @david_l /o



Pour revenir sur les mots de passe … ameli les bride à 13 caractères <img data-src=" />

Et le ponpon ? Il faut utiliser des chiffres uniquement <img data-src=" />


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”…


ah oui ça le coup des fameux caractères only, une belle aberration !








zhebulonn a écrit :



J’ai jamais compris l’utilité de brider les mots de passe, que ce soit par la taille ou par des caractères inutilisables.





Certains limitent la taille de part la technologie utilisée pour les stocker (genre si ils sont stockés dans un system unix relativement vieux, c’est limité à 8 characters.

Certains limitent les charactères pour éviterles attaques par injection etc. (alors qu’il “suffit” de bien encoder le mdp).



Mais en général oui ce sont des mauvaises raisons.



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 <img data-src=" />


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 ?








Flogik a écrit :



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 ?





Oui c’est bizarre… ça voudrait dire soit que ton “toto” est le nombre maxi de caractères autorisés par le système de mdp (et qu’il ignore le reste), soit que le hash de ton mdp est le même pour toto, toto85 ou totoabcd (ça me semble impossible), soit que le système connait ton mot de passe en clair et accepte quand c’est presque ça (ça serait complètement con <img data-src=" />), soit enfin que tu as un système quelconque d’auto-complétion dans ton navigateur qui by-pass ce que tu saisies (là aussi ça serait con puisque ça t’interdirait de fait de changer ton mdp)



edit pour éviter de mettre l’orthographe trop en PLS



Ç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…


ah oui y a ça aussi <img data-src=" /> (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”)


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…








Tatsu-Kan a écrit :



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…





Après vérification, ils ont du arrêter en 2010. :CoupDeVieux:









Minikea a écrit :



pour Free par contre c’est juste intolérable… <img data-src=" />





Pas que pour Free en fait. C’est juste intolérable.



Au passage, Pole emploi, en plus d’envoyer le mot de passe par email limite sa taille à 12 caractères…





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.








DUNplus a écrit :



Je n’ai jamais compris comment un hash peut être non réversible….





Article super court, qui explique pourquoi :)

https://learncryptography.com/hash-functions/why-are-hashes-irreversible



&nbsp;









Ne2l a écrit :



Pas que pour Free en fait. C’est juste intolérable.



Au passage, Pole emploi, en plus d’envoyer le mot de passe par email limite sa taille à 12 caractères…







En même temps, vu l’utilité de Pole emploi, qui voudrait piquer un compte ? <img data-src=" />



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.


et un accès mot de passe par un lecteur biométrique + un code de déverrouillage en cas de non fonctionnement ?


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.&nbsp;



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.&nbsp;





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.








popolski a écrit :



et un accès mot de passe par un lecteur biométrique + un code de déverrouillage en cas de non fonctionnement ?





de mon point de vue, ça posera le même problème exprimé en d’autres termes




  • ton ‘empreinte’ biométrique sera-t-elle stockée (en clair ou pas : double voire triple problème) ou juste son hash ? (possibilité de collision en fonction de la fonction de hashage choisie ?)

  • forte probabilité de choisir le code de déverrouillage en choisissant un code (trop) simple ou rapide (simplicité d’utilisation vs sécurité)



<img data-src=" />








RaoulC a écrit :



Des maths oui, avec des opérations non bijectives..



Ton MDP c’est ABCDEF. Maintenant que l’on attribue une valeur arbitraire à chaque lettre et qu’on les additionne.

Tu obtient un résultat, le hash . A partir du résultat tu retrouve comment ABCDEF?



Évidemment, c’est simplifié à l’extrême, les formules mathématiques sont bien plus complexes hein :)

&nbsp;

Tu ne connait ni la longueur du mdp initial ni les caractères qui le composent.

&nbsp;

Il reste donc a tester toutes les combi de caractères avec la formule de calcul pour tester si tu peut en trouver une qui donne le même résultat : l’attaque par force brute. Et tu ne retrouvera pas forcement le BON mot de passe, juste un qui passe , une collision !



Pour accélérer l’attaque on peut employer des dictionnaires.. les gens emploient souvent des mots.



Ce qui explique que l’on augmente la force d’un mot de passe en employant majuscules minuscules chiffres et caractères spéciaux et sa taille : à partir du hash, beaucoup plus de caractères différents / plus de possibilité de caractères à tester&nbsp; = grosse multiplication du temps de calcul.



C’est pour cela que les algo de hash sont dépréciés avec le temps : si ca devient trop facile de trouver des collisions , on passe à un autre. Le MD5 c’est finit normalement, et le SHA1 je croit aussi.





Avec un hash la bruteforce est tjrs possible, c’est plus plus coûteux en perfs c’est tout.









macintosh_plus a écrit :



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.





Un site qui pré-rempli le champs de mot de passe, j’ai jamais vu ça. Tu es sûr de ne pas confondre avec l’enregistrement des mots de passe par ton navigateur ?



Je me souviens d’un site (un jeu par navigateur, vers 2001-2002) qui demandait un mot de passe unique <img data-src=" />



C’est à dire que deux utilisateurs ne pouvaient pas avoir le même mot de passe…








DUNplus a écrit :



Je n’ai jamais compris comment un hash peut être non réversible….





Parce qu’il y a des dépassements tronqués

Une version simplifiée serait de considérer que le mot de passe est un nombre, ainsi que la fonction de hashage.

&nbsp;

&nbsp;(2^23-1) * (2^13-1) % 10^6 = 68711079937 % 10^6 = 079937



Saurais-tu retrouver les nombres que j’ai multipliés à l’origine pour obtenir 079937 sans autre information ? :)



Si tu prends une empreinte, la taille du mot de passe ne joue pas.

La taille de l’empreinte est fixe. <img data-src=" />

EDIT : bbqed <img data-src=" />


L’authentification par biométrie est une très mauvaise idée, pour deux principales raisons :





  1. imaginons une authentification par empreintes digitales (et non numériques, cette fois). Soit, littéralement, le truc que tu laisses traîner PARTOUT, parce qu’il s’avère que les empreintes sont au bout des doigts, et que les doigts servent à toucher à peu près tout. Il est trivial, pour peu que l’on soit physiquement proche de toi, de voler tes empreintes. La reconnaissance d’iris n’est pas mieux, car une simple photographie permet de contourner les systèmes. Pour faire un parallèle douteux, c’est à peu près aussi sûr que d’avoir ton mot de passe écrit sur un post-it attaché sur ton écran.



  2. tout moyen d’authentification se doit d’être révoquable. Il est indispensable de pouvoir à tout moment changer de mot de passe. Comme il est possible de changer la serrure de ta porte d’entrée si tu crains que ta clé ait été copiée. C’est naturellement impossible avec la biométrie, et c’est très grave. Ça signifie également qu’un élément biométrique sera le même pour t’authentifier sur tous les systèmes qui le reconnaissent.


Connaitre un mot de passe donne souvent des indications sur les autres, ou des fois il est identique.


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…








Poppu78 a écrit :



[…]

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.





Breton spotted <img data-src=" />



Que penser de ça :

http://hpics.li/218c4cb








gordonzola a écrit :



L’authentification par biométrie est une très mauvaise idée, pour deux principales raisons :




1) imaginons une authentification par empreintes digitales (et non numériques, cette fois). Soit, littéralement, le truc que tu laisses traîner PARTOUT, parce qu’il s’avère que les empreintes sont au bout des doigts, et que les doigts servent à toucher à peu près tout. Il est trivial, pour peu que l’on soit physiquement proche de toi, de voler tes empreintes. La reconnaissance d’iris n’est pas mieux, car une simple photographie permet de contourner les systèmes. Pour faire un parallèle douteux, c’est à peu près aussi sûr que d’avoir ton mot de passe écrit sur un post-it attaché sur ton écran.      






2) tout moyen d’authentification se doit d’être révoquable. Il est indispensable de pouvoir à tout moment changer de mot de passe. Comme il est possible de changer la serrure de ta porte d’entrée si tu crains que ta clé ait été copiée. C’est naturellement impossible avec la biométrie, et c’est très grave. Ça signifie également qu’un élément biométrique sera le même pour t’authentifier sur tous les systèmes qui le reconnaissent.








Il me semble que la reconnaissance proposée par Windows Hello sur Windows 10 n'est pas contournable par une photographie.     



Ca passe par 3 lentilles : une normale, une infrarouge et une “3D” qui analyse la profondeur, ce qui empêche la photographie de déverrouiller le système.

&nbsp;

Idem pour un jumeau, ça ne marche pas.



On peut en penser que ton lien n’inspire pas confiance, vu qu’il est réduit et présenté sans contexte :)


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








Lochnar a écrit :



On parle pas mal d’identification a l’aide des réseaux veineux des doigts&nbsp;





Ah, Ah, Ah!<img data-src=" />



Tu sais que le réseau sanguins est dynamique (comme le système osseux) et passe son temps à se construire et se déconstruire?



https://fr.wikipedia.org/wiki/Facteur_de_croissance_de_l%E2%80%99endoth%C3%A9liu…



Bref, si le système est trop fin, il va déclencher un faux négatif car la personne se sera remis aux pompes claqués et ainsi densifier son réseau sanguin. Si le système est plus lâche pour éviter cet écueil, il va générer des faux positifs et perdre son caractère discriminant.



En conclusion, je suis septique devant ce genre de technologie (réseau sanguin, voie, etc …).



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 “


Dam, je me suis fait repérer <img data-src=" />


Ça existe. Ça s’appelle NO_CYPHER_OVERLAP, mais faudrait juste améliorer la page d’erreur :P

&nbsp;

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…


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).


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.


&nbsp;Faudrait aussi (surtout?) améliorer la lecture des messages d’erreur par les utilisateurs.



Mais je n’ai rien pour ça <img data-src=" />


Je pense que cela pose un problème d’utilisation au final, puisque tu dois toujours avoir le fichier de clé avec toi.


Ça marche peut-être aussi en saisissant n’importe quoi <img data-src=" />


Les vieux souvenirs persistants qui paraissent proches !


Une prise d’otage et la personne à authentifier est bien vivante.


L’ANSSI peut-être.


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.


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.


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.








lanoux a écrit :



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.



Et donc, surtout, faut rien changer.



Au même titre que d’autres choses, un ordinateur est avant tout un outil et parfois, les outils, faut les faire évoluer.



&nbsp;





aeris22 a écrit :



&nbsp;

Surtout que ça met en danger tout le monde, y compris ceux avec des navigateurs plus ou moins à jour.



&nbsp;Parce que le serveur supporte des trucs pourris, je peux forcer les navigateurs à se rabattre sur ces trucs pourris alors que normalement ils auraient du utiliser quelque chose de plus fort.

Ou encore dans le cas de EBP, un de leur serveur supporte du SSLv2, je peux donc profiter de la faille DROWN même si votre navigateur ne supporte pas cette veille suite de chiffrement.



&nbsp;Dit autrement, si vous êtes sur le même réseau que moi (au pif au Starbuck du coin ou sur un wifi public), je peux plutôt « facilement » (c’est l’affaire de 2 ou 3 heures voire de quelques minutes pour les trucs les pires) avoir accès à vos cookies ou à votre mot de passe, et ainsi récupérer tous vos plans comptables ou les fiches de paies de tous vos employés. Même si votre navigateur Firefox est le plus à jour disponible…



Je sais bien.



D’ailleurs, c’est bien là qu’est tout le problème dans ce cas, si ça n’impactait que ceux qui s’en foutent d’être à jour et autre, ce ne serait pas tant un problème.



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.








DUNplus a écrit :



Je n’ai jamais compris comment un hash peut être non réversible…











Xaelias a écrit :



La plupart des algos sont basés sur le fait qu’on est globalement incapable de factoriser des grands nombres en facteurs premiers en un temps raisonnable.





Non, ça c’est le chiffrement.







kvasir a écrit :



Il suffit d’utiliser une fonction surjective et non bijective.https://fr.wikipedia.org/wiki/Surjection





C’est vrai mais c’est abstrait au premier abord :-) .



Je réponds en retard donc j’ai sans doute été grillé, mais à tout hasard, pour répondre à DUNplus de la façon la plus simple, le hachage consistant à réduire une données de X octets à une donnée de Y octets (avec Y beaucoup plus petit), une fois qu’on a Y, comment retrouver X ?



Concrètement, mettons que tu additionnes la valeur (ASCII) des lettres du mot de passe et tu gardes la valeur sur 1 octet (ça ne convient pas en vrai pour la sécurité mais c’est du hachage).

“ABCD9” -&gt; somme = 65 + 66 + 67 + 68 + 57 = 323 -&gt; 67 (modulo 256, on ne garde que le dernier octet)

“BCDE5” -&gt; somme = 66 + 67 + 68 + 69 + 53 = 323 -&gt; 67 (modulo 256, on ne garde que le dernier octet)

On a déjà 2 mots de passe avec le même hash, et on peut en trouver beaucoup d’autres.

Donc ce n’est pas réversible.







melchizedech a écrit :



ç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).





DES c’est un algorithme de chiffrement.

Concernant MD5, on a trouvé une méthode pour générer des collisions, mais je crois que pour le cas général, ça reste solide, sauf à avoir les moyens informatiques d’un État ou d’une riche organisation criminelle.



Eh bien, j’en ai fait des fautes sur ce commentaire. ça m’apprendra à aller vite dans mes réponses.








OlivierJ a écrit :



On a déjà 2 mots de passe avec le même hash, et on peut en trouver beaucoup d’autres.

Donc ce n’est pas réversible.





tu devrais revoir ta formulation, ce n’est pas parce que 2 sources donnent le même résultats que ce n’est pas réversible ;)









zhebulonn a écrit :



J’ai jamais compris l’utilité de brider les mots de passe, que ce soit par la taille ou par des caractères inutilisables.





Moi non plus.

Perso j’ai toujours autorisé au moins 16 caractères, parfois plus.

Et vu qu’après le mot de passe était haché, peu importe les caractères présents dedans.







ZoZo a écrit :



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.





Vu que tu rentres ton mot de passe dans un formulaire, ça me paraît difficile de rentrer plusieurs Mo <img data-src=" /> .

Et j’ai toujours vu mettre des limites dans les propriétés de champs texte en terme de longueur (genre 16, 20 ou 32 pour un mot de passe).







ZoZo a écrit :



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.





Je n’ai pas compris tout de suite de quoi tu parlais avec cette histoire de place, je suppose que c’est quand il s’agit d’UTF-8 ? Ceux des années 80 qui économisaient le caractère, ils ne connaissaient pas l’UTF-8 <img data-src=" /> .









aeris22 a écrit :



Même si en entrée tu lui as mis l’intégral des 2To de ta collection de porn ou que ton mot de passe contient des sinogrammes encodés en UTF-8…





<img data-src=" />



Et tu ne peux normalement jamais rentrer plus que quelques caractères quand tu entres un mot de passe sur un site.









yyouf a écrit :



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”&nbsp;<img data-src=" />



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…





J’ai eu le cas, sur un site que de nombreuses personnes utilisent surement ici, pour les CSP+. Je tairais leur nom vu le temps qu’ils ont mis à réagir mais bon.&nbsp; Ils m’ont recontacté pour me remercier et finalement ils ont corrigés le tir et sont passés en https dans la foulée









Xaelias a écrit :



Certains limitent la taille de part la technologie utilisée pour les stocker (genre si ils sont stockés dans un system unix relativement vieux, c’est limité à 8 characters.





Jamais vu ça (et je connais Unix depuis 1991), et je ne vois pas pourquoi ça limite. Tu confonds avec une autre limite des TRÈS vieux Unix alors, peut-être la taille des mots de passe des comptes Unix.







Xaelias a écrit :



Certains limitent les charactères pour éviterles attaques par injection etc. (alors qu’il “suffit” de bien encoder le mdp).





<img data-src=" />

En effet, pour éviter les attaques il suffit soit d’échapper les caractères comme l’apostrophe, soit d’utiliser des procédures stockées (ou prepared statement) qui empêchent les injections.









zethoun a écrit :



tu devrais revoir ta formulation, ce n’est pas parce que 2 sources donnent le même résultats que ce n’est pas réversible ;)





Tu te trompes.

Si 2 sources donnent le même résultat, c’est que ce n’est pas réversible. Ce qui est réversible c’est ce qui te permet de retrouver l’information de départ, comme avec une compression sans perte (zip, gzip, etc.).

Et dans un hash, surtout quand c’est “XyZaB4u37Vjk” va trouver une fonction qui te donne le hash de départ, sachant qu’en plus plusieurs longueurs de mot de passent peuvent générer le hash en question.



Sinon tu vas révolutionner d’une part les maths et d’autre part la compression de données aussi.



C’est ce que je dit, en substance. Surtout sur la fin : la puissance des pc monte =&gt; on change d’algo :)


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 ?








aeris22 a écrit :



Ça existe. Ça s’appelle NO_CYPHER_OVERLAP, mais faudrait juste améliorer la page d’erreur :P

&nbsp;

https://null.badssl.com/&nbsp;



&nbsp;

C’est clairement pas compréhensif pour l’utilisateur final.



Il faudrait un code erreur spécifique comme le 404.









YamaLandia a écrit :



Il me semble que la reconnaissance proposée par Windows Hello sur Windows 10 n’est pas contournable par une photographie.

Ca passe par 3 lentilles : une normale, une infrarouge et une “3D” qui analyse la profondeur, ce qui empêche la photographie de déverrouiller le système.

 

Idem pour un jumeau, ça ne marche pas.







Et bien évidemment, toutes les webcam trouvables dans le commerce contiennent ces fameuses 3 lentilles…..



Bref, encore un bon moment de rigolade ^^



c’est pour ça que Windows Hello n’est compatible qu’avec 3 ou 4 webcam seulement à l’heure actuelle ;)








zethoun a écrit :



c’est pour ça que Windows Hello n’est compatible qu’avec 3 ou 4 webcam seulement à l’heure actuelle ;)







Oh, autant pour moi ^^



Mais du coup ca sent le produit mort né ^^









eliumnick a écrit :



Et bien évidemment, toutes les webcam trouvables dans le commerce contiennent ces fameuses 3 lentilles…..




Bref, encore un bon moment de rigolade ^^







<img data-src=" />



&nbsp;Si ta cam a pas ces trois lentilles, Windows Hello ne te propose pas la reconnaissance faciale, c’est aussi simple que ça…

&nbsp;&nbsp;

Même principe sur mobile ou seuls les 950 et 950 XL le propose (de mémoire)



Edit : grillé



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)








zethoun a écrit :



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)







Oula oui, logitech en sort une à 239 euros, c’est sur ca va cartonner ^^



Plus sérieusement, ca existe des gens prêt à dépenser autant dans une webcam ? ^^









eliumnick a écrit :



Oula oui, logitech en sort une à 239 euros, c’est sur ca va cartonner ^^




  Plus sérieusement, ca existe des gens prêt à dépenser autant dans une webcam ? ^^








  Il y a d'autres modèles : celui de chez Razer est déjà moins cher que Logitech (149$). Comme d'habitude, il y a plusieurs gammes.       






 Ensuite, les nouveau laptops embarquent de plus en plus cette technologie (notamment les DELL XPS).       

D'autres exemples mis en avant pas MS :&nbsp;https://www.microsoftstore.com/store/msusa/en\_US/cat/Windows-Hello-PCs/categoryI...&nbsp;(et y'en a pas des prix abordables, je pense par exemple au DELL Inspirion)


vu les carac du bestiaux, c’est pas si cher que ça si tu en as le besoin (rappel: 4K et HDR…)


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…








DUNplus a écrit :



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 ?





Apparemment tu devrais relire certains commentaires <img data-src=" /> .



Plusieurs problèmes :




  • on ne connaît pas forcément le “sel” utilisé -&gt; c’est mort

  • ça dépend ce que tu appelles “liste limitée” (si cette limite est haute, c’est mort)

  • si on suppose qu’il n’y a pas de sel, il y a le temps pour tester tous les mots de passes alpha-numériques à 8 puis 9 puis 10 puis 11 puis 12 caractères (voire plus) : si tu mets des mois ou (plus probablement) des années, pas très utile



    Ensuite, plusieurs cas de figure :

  • Si tu ne peux pas entrer plus de 3 fois un mot de passe erroné dans un système avant blocage, tu n’es guère avancé.

  • Si le système attend 5 secondes après une tentative erronée, si tu as 100 000 mots de passe potentiels, tu en as pour un bout de temps (avec un programme évidemment), et ne parlons pas de plus.

  • En général, un système bien conçu se rendra compte de multiples tentatives erronées et finira par bloquer le compte, ou attendre plus longtemps entre 2 tentatives (avec un gmail ou facebook, je pense qu’on ne doit pas pouvoir tester très longtemps).









YamaLandia a écrit :



Il me semble que la reconnaissance proposée par Windows Hello sur Windows 10 n’est pas contournable par une photographie.

Ça passe par 3 lentilles : une normale, une infrarouge et une “3D” qui analyse la profondeur, ce qui empêche la photographie de déverrouiller le système.

Idem pour un jumeau, ça ne marche pas.





L’histoire des “3 lentilles” me paraît bizarre, car une lentille infrarouge ça ne veut pas dire grand chose, ni une lentille 3D. Une lentille normale laisse passer de l’infrarouge (mais moins que du visible, et dépendant de la longueur d’onde et du matériau).



Je suppose que la webcam est capable de changer le filtre devant le capteur, dont un qui ne laisse rentrer que les infrarouges, et un qui filtre les infrarouges (un capteur CMOS est sensible au visible et aux infrarouges généralement, mais la matrice de Bayer les filtre au passage dans cas d’un appareil photo).

Vu que la webcam doit pouvoir filmer en couleur aussi, j’imagine que soit les pixels rouges laissent passer l’infrarouge pas défaut, soit qu’il y a un 2e capteur plus petit juste pour l’IR.

Pour la 3D, ça utilise peut-être les 2 capteurs en même temps, pour une vue stéréoscopique.



Le plus simple serait d’aller creuser la question, la réponse doit être en ligne je suppose.







eliumnick a écrit :



Et bien évidemment, toutes les webcam trouvables dans le commerce contiennent ces fameuses 3 lentilles…











zethoun a écrit :



c’est pour ça que Windows Hello n’est compatible qu’avec 3 ou 4 webcam seulement à l’heure actuelle ;)






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).&nbsp; 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 !








OlivierJ a écrit :



L’histoire des “3 lentilles” me paraît bizarre, car une lentille infrarouge ça ne veut pas dire grand chose, ni une lentille 3D. Une lentille normale laisse passer de l’infrarouge (mais moins que du visible, et dépendant de la longueur d’onde et du matériau).



Je suppose que la webcam est capable de changer le filtre devant le capteur, dont un qui ne laisse rentrer que les infrarouges, et un qui filtre les infrarouges (un capteur CMOS est sensible au visible et aux infrarouges généralement, mais la matrice de Bayer les filtre au passage dans cas d’un appareil photo).

Vu que la webcam doit pouvoir filmer en couleur aussi, j’imagine que soit les pixels rouges laissent passer l’infrarouge pas défaut, soit qu’il y a un 2e capteur plus petit juste pour l’IR.

Pour la 3D, ça utilise peut-être les 2 capteurs en même temps, pour une vue stéréoscopique.



Le plus simple serait d’aller creuser la question, la réponse doit être en ligne je suppose.





“Devices with Intel® RealSense™ Camera have three lenses: a conventional lens, an infrared lens, and an infrared laser projector lens.”



https://communities.intel.com/thread/63204



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…








aeris22 a écrit :



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.





C’est moche non ? En tous cas je ne ferais pas ça vu l’importance du sel.







aeris22 a écrit :



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.





J’avoue que j’ai effectivement loupé ce point, il suffit d’en trouver un qui génère le hash <img data-src=" /> <img data-src=" /> .



Histoire d’être certain :




  • si la base de hash est salée et que le sel n’est pas en possession de l’attaquant, c’est mort non ?

  • si on dispose du sel, avec une bonne fonction de hash, j’imagine que trouver un mot de passe qui génère le hash recherché, ça peut prendre un temps dingue, non (vu que c’est le but du hash d’empêcher la chose) ?









YamaLandia a écrit :



“Devices with Intel® RealSense™ Camera have three lenses: a conventional lens, an infrared lens, and an infrared laser projector lens.”



https://communities.intel.com/thread/63204





Merci pour le lien, mais c’est pas encore clair pour moi pour le fonctionnement concret.

Par ailleurs, “infrared laser projector lens”, c’est quoi ?



Au moins, on peut constater la bonne homogénéité de la communication de Free, quelque soit le domaine .

:o








OlivierJ a écrit :



Je réponds en retard donc j’ai sans doute été grillé, mais à tout hasard, pour répondre à DUNplus de la façon la plus simple, le hachage consistant à réduire une données de X octets à une donnée de Y octets (avec Y beaucoup plus petit), une fois qu’on a Y, comment retrouver X ?



Concrètement, mettons que tu additionnes la valeur (ASCII) des lettres du mot de passe et tu gardes la valeur sur 1 octet (ça ne convient pas en vrai pour la sécurité mais c’est du hachage).

“ABCD9” -&gt; somme = 65 + 66 + 67 + 68 + 57 = 323 -&gt; 67 (modulo 256, on ne garde que le dernier octet)

“BCDE5” -&gt; somme = 66 + 67 + 68 + 69 + 53 = 323 -&gt; 67 (modulo 256, on ne garde que le dernier octet)

On a déjà 2 mots de passe avec le même hash, et on peut en trouver beaucoup d’autres.

Donc ce n’est pas réversible.





DES c’est un algorithme de chiffrement.

Concernant MD5, on a trouvé une méthode pour générer des collisions, mais je crois que pour le cas général, ça reste solide, sauf à avoir les moyens informatiques d’un État ou d’une riche organisation criminelle.





C’est peut être plus simple, mais je trouve que c’est dangereux d’expliquer le hachage par les collisions. Un bon système de hachage doit justement éviter au maximum les collisions (et idéalement n’en avoir aucune).



Le principe de base du hachage de mot de passe, c’est d’avoir une fonction simple (dans le sens qu’elle se calcule rapidement) mais qui n’est pas inversible simplement.









OlivierJ a écrit :



C’est moche non ? En tous cas je ne ferais pas ça vu l’importance du sel.





&nbsp;Le sel n’est pas critique et n’a aucun intérêt à être caché. Sa publication ne change rien à la sécurité, son objectif est uniquement d’empécher un bruteforce massif de la table et d’obliger un attaquant à travailler par utilisateur.



&nbsp;Dans tous les cas, comme il doit être unique par utilisateur, ça sera difficile de le garder planquer.

Certains le code en dur, mais il est du coup commun à tous les utilisateurs et ne sert alors à rien (on bruteforcera toute la base comme s’il n’y avait pas de sel).





OlivierJ a écrit :



Histoire d’être certain :




  • si la base de hash est salée et que le sel n’est pas en possession de l’attaquant, c’est mort non ?

  • si on dispose du sel, avec une bonne fonction de hash, j’imagine que trouver un mot de passe qui génère le hash recherché, ça peut prendre un temps dingue, non (vu que c’est le but du hash d’empêcher la chose) ?





    &nbsp;Si le sel n’est pas en possession de l’attaquant, c’est mort, mais pas pour l’attaquant, pour toi. Ça veut dire que tu as raté quelque chose sur le principe du sel :P Cf juste au-dessus.

    &nbsp;

    &nbsp;Si ton algo de hash est correct, tu vas en effet galérer à trouver une collision. Tu auras alors effectivement plutôt intérêt à faire une attaque par dictionnaire que par pure force brute, la probabilité que ton utilisateur ait un mot de passe faible étant bien plus grande (en pratique elle est même proche de 1…) que celle de trouver une collision sur SHA2, scrypt, PBKDF2 ou argon2…

    &nbsp;Après, on trouve dans le commerce pour quelques centaines ou milliers d’euro des machines capables de calculer du SHA2 à plusieurs centaines de terra hash par seconde (Bitcoin s’est même spécialisé là dedans)… Ça prendra toujours quelques 262267361648628767629672630392222738306493224672122028428 d’années à collisionner un hash, mais on fait quand même des progrès spectaculaires en ce moment (les nombres commencent à pouvoir s’écrire sur une seule ligne :P).



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)”.








aeris22 a écrit :



Dans tous les cas, comme il doit être unique par utilisateur, ça sera difficile de le garder planquer.

Certains le code en dur, mais il est du coup commun à tous les utilisateurs et ne sert alors à rien (on bruteforcera toute la base comme s’il n’y avait pas de sel).





Je n’avais pas vu ça, car je pensais qu’un sel commun à tout le monde revenait à modifier la fonction de hashage. Tu es sûr que ça revient tout à fait au même ? Qu’on peut obtenir le même hash recherché sans le sel ?







aeris22 a écrit :



Ça prendra toujours quelques 262267361648628767629672630392222738306493224672122028428 d’années à collisionner un hash, mais on fait quand même des progrès spectaculaires en ce moment (les nombres commencent à pouvoir s’écrire sur une seule ligne :P).





C’est ce qu’il me semblait, merci.



Mais c’est pas du bon hachage, même en dehors du cadre de la sécurité. <img data-src=" />



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).


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).








OlivierJ a écrit :



J’expliquais le côté non inversible avec un exemple le plus simple possible.





C’est justement la partie que je critique : il ne faut pas expliquer le côté non inversible par de la collision <img data-src=" />.









OlivierJ a écrit :



Je n’avais pas vu ça, car je pensais qu’un sel commun à tout le monde revenait à modifier la fonction de hashage. Tu es sûr que ça revient tout à fait au même ? Qu’on peut obtenir le même hash recherché sans le sel ?





Si le sel est commun, disont SSSS, ça revient à transformer un bruteforce de tous les XXXX vers HHHH en tous les SSSSXXXX vers HHHH. Donc plutôt que de générer des données au pif, de calculer le hash et de vérifier s’il est dans la table, tu vas générer une donnée au pif, lui foutre SSSS devant, hashé et vérifier la base.

Autant dire qu’en terme de complexité pour l’attaquant, tu n’as strictement rien changé, il pourra toujours comparé chacun de ses hashs calculés avec l’ensemble de la base.



Avec un sel par utilisateur, il devra faire la même procédure pour chaque utilisateur, ralentissant son attaque d’un facteur égal au nombre d’utilisateur.



Le problème est bien visible avec un exemple.



&nbsp;Pas de sel ou un sel partagé

Utilisateur 1 : HHHH

Utilisateur 2 : IIIIII

Utilisateur 3 : JJJJ

Utilisateur 4 : HHHH



Déjà je vois immédiatement que 1 et 4 ont le même pass.

Je génère des tonnes de pass aléatoires, l’un d’eux (pppp) me donne HHHH. J’ai donc le pass de 1 ET de 4.

&nbsp;Si j’ai un sel partagé SSSS, je calcule juste hash(SSSSpppp) au lieu de hash(pppp), si ça me donne HHHH, j’ai aussi le pass de 1 ET de 4. Durant mon parcours des nombres aléatoires, j’ai aussi très bien pu trouver IIII et JJJJ, et donc avoir casser 2 et 3 au passage.



&nbsp;Sel unique

Utilisateur 1 : SSSS|HHHH

Utilisateur 2 : TTTT|IIIIII

Utilisateur 3 : UUUU|JJJJ

Utilisateur 4 : VVVV|KKKK



Bien que 1 et 4 utilisent le même mot de passe, je n’ai déjà plus la possibilité de le deviner a priori.

&nbsp;Je génère des tonnes de pass aléatoires, l’un d’eux (pppp) concaténé avec SSSS me donne HHHH. J’ai donc le pass de 1. Je ne peux pas deviner que j’ai aussi le pass de 4, puisqu’il aurait fallu que je calcule aussi VVVVpppp ce que je n’ai pas fait… Même si au court de mon parcours je tombe sur IIII à partir de iiii, j’ai en fait calculer hash(SSSSiiii) = IIII, et donc ça ne veut absolument pas dire que j’ai trouvé le passe de 2, puisqu’il aurait fallu en fait que je calcule hash(TTTTiiii)…



&nbsp;Bilan : avec un sel unique pour chaque utilisateur, un attaquant est incapable de casser plus de 1 utilisateur à la fois, alors qu’avec un sel partagé ou pas de sel du tout, il va casser tous les utilisateurs d’un coup. Ou encore dit autrement, en ayant parcouru l’ensemble des valeurs des 2^256 possibilités de SHA2, il n’aura trouvé qu’un seul utilisateur avec un sel unique alors qu’il aura trouvé TOUS les utilisateurs sans sel ou avec un sel partagé.









Mihashi a écrit :



mais, j’insiste, ce n’est pas que pour cette raison que c’est non inversible





En fait si, la condition de collision est suffisante pour garantir la non réversibilité d’une fonction.

Tout algo connaissant des collisions est non réversible puisqu’au moins 2 valeurs de départ pointant sur la même valeur d’arrivée, il est impossible de décider quelle est la “bonne” valeur de départ à partir d’une de ces valeurs.



Par contre c’est effectivement une mauvaise idée de se servir de cette propriété en cryptologie et surtout en hashage, puisqu’une bonne fonction de hashage doit justement minimiser les collisions.

Dans le cas de SHA2, on sait qu’il existe forcément des collisions puisque l’ensemble de départ (tout :P) est infiniment plus grand que l’ensemble d’arrivée ([0-2^256]) et donc qu’il existe même une infinité de valeurs possédant le même hash. Et donc que la fonction est mathématiquement non inversible.



&nbsp;Cryptographiquement, on va plutôt raisonner en restreignant l’ensemble de départ à aussi [0-2^256]. Comme SHA2 est une bonne fonction de hash cryptographique, il se trouve qu’elle va être très proche d’une bijection de [0-2^256] sur [0-2^256], donc n’avoir que peu de points en doublon, et donc être théoriquement inversible (« presque partout » comme diraient les mathématiciens).

&nbsp;La vraie définition de l’inversibilité en crypto est surtout qu’il n’existe pas de manière plus efficace de calculer cette pseudo-bijection inverse que celle consistant à fabriquer la table inverse par force brute en calculant chaque image pour chaque valeur de [0-2^256]. Et aujourd’hui, en l’état des connaissances, c’est juste physiquement impossible de travailler sur des données aussi collosales qu’un espace de 256 bits (espace de stockage supérieur aux nombres d’atomes constituant l’Univers), temps de calcul dépassant l’âge actuel de l’Univers, …).









OlivierJ a écrit :



Jamais vu ça (et je connais Unix depuis 1991), et je ne vois pas pourquoi ça limite. Tu confonds avec une autre limite des TRÈS vieux Unix alors, peut-être la taille des mots de passe des comptes Unix.





&lt;tousse&gt;

Solaris 10

&lt;/tousse&gt;



Et c’est pas si vieux que ça. Même chez Sun, à l’époque (et là, je parle de 2010), tu pouvais taper n’importe quoi après les 8 premiers caractères du mot de passe pour les sessions SunRay, et ça passait. En fait, c’était pas clairement documenté (tu m’étonnes !), la seule obligation était de mettre de mettre des caractères variés parmi les 8 premiers caractères…



On s’en est rendu compte parce qu’un de mes collègues avait appuyé sur entrée avant d’avoir tapé son mot de passe entier, et avait quand même ouvert sa session.



C’est la configuration par défaut, mais ça peut se régler:

https://blogs.oracle.com/darren/entry/what_is_the_maximum_password



Mais je ne suis pas persuadé que beaucoup d’utilisateurs de Solaris 10 s’en soucient réellement (bien qu’ils le devraient).



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 <img data-src=" />, juste que ce n’est pas en France)&nbsp;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 ?








aeris22 a écrit :



En fait si, la condition de collision est suffisante pour garantir la non réversibilité d’une fonction.





Mais pour les fonctions de hachage ce ne sont pas les possibilités de collisions qui font qu’elles sont non inversible. Ou alors ce sont vraiment des fonctions de hachage très très mauvaises.









sr17 a écrit :



En même temps, vu l’utilité de Pole emploi, qui voudrait piquer un compte ? <img data-src=" />





Dans &nbsp;tous les cas, le probleme n’est pas fdorcement les données du compte même. Mais vu que les utilisateurs ont tendance a utiliser le meme mot de passe pour plusieurs services, pirater la BD de Pole emploi donne acces a pas mal d’autres compte avec même email/pwd sur d’autres sites sécurisés correctement.



Sinon ceux qui veulent médire des sites gouvernementaux peuvent aller voir ici :https://www.openbugbounty.org/search/?search=gouv.fr&type=host









aeris22 a écrit :



(« presque partout » comme diraient les mathématiciens).





Tu vas faire hurler les mathématiciens. Presque partout à une signification très précise, et plutôt incompatible avec les ensembles finis. <img data-src=" />







aeris22 a écrit :



La vraie définition de l’inversibilité en crypto est surtout qu’il n’existe pas de manière plus efficace de calculer cette pseudo-bijection (…)





Corrige-moi si je me trompe, mais n’est-ce pas plutôt qu’on ne connait pas de manière? Je n’ai pas de scoop à annoncer, mais la nuance est tout de même de taille, quand on regarde l’histoire de la crypto.

Bon, je dois y aller, l’ordi quantique que je bricole dans mon garage se languit, il faut que je révise mon Shor.



Bases de données client et tout








OlivierJ a écrit :



Jamais vu ça (et je connais Unix depuis 1991), et je ne vois pas pourquoi ça limite. Tu confonds avec une autre limite des TRÈS vieux Unix alors, peut-être la taille des mots de passe des comptes Unix.





<img data-src=" />

En effet, pour éviter les attaques il suffit soit d’échapper les caractères comme l’apostrophe, soit d’utiliser des procédures stockées (ou prepared statement) qui empêchent les injections.





J’avoue ne jamais avoir cherché la source exacte de la limitation. Je sais que dans mon école par exemple, les mdp étaient stockés de telle manière que seuls les 8 premiers charactères étaient utilisés. Le système acceptait les mdp plus long, mais les charactères [8:] ne servaient strictement à rien et tu pouvaient ne pas les spécifier ou mettre autre chose à la place.

Et clairement quand je vois une taille max de 8 je repense à cela.









Zulgrib a écrit :



Bases de données client et tout





Sur papier = pas de risque de piratage&nbsp;<img data-src=" />









aeris22 a écrit :



&nbsp;Cryptographiquement, on va plutôt raisonner en restreignant l’ensemble de départ à aussi [0-2^256]. Comme SHA2 est une bonne fonction de hash cryptographique, il se trouve qu’elle va être très proche d’une bijection de [0-2^256] sur [0-2^256], donc n’avoir que peu de points en doublon, et donc être théoriquement inversible (« presque partout » comme diraient les mathématiciens).&nbsp;



On se calme, presque partout c’est quand tu as une mesure (en gros une intégrale) nulle, pas quand le nombre de points de doublon est très petit devant le nombre de points sans.



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.



&nbsp;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.








Mihashi a écrit :



Mais c’est pas du bon hachage, même en dehors du cadre de la sécurité. <img data-src=" />



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).





c’est ce que j’avais voulu dire, mais en beaucoup plus clair et précis ^^









OlivierJ a écrit :



Merci pour le lien, mais c’est pas encore clair pour moi pour le fonctionnement concret.

Par ailleurs, “infrared laser projector lens”, c’est quoi ?





Je ne me suis pas penché sur la question. Cependant, c’est bien trois éléments différents qui font le job.





Plus d’informations sur le fonctionnement :

http://iq.intel.co.uk/how-the-realsense-3d-camera-works-and-some-clever-things-y…

http://www.chipworks.com/about-chipworks/overview/blog/inside-the-intel-realsens…

&nbsp;



&nbsp;









GentooUser a écrit :



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.





hmm, tu peux m’expliquer en quoi consiste le challenge authentication dont tu parles, stp? j’ai un doute…



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 :(


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!!