Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

[MàJ] Mots de passe envoyés par mail, une pratique encore assez répandue

Une ODR = Un risque

[MàJ] Mots de passe envoyés par mail, une pratique encore assez répandue

Le 07 décembre 2012 à 16h00

Depuis peu, Samsung exploite un site où il faut créer un compte afin de profiter des offres de remboursement de la marque. Problème, la sécurité de celui-ci semble plutôt légère puisque comme encore beaucoup trop de services en ligne, il vous envoie votre mot de passe en clair. Est-ce un problème ? Nous avons décidé de faire le point.

Avec l'émergence de plus en plus de services en ligne, la sécurité des données qui y sont stockées est un enjeu qui devient vital. Or, ces derniers mois, nombreux ont été les exemples de sites qui ont laissé fuiter des informations à leur insu, avec parfois des conséquences dramatiques.

Pour chaque mot de passe stocké en clair, un chaton adepte du SHA-1 se noie

En effet, alors que le stockage d'une empreinte du mot de passe au sein d'une base de données semble tenir du bon sens pour n'importe quel développeur ayant déjà produit plus de dix lignes de code dans sa vie, force est de constater que nombreux sont les services qui se passent de cette étape, mettant en danger leurs utilisateurs.

En cas de faille et de fuite des données, les mots de passe pourront être récupérés s'ils sont stockés en clair, ainsi que les pseudo et autres e-mails. Dans le cas d'un chiffrement réversible, outre la question de la sécurité de stockage de la clef de chiffrement, c'est celle de la confidentialité des données vis-à-vis des employés de la société qui peut être posée. En effet, de telles informations ne devraient pas être lisibles par des tiers, quels qu'ils soient.

MD5 SHA-1
Un outil de calcul d'empreinte MD5 / SHA-1 pour un fichier

C'est d'ailleurs pour cela que le stockage d'une empreinte du mot de passe via SHA-1 est le plus souvent recommandé, avec un composante aléatoire (le salage). En effet, la procédure de vérification consiste alors à calculer une empreinte (hash) celui que vous avez tapé, puis de la comparer à celle qui est stockée. Si les deux versions correspondent, vous pouvez vous connecter.

Une procédure plus complexe, notamment pour ce qui est de la récupération du mot de passe en cas d'oubli, mais qui est un minimum en terme de sécurité. Car ces informations sont parfois toujours les mêmes pour un utilisateur qui ne fait pas très attention. Celui-ci pourrait alors voir toute sa vie numérique accessible à des tiers : e-mail, comptes sur les réseaux sociaux, services de stockage en ligne...

Le mot de passe unique : une erreur à ne pas commettre

Outre le fait d'utiliser des mots de passe complexes et différents pour chaque service, et des outils tels que KeePass par exemple, nous ne pouvons que vous recommander d'éviter les sociétés qui stockent une telle donnée en clair ou de manière réversible. Cela est assez facilement identifiable, puisqu'elle a souvent la mauvaise idée... de vous l'envoyer par mail, sans que l'on sache s'il est stocké dans cet état ou supprimé ensuite.

Mot de passe clair inscription

Malheureusement, dans certains cas, il est compliqué de se passer de certains services. C'est par exemple le cas du site MySamsung du constructeur, sur lequel il faut désormais créer un compte pour profiter de certaines offres de remboursement, comme nous venons de le constater.

Contacté sur le sujet, Samsung nous a confirmé que seule une empreinte SHA-1 était effectivement stockée, et que le mot de passe n'était envoyé qu'au moment du formulaire et n'était jamais mémorisé. Nous avons alors demandé à la marque quel était le but d'une telle information dans un mail et il semble que comme souvent, il s'agisse surtout d'effectuer un rappel à l'utilisateur.

Néanmoins, il nous a été précisé que le fait d'informer le client de la procédure utilisée pour le stockage serait étudiée. En effet, pour ce dernier, comment savoir si sa sécurité est assurée ou non, puisqu'aucun standard n'est défini en la matière, et qu'aucun organisme n'assure du respect des règles élémentaires.

Le mot de passe : une procédure de sécurité devenue insuffisante ?

Ces derniers mois, nous avons d'ailleurs pu remarquer une pratique similaire chez de nombreux services importants lors de l'inscription. Si certains ont depuis effectué des changements, ce n'est pas le cas de Pizza Hut, Relay, Sarenza, le service de commande d'accessoires de SFR (Modelabs), Recatch.tv, Speed Burger ou Tiilt pour ne citer qu'eux. Les revendeurs high-tech ne sont d'ailleurs pas des cas à part puisque nous avons pu constater que Boulanger, Darty et LDLC faisaient de même :

mot de passe clair inscription mot de passe clair inscription

mot de passe clair inscription mot de passe clair inscription

N'hésitez donc pas à vous en plaindre auprès du service client, ou à exiger de savoir comment était stocké votre mot de passe, lorsque vous constatez que c'est le cas, et à nous indiquer au sein de nos commentaires ceux que vous avez pu repérer vous-même. On regrettera au passage que la CNIL, qui édite un guide de sécurité des données personnelles, ne s'intéresse pas plus à la question et ne permette pas aux utilisateurs de l'alerter sur de telles pratiques.

Ces soucis posent d'ailleurs la question de l'intérêt d'une nouvelle donne au niveau des procédures de connexion. De plus en plus de services proposent une solution de double authentification, en exploitant leurs propres outils, ou ceux fournis par Amazon, Google, Intel ou encore Microsoft sur Windows Phone que ce soit en version logicielle ou matérielle.

Authenticator Blizzard

Malheureusement, cela complexifie parfois la procédure, et de telles pratiques sont encore loin d'être généralisées. Espérons que cela ne tardera pas trop à changer.

Commentaires (135)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Outre les mots de passe en clair dans un mail (merci LDLC), ce qui me choque c’est les sites des FAI où l’identifiant est un numéro de mobile et le mot de passe qui ne doit pas dépasser 4 ou 6 caractères…

votre avatar







Freud a écrit :



La clé n’est pas créée de manière pseudo-aléatoire (qu’est-ce que ça veut dire d’ailleurs ?) dans keepass, c’est simplement le hachage sha256 du master password qui est utilisée en tant que clé. C’est bien de l’AES-256 par contre.







Me souviens a avoir à bouger mon mulot comme un neuneu dans tous les sens sur une image composée de point noir&blanc pour créer un truc pseudo-aléatoire.



A moins que ça ne soit pour le Master ?? <img data-src=" />


votre avatar







FrenchPig a écrit :



Outre les mots de passe en clair dans un mail (merci LDLC), ce qui me choque c’est les sites des FAI où l’identifiant est un numéro de mobile et le mot de passe qui ne doit pas dépasser 4 ou 6 caractères…







En général, quand les mots de passe sont de taille limitée, c’est que le nombre d’essais est limité avant blocage du compte.



Mais ça reste débile effectivement, car il suffit de connaître l’identifiant d’un compte pour en verrouiller l’accès.


votre avatar







tsyr2ko a écrit :



3/ un site peut stocker les mots de passe de façon CRYPTÉE dans la base de donnée et vous le renvoyer la version décryptée lors d’une procédure de mot de passe oublié. (si un pirate accède à la BDD seule, il n’aura pas les mots de passe en clair et devra en plus de ça, accéder au source du site (sauf si le cryptage est fait par une procédure stockée, ce qui serait stupide en matière de sécurité).







Chiffrer un mot de passe c’est un comportement pas très net. J’ai pas vraiment envie de partager ce secret avec le site :/


votre avatar

mh, je sais pas s’il faut forcément voir le mal partout.



Dans ma boite, lorsqu’un individu créé son compte, le mot de passe saisi est stocké en variable pour être envoyé dans l’email de bienvenue, mais la version stockée en BDD est bien le sha1 de cette variable.

Du coup, en cas de mot de passe oublié, on en génère un à la volée et un colle un flag de modification obligatoire à la prochaine connexion.



L’envoyer en clair lors de l’inscription n’est dangereux qui si on se fait hacker sa boite mail sans avoir supprimé le mail. C’est en revanche bien plus douteux si on nous le renvoi en clair en cliquant sur mot de passe oublié.



le ptit plus : on passe par cegedim pour les congés payés et celui ci impose, alpha majuscule ET minuscule, chiffre et caractère non alpha num. Seulement cliquer sur “mot de passe oublié” le renvoi en clair <img data-src=" />. Comme la porte blindée fixée sur un mur en carton <img data-src=" />

votre avatar







David_L a écrit :



le mot de passe unique





Faut être réaliste, personne n’a l’envie, le temps ou l’énergie de retenir 50 mots de passes différents pour les 50 services où on est tous inscrits sur Internet, les comptes mails, Microsoft/Live, celui du FAI, Orange, Facebook, Google, Apple, Amazon, Steam, Origin, Pixmania, LDLC, la Fnac, Grosbill, Priceminister, eBay, CDiscount, Battle.net, Newshosting, 10 forums différents, sans oublier les trucs “hors ligne”, les mots de passe Windows et autres codes PIN…



Sans déconner, qui, hormis un pourcentage marginal de geeks paranoïaques, crée un mot de passe différent pour chacun de ces comptes ?


votre avatar







John Shaft a écrit :



Me souviens a avoir à bouger mon mulot comme un neuneu dans tous les sens sur une image composée de point noir&blanc pour créer un truc pseudo-aléatoire.



A moins que ça ne soit pour le Master ?? <img data-src=" />







Le fait de bouger la souris sert à créer de l’enthropie, qui est la base pour le générateur de nombre aléatoires de l’OS.



En général, un OS fournit 2 manières d’obtenir un nombre aléatoire : la première permet d’obtenir un nombre pseudo-aléatoire, dont le caractère aléatoire n’est donc pas garanti. La deuxième permet d’obtenir un nombre vraiment aléatoire, mais peut bloquer jusqu’à ce que suffisamment d’enthropie soit récoltée, d’où le besoin de bouger la souris (les mouvements de souris sont considérés comme étant suffisamment imprévisibles pour être considérés comme aléatoires).



Généralement, des nombres aléatoires sont nécessaires pour créer une paire de clés publique/privée.



KeePass propose un fichier de verrouillage en plus du mot de passe, peut-être que c’est à ce moment qu’il a besoin d’enthropie, je n’ai pas étudié ce point.


votre avatar







Nathan1138 a écrit :



Sans déconner, qui, hormis un pourcentage marginal de geeks paranoïaques, crée un mot de passe différent pour chacun de ces comptes ?





C’est comme la backup : une fois que tu as tout perdu, tu changes sans doute de façon de voir les choses <img data-src=" />


votre avatar







Freud a écrit :



La clé n’est pas créée de manière pseudo-aléatoire (qu’est-ce que ça veut dire d’ailleurs ?) dans keepass, c’est simplement le hachage sha256 du master password qui est utilisée en tant que clé. C’est bien de l’AES-256 par contre.







Pseudo aléatoire c’est une suite qui tend à avoir un comportement aléatoire.

Mais vu que les données proviennent d’un algo, c’est pas totalement aléatoire.


votre avatar







BlackYeLL a écrit :



Et concernant l’outil en question, ce n’est pas un mot de passe, mais une passphrase que je connais par coeur, mais qui est à mon avis totalement impossible à devenir tellement elle est longue et complexe.





http://xkcd.com/936/


votre avatar







Freud a écrit :



KeePass propose un fichier de verrouillage en plus du mot de passe, peut-être que c’est à ce moment qu’il a besoin d’enthropie, je n’ai pas étudié ce point.







Ah oui, c’était pour ça <img data-src=" />



M’en vais rebouquiner du Knuth à Noël moi pour la peine <img data-src=" />


votre avatar







Spidard a écrit :



mh, je sais pas s’il faut forcément voir le mal partout.



Dans ma boite, lorsqu’un individu créé son compte, le mot de passe saisi est stocké en variable pour être envoyé dans l’email de bienvenue, mais la version stockée en BDD est bien le sha1 de cette variable.



L’envoyer en clair lors de l’inscription n’est dangereux qui si on se fait hacker sa boite mail sans avoir supprimé le mail.







Yangzebul l’a pourtant expliqué quelques commentaires plus haut : le transfert de mail n’est jamais sécurisé, il passe en clair sur le réseau, donc tous les intermédiaires pourraient sniffer le réseau et récupérer le mot de passe.



C’est donc une très mauvaise pratique. D’autant plus qu’à l’inscription, on demande toujours de saisir 2 fois le mot de passe : quelle est l’utilité de l’envoyer par mail à la personne qui l’a saisi 2 fois ?


votre avatar

Ah je vois que jeuxvideo.com renvoie le mot de passe tel quel avec l’option “mot de passé oublié”.. donc il doit être stocké en clair <img data-src=" />



Et un site hightech belge compumsa aussi… argh

votre avatar

LE probleme c’est que 80% des utilisateur non geek veulent retrouver leur MDP quand il clique sur “J’ai perdu mon mdp comme un con”, ce qui implique une maniere de le retrouver et pas uniquement stocker un md5.



Le probleme c’est plutot comment concilier les deux, genre une option a l’inscription “ je souhaite pouvoir retrouver mon mdp ou reset obligé”, qui implique ou non le stockage du mdp ou du hash.



biz



En tout cas pour l’instant, contrairement a ce que l’article semble faire croire mais LA MARJORITE des utlisateur DEMANDE ce comportement.

votre avatar







Droooom a écrit :



Ah je vois que jeuxvideo.com renvoie le mot de passe tel quel avec l’option “mot de passé oublié”.. donc il doit être stocké en clair <img data-src=" />



Et un site hightech belge compumsa aussi… argh







Un mot de passe renvoyé en clair peut être stocké chiffré avec un algorithme tel qu’AES par exemple.



Mais ça reste une mauvaise pratique, car le transit par mail est forcément en clair, sans parler du problème si la clé secrète est récupérée en même temps que la base de données par un attaquant.


votre avatar







David_L a écrit :



C’est comme la backup : une fois que tu as tout perdu, tu changes sans doute de façon de voir les choses <img data-src=" />





Sans doute.



Mais si tu écoutes les experts en sécurité, il faudrait avoir 50 mots de passe différents composés de 20 minuscules, majuscules, nombres et caractères spéciaux.



Prêts ? C’est parti : on commence par {Y3;qv3xV5 puis )iUL;e9g59 et ensuite K8(/qY2ck6 et après *UpXhf64#4…



Désolé, je suis pas R2D2.


votre avatar







dapro a écrit :



Le spécialiste de la vente de pièces auto OSCARO.

Mot de passe non chiffré et connection au compte en http.





ça c’est un fléau. la dernière fois que j’ai commandé la carte sncf 12-25 sur le site associé (qui n’est pas un site de la sncf, a préciser), la page de paiement n’était pas en https… <img data-src=" />


votre avatar







XalG a écrit :



Chiffrer un mot de passe c’est un comportement pas très net. J’ai pas vraiment envie de partager ce secret avec le site :/





Mais justement, lorsque tu t’inscris sur un site, tu ne sais absolument pas ce qu’il fait de tes données (ici, le mot de passe). Parfois, car un chef de projet a décidé qu’on devait pouvoir renvoyer le mot de passe à l’utilisateur, tu te retrouves à devoir implémenter ce genre de solution bancale entre “tout en clair” et “un minimum de sécurité” :-)


votre avatar







Freud a écrit :



Yangzebul l’a pourtant expliqué quelques commentaires plus haut : le transfert de mail n’est jamais sécurisé, il passe en clair sur le réseau, donc tous les intermédiaires pourraient sniffer le réseau et récupérer le mot de passe.





Oui c’est possible. Mais la sécurité parfaite n’existe pas. J’ai souvent tenté d’expliquer (surtout irl) qu’un site aura beau avoir la plus grosse sécu possible et inimaginable pour tes données perso, suffit que ta propre machine soit infectée (keylogger) pour que toute cette sécu tombe à l’eau.





Freud a écrit :



C’est donc une très mauvaise pratique. D’autant plus qu’à l’inscription, on demande toujours de saisir 2 fois le mot de passe : quelle est l’utilité de l’envoyer par mail à la personne qui l’a saisi 2 fois ?





Ca par contre je plussoie. Comme pour l’email. Quelle intérêt de le faire répéter ? je suis sur que la plupart des gens le copie-collent d’un champ à l’autre.


votre avatar

dsl doublon à nouveau

votre avatar







John Shaft a écrit :



Me souviens a avoir à bouger mon mulot comme un neuneu dans tous les sens sur une image composée de point noir&blanc pour créer un truc pseudo-aléatoire.



A moins que ça ne soit pour le Master ?? <img data-src=" />





Euh je test Keepass depuis une semaine et j’aimais eu à m’acharner sur le mulot pour générer quoique ce soit (m^rmr le Master)

Je pense que tu confonds avec un concurent (Keypass ? c’est un autre…)

Sinon parlant d’anthropie KeePass se débrouille pas mal.



D’ailleurs (pour ce que ça vaut) keepass à été certif par l’ANSSI : google.fr Google



votre avatar







Nathan1138 a écrit :



Sans doute.



Mais si tu écoutes les experts en sécurité, il faudrait avoir 50 mots de passe différents composés de 20 minuscules, majuscules, nombres et caractères spéciaux.



Prêts ? C’est parti : on commence par {Y3;qv3xV5 puis )iUL;e9g59 et ensuite K8(/qY2ck6 et après *UpXhf64#4…



Désolé, je suis pas R2D2.







Ce qu’on voit beaucoup dans des entreprises, et qui est pourtant une très mauvaise pratique, c’est l’obligation de changer de mot de passe régulièrement.



C’est très mauvais, car un bon mot de passe (disons au moins 12 caractères, avec minuscles/majuscules/chiffres/caractères spéciaux) stocké correctement (donc : pas en clair) ne pourra jamais être retrouvé par bruteforce en un temps correct (comprendre : plusieurs décennies, voire siècles). Donc il n’y a aucune raison de changer un tel mot de passe.



En revanche, obliger les gens à changer de mot de passe fait qu’ils choisissent des mots de passe faciles à retenir, et donc faciles à cracker.



La bonne solution : forcer un mot de passe complexe, mais laisser les gens le garder indéfiniment (ou du moins, tant que l’algo de stockage est sûr).


votre avatar







tsyr2ko a écrit :



Mais justement, lorsque tu t’inscris sur un site, tu ne sais absolument pas ce qu’il fait de tes données (ici, le mot de passe). Parfois, car un chef de projet a décidé qu’on devait pouvoir renvoyer le mot de passe à l’utilisateur, tu te retrouves à devoir implémenter ce genre de solution bancale entre “tout en clair” et “un minimum de sécurité” :-)







C’est ce genre d’informations qu’on devrait pouvoir obtenir à l’inscription, avec des logos :

certifié hashé,

certifié chiffré,

certifié tu vas te faire volé !


votre avatar







Spidard a écrit :



ça c’est un fléau. la dernière fois que j’ai commandé la carte sncf 12-25 sur le site associé (qui n’est pas un site de la sncf, a préciser), la page de paiement n’était pas en https… <img data-src=" />







Souvent, les sites utilisent un prestataire de paiement externe, qu’ils collent dans une iframe.



Le site est donc en HTTP, mais l’iframe est bien en HTTPS.

Si ce n’est pas le cas, c’est effectivement très grave<img data-src=" />


votre avatar







tsyr2ko a écrit :



Parfois, car un chef de projet a décidé qu’on devait pouvoir renvoyer le mot de passe à l’utilisateur, tu te retrouves à devoir implémenter ce genre de solution bancale entre “tout en clair” et “un minimum de sécurité” :-)









Tellement vrai je ne compte plus le nombre de dizaines d’heures que j’ai passé à m’engueuler avec des chefs de projets pas très doués qui exigeaient ça, alors qu’en parallèle le client payait plusieurs milliers d’euros en certificats SSL… <img data-src=" />



Malheureusement le nombre de fois où j’ai réussi à obtenir gain de cause est assez faible…


votre avatar







Freud a écrit :



La bonne solution





La bonne solution, ce serait de trouver une alternative au mot de passe.



Non, je n’ai pas de solution miracle, mais en même temps, chacun son taf <img data-src=" />


votre avatar







DakoR a écrit :



SHA-1 est un algo de hashage donc théoriquement non réversible. Par contre les possibilités de trouver des collisions sont plutôt grande, donc préférez dans tous les cas SHA-256 +salt (et encore vu les bases à dispo maintenant ce n’est pas non plus infaillible)





Assez d’accord mais les recommandations pour stocker des mots de passe sont plutot :




  • ajouter un sel personnalisé (pour éviter les attaques par dictionnaire)

  • faire un certain nombre de fois (plus de 1000 par exemple) le hash (SHA-256 effectivement car on commence à découvrir des problèmes dans SHA-1) pour faire exploser en temps de calcul chez l’attaquant en brute force.


votre avatar



C’est d’ailleurs pour cela que le stockage des mots de passe via SHA-1 est le plus souvent recommandé





Le SHA-1 n’est pas recommandé, faut aller sur des algorithmes beaucoup plus lents.



Quelques infos très intéressantes dans cet article :arstechnica.com Ars Technica



Et chez PCinpact, vous utilisez SHA-1 pour nos mots de passe ? <img data-src=" />

votre avatar

Et vos solutions à base de KeePass ou autre logiciel. Ça se passe comment le jour où votre ordinateur est perdu / volé / mort ?



Vous faites comment pour récupérer les mdp ? Ils sont stockés ailleurs que sur le PC ? Parce que sinon c’est la catastrophe quoi… Et ça en devient pas très intéressant pour le coup <img data-src=" />

votre avatar







Nathan1138 a écrit :



La bonne solution, ce serait de trouver une alternative au mot de passe.



Non, je n’ai pas de solution miracle, mais en même temps, chacun son taf <img data-src=" />





Une alternative ? Double authentification avec biométrie+token d’identification (clef USB, carte à puce, téléphone portable). Comme ça il faut te couper le bras et voler ton téléphone ! <img data-src=" />


votre avatar







Spidard a écrit :



Ca par contre je plussoie. Comme pour l’email. Quelle intérêt de le faire répéter ? je suis sur que la plupart des gens le copie-collent d’un champ à l’autre.





Une petite mauvaise expérience : je souhaite acheter quelques jeux sur GOG.com pour la première fois. Je me trompe dans mon mail (j’ai confondu avec le mail du boulot) et rentre un mail valide mais ne m’appartenant pas. Du coup un type a reçu mon mail de commande avec le lien vers mes jeux, et je suppose le mail de confirmation d’inscription. Heureusement j’ai pu rapidement modifier mon mail dans mon compte, n’ayant pas quitté ma session. Comment j’aurais fait si j’avais quitté la session en ne me souvenant plus du vrai-faux mail que j’ai tapé ? Je me serais retrouvé avec quelques euros de moins et sans aucun jeu.


votre avatar







Drako99 a écrit :



Le SHA-1 n’est pas recommandé, faut aller sur des algorithmes beaucoup plus lents.



Quelques infos très intéressantes dans cet article :arstechnica.com Ars Technica



Et chez PCinpact, vous utilisez SHA-1 pour nos mots de passe ? <img data-src=" />







cf mon commentaire #21



Chez PCinpact, il n’y a pas de HTTPS, donc les mots de passe transitent en clair pour commencer…



Sans compter les cookies de session.



Donc pour PCinpact : <img data-src=" /> on veut du HTTPS ! C’est bien beau de donner des leçons aux autres, commencez par balayer devant votre porte !


votre avatar

En fait, c’est plus compliqué.



1/ un site internet peut très bien (hashé avec sel ou crypté) le stockage du mot de passe et envoyer un mail avec les données issus du formulaire d’inscription, sans pour autant ne pas respecter la sécurité des mots de passe.



2/ un site peut stocker les mots de passe en clair et vous le renvoyer tel quel lors d’une procédure de mot de passe oublié.



3/ un site peut stocker les mots de passe de façon CRYPTÉE dans la base de donnée et vous le renvoyer la version décryptée lors d’une procédure de mot de passe oublié. (si un pirate accède à la BDD seule, il n’aura pas les mots de passe en clair et devra en plus de ça, accéder au source du site (sauf si le cryptage est fait par une procédure stockée, ce qui serait stupide en matière de sécurité).



4/ un site peut stocker les mots de passe de façon HASHÉE avec (ou sans) sel et aura deux comportements possibles : soit il vous renvoie un mot de passe aléatoire, voire temporaire en vous incitant à le changer lors de la prochaine connexion; soit carrément de vous faire venir sur le site via une URL prédéterminée pour que vous rentriez votre nouveau mot de passe.



Mais la conclusion est qu’on ne peut déterminer, en tant qu’utilisateur du service, si le stockage du mot de passe est faite de manière sécurisée ou pas.



Un autre problème, à mon sens, est que lors du renvoi de mot de passe par mail, qu’il soit crypté ou non en BDD, le mail, lui, transite en clair sur le réseau, et il me semble que c’est là le propos de David.



;-)

votre avatar







tsyr2ko a écrit :



Un autre problème, à mon sens, est que lors du renvoi de mot de passe par mail, qu’il soit crypté ou non en BDD, le mail, lui, transite en clair sur le réseau, et il me semble que c’est là le propos de David.



;-)





Voila, et qu’il faudrait mettre fin aux mots de passe, aux mails, et à la vie de certains développeurs <img data-src=" />


votre avatar







La news a écrit :



“Outre le fait d’utiliser des mots de passe complexes et différents pour chaque services, et des outils tels que KeePass par exemple”







Je trouve idiot/dangereux de stocker tous ses mots de passe dans un seul outil.


votre avatar







winch a écrit :



En partie faux…



Je m’explique :



Recevoir le mot de passe en clair à l’inscription ne prouve pas que le service stocke les mots de passe en clair, car au moment de l’inscription il ne lit pas le mot de passe à partir de la base de donnée mais à partir du formulaire d’inscription, où le mot de passe est en clair (puisque rentré à la main par le nouvel utilisateur)





La vraie preuve est lors d’une procédure “mot de passe oublié” : si vous recevez votre mot de passe en clair à ce moment là alors il y a un problème de sécurité.



Sur mon site certaines personnes flippent car mal informées, et ce n’est pas cet article qui va rassurer. Merci de corriger :)





Je trouve ça risqué d’envoyer le mot de passe par mail (même s’il n’est pas stocké en clair de l’autre côté). Un mail ça s’intercepte, ça se balade en clair, tu n’es pas sûr que la personne ne va pas le garder dans sa boite mail (grosse grosse erreur de sa part, mais c’est tellement courant). Le nombre de mail que tu retrouves avec le mot de passe dedans. Quand je vois que des collègues utilisent en plus la boite mail du boulot pour s’inscrire sur des sites. J’espère pour eux que le sysadmin n’est pas “from hell”. (Cf. BOFH)



Moi un truc qui me choque encore plus c’est des sites qui te mettent un lien dans un mail, et en fait ce lien t’identifie, tu n’as pas besoin de taper ton mot de passe pour te connecter, tu as juste à cliquer sur le lien et tu as un accès complet au compte.


votre avatar







David_L a écrit :



Et donc le mot de passe, il est tiré du papa noël ?







Ben non, du formulaire que l’utilisateur à envoyé ^^



Mais sinon, on est d’accord qu’il est totalement aberrant d’envoyer le mot de passe par email :/


votre avatar

Mot de passe hashié c’est imparable <img data-src=" />

votre avatar

Mouais…



Un article pour pas grand chose, quoi, un peu comme à chaque fois que David se met à un truc (on a eu les extensions chrome, les petits programmes en C#, et maintenant la sécurité des mots de passe…).



Et du coup on y voit plein d’inexactitudes, qui contribuent malheureusement à répandre des idées reçues :

-Il n’y a pas d’attaque de préimage sur le MD5. Plus clairement, ça signifie que pour retrouver une préimage (donc un mot de passe dans notre cas) à partir d’un hash MD5, la seule méthode reste encore le brute force (et je vous vois venir, les rainbow tables c’est du bruteforce).

-Le MD5 est vulnérable seulement à des attaques de collision, ce qui n’a rien à voir avec les attaques de préimage, et ne peut absolument pas être utilisé pour retrouver un mot de passe à partir d’un hash.

-SHA1 et MD5 sont donc aussi sûrs l’un que l’autre pour stocker un mot de passe, à la vitesse du bruteforce près. Attention, “aussi sûrs” ne veut pas dire qu’ils sont très sûrs :)



J’en viens donc au point le plus important :

Si l’on stocke directement le hash du mot de passe, MD5 et SHA1 sont aussi mauvais l’un que l’autre. Ils sont facilement bruteforçables (plusieurs centaines de millions, voire plusieurs milliards de hachages par seconde sur une machine moderne), sans parler des rainbow tables.



Donc, le minimum aujourd’hui, c’est sha1/md5 de mot de passe avec salt.



Le mieux, bon rapport perf/sécurité, c’est sha256 de mot de passe avec salt ou double salt.



Le top du top, c’est bcrypt, mais c’est très lent (mais c’est le but en même temps).

votre avatar







fwak a écrit :



Je trouve idiot/dangereux de stocker tous ses mots de passe dans un seul outil.





C’est toujours mieux que les bouts de papier, ou le mot de passe unique. Surtout que pour le coup, l’ensemble peut être chiffré et protégé de manière assez complète.



Mais il n’y a pas de solution parfaite, et le mot de passe seul n’en est pas une de toutes façons. <img data-src=" />


votre avatar

Cet article m’aura au moins fait faire quelque chose que j’aurais dû faire depuis longtemps : une recherche dans mes mails sur les mots de passe que j’utilise fréquemment.



30 résultats… <img data-src=" /><img data-src=" />

votre avatar







fwak a écrit :



Je trouve idiot/dangereux de stocker tous ses mots de passe dans un seul outil.







Moi non.



L’outil que j’utilise génère et stocke un mot de passe différent pour chaque site. Chaque mot de passe fait plus de 32 caractères, de tout type (majuscules, minuscules, chiffres, caractères spéciaux …).



Donc impossible de deviner le mot de passe d’un site… et même si ça devait arriver, il ne pourrait être utilisé nulle part.



Et concernant l’outil en question, ce n’est pas un mot de passe, mais une passphrase que je connais par coeur, mais qui est à mon avis totalement impossible à devenir tellement elle est longue et complexe.


votre avatar







fwak a écrit :



Je trouve idiot/dangereux de stocker tous ses mots de passe dans un seul outil.







KeePass, c’est pas du coffre de lopette : c’est de l’AES-256 avec une clé créée de manière pseudo aléatoire, donc c’est sûr tant qu’on a pas d’ordinateur quantique (ou que les matheux trouve un angle d’attaque qui ne nécessite pas 2^100 opérations) <img data-src=" />


votre avatar







Jean_Peuplus a écrit :



Je vais toaster ça ce WE.





Magnifique petit logiciel, qui permet de gérer ces MDP dans un coffre fort (BD sécurisée et chiffrée) , qui contient un générateur de mots de passe çà partir de regex, permet une saisie automatique avec canaux d’obscurcissement ( saisie pass par simulation clavier et par presse papier afin de contrer les keyloggers et consort)

Extrêment secure, protège le presse papier, protège son utilisation mémoire et tout ça en opensource….


votre avatar







David_L a écrit :



J’avais rajouté une précision pour que ce soit plus clair à ce niveau, mais il n’y a que moi qui trouve dingue l’idée d’envoyer un mot de passe en clair non temporaire par mail, pour quelque raison que ce soit ? Le formulaire est SSL j’espère ? <img data-src=" />



PS : merci d’éviter d’en profiter pour faire de l’auto-promo ;)







Non tu n’es pas le seul, c’est totalement inutile de faire un salage + SHA-256 des familles si au moment de l’inscription, tu fais transiter le mot de passe en clair :/



J’ai récemment envoyé un jolie mèl pour engueuler ma boite qui venait de me renvoyer mon mot de passe en clair.



Il devrait y avoir sur les sites un logo : CERTIFIED SHA


votre avatar







snoopy1492 a écrit :



Toujours est-il que perso je pense qu’un mot de passe ne devrait dans aucun cas être marqué en clair dans un quelconque email, même d’inscription.

SI quelqu’un accède à la boite mail de la personne, il lui suffirait alors d”un petit tour dans les emails pour accéder aux infos.

C’est un peu comme marquer le code de sa carte bleue dans son agenda, c’est tenter le diable <img data-src=" />











DakoR a écrit :



même si cela ne passe pas par la BDD, il n’y a, à mon avis, rien de moins sûr qu’un mail. Aucune garantie de transfert sécurisé et de toute manière et ça crée aussi un endroit (la BAL utilisateur) où le password est stocké en clair. Donc à bannir aussi.









Vous vous trompez tout les deux, le problème de sécurité dans ce cas de figure n’est pas que le mot de passe soit stocké en clair dans le mail de l’user, mais que le mot de passe est vulnérable PENDANT le transfert de cet email.



Le problème est uniquement dans le transfert, une fois que le mail est arrivé à destination alors c’est parfaitement sécurisé.



Peu importe que le mot de passe dans la BAL de l’utilisateur soit stocké en clair ou crypté avec un algorithme secret des mayas totalement indéchiffrable même avec toute la puissance de calcul de trois fois l’univers… La sécurité est égal au maillon le plus faible de la chaîne, donc si l’attaquant à accès à ta BAL tu es cuit peu importe comment tu stocke, l’attaquant peut juste utiliser la procédure de mot de passe oublié.



CQFD


votre avatar







John Shaft a écrit :



KeePass, c’est pas du coffre de lopette : c’est de l’AES-256 avec une clé créée de manière pseudo aléatoire, donc c’est sûr tant qu’on a pas d’ordinateur quantique (ou que les matheux trouve un angle d’attaque qui ne nécessite pas 2^100 opérations) <img data-src=" />







La clé n’est pas créée de manière pseudo-aléatoire (qu’est-ce que ça veut dire d’ailleurs ?) dans keepass, c’est simplement le hachage sha256 du master password qui est utilisée en tant que clé. C’est bien de l’AES-256 par contre.


votre avatar







cosmocat a écrit :





  • faire un certain nombre de fois (plus de 1000 par exemple) le hash (SHA-256 effectivement car on commence à découvrir des problèmes dans SHA-1) pour faire exploser en temps de calcul chez l’attaquant en brute force.





    A ne pas faire sauf à ajouter du sel à chaque fois.



    Les algo de hash sont “sûrs” en tant que tel. Hasher un hash réduit la sécurité de l’algo.


votre avatar







Freud a écrit :



KeePass est open source. Le fichier de mots de passe est en format XML.



Tu peux toi-même coder ton utilitaire pour ouvrir ce fichier : c’est de l’AES-256, la clé est le sha256 du mot de passe.



KeePass tourne sous tout os. Dropbox est un exemple, on peut utiliser n’importe quel service de stockage en ligne, même un truc complètement public, vu que tout est chiffré.







Je viens de tester, et c’est tout sauf du XML en fait <img data-src=" />

C’est un format binaire…







Nathan1138 a écrit :



Au-delà de ces problèmes, c’est surtout le côté pas pratique qui est problématique.



J’ai utilisé Keepass quelques mois. Et franchement, dans un monde où tu passes ta vie à rentrer des mots de passe, c’est carrément casse-couilles, à chaque fois qu’on t’en demande un, de lancer Keepass, de retrouver le service, de copier le mot de passe, de le coller, etc…







Un service qui tourne en fond et sait intelligemment remplir automatiquement les mots de passe en fonction des url serait un bon progrès. Après ça ne marche que pour le web ça.


votre avatar







P-A a écrit :



On ne donne de leçon à personne, et comme je l’ai dit moulte et moulte fois, le https arrivera avant la fin de l’année ;)







Malin comme deadline !

Avec la fin du monde qui arrive avant. <img data-src=" />













… ou pas.


votre avatar



le stockage d’une empreinte du mot de passe au sein d’une base de données semble tenir du bon sens pour n’importe quel développeur ayant déjà produit plus de dix lignes de code dans sa vie





Ça casse sec.

votre avatar







Weig a écrit :



Je viens de tester, et c’est tout sauf du XML en fait <img data-src=" />

C’est un format binaire…







Oui, j’ai dit une connerie :)



C’est l’export en XML qui est une feature, mais effectivement le format est binaire.


votre avatar







Khalev a écrit :



Les algo de hash sont “sûrs” en tant que tel. Hasher un hash réduit la sécurité de l’algo.







Ou utiliser un algo de hash très lent et prévu pour :

en.wikipedia.org Wikipediacode.google.com GoogleLe nombre d’itérations fait partie de l’algo. J’ai essayé cet algo avec 5000 itérations, sur un mobile d’il y a 3 ans, il y en a pour quelques secondes.


votre avatar







Antwan a écrit :



Ça casse sec.







Ça casse et pourtant la news est pleine d’inexactitudes et de contre-vérités, cf mon commentaire #21.


votre avatar







Drako99 a écrit :



Ou utiliser un algo de hash très lent et prévu pour :

en.wikipedia.org Wikipediacode.google.com GoogleLe nombre d’itérations fait partie de l’algo. J’ai essayé cet algo avec 5000 itérations, sur un mobile d’il y a 3 ans, il y en a pour quelques secondes.





Oui, mais comme tu dis c’est prévu dans l’algo, il n’y a que BB pour n’utiliser qu’une itération… ou pas (hélas).



En revanche sur md5 par exemple il y a des raisons pour lesquelles on fait exactement 16 itérations et pas 15 ni 17. Le passer plusieurs fois affaibli grandement son efficacité (je crois que c’est un des pire pour ça en fait).


votre avatar

Qu’est ce qu’on voit pas passer comme conneries sur PC INpact en se moment!











tsyr2ko a écrit :



Un autre problème, à mon sens, est que lors du renvoi de mot de passe par mail, qu’il soit crypté ou non en BDD, le mail, lui, transite en clair sur le réseau





Les transferts de mail sont chiffrés… enfin normalement. Le problème c’est qu’on ne sait pas si tout les transferts entre les MTA ont eu lieu de façon chiffré. Vous ne pouvez être sur que du transfert entre les 2 derniers MTA… càd entre celui de votre client de messagerie ou browser (la taxonomie est pas exacte du coup mais on s’en fout) et le serveur de votre fournisseur de service.







Freud a écrit :



Et du coup on y voit plein d’inexactitudes, qui contribuent malheureusement à répandre des idées reçues :

-Il n’y a pas d’attaque de préimage sur le MD5. Plus clairement, ça signifie que pour retrouver une préimage (donc un mot de passe dans notre cas) à partir d’un hash MD5, la seule méthode reste encore le brute force (et je vous vois venir, les rainbow tables c’est du bruteforce).

-Le MD5 est vulnérable seulement à des attaques de collision, ce qui n’a rien à voir avec les attaques de préimage, et ne peut absolument pas être utilisé pour retrouver un mot de passe à partir d’un hash.

-SHA1 et MD5 sont donc aussi sûrs l’un que l’autre pour stocker un mot de passe, à la vitesse du bruteforce près. Attention, “aussi sûrs” ne veut pas dire qu’ils sont très sûrs :)





On peut retrouver la préimage à partir du hash si tu retire ta blouse de scientifique frigide… c’est juste qu’on peut pas le prouver. Si tu trouves une collision qui donne “jesuistropbelle” il y a beaucoup de chances que tu ai trouvé la bonne pré-image. Et encore plus si les contraintes sur la préimage imposé par le site et supérieur aux contraintes imposée par le codage du charset. (en traduit ça donne: “si ta collision a un tiret et que le site t’envoi péter quand tu mets un tiret dans ton pass alors c’est pas la préimage”)



Une rainbow table c’est pas du bruteforce. Où alors je savais pas que le bruteforce pouvait avoir une complexité logarithmique



Bon… une collision pour un site A fonctionne très bien sur un site B s’ils utilisent la même implémentation. Si la victime utilise le même passe partout alors il existe une chance pour l’exploit soit exploitable ailleurs.

On n’a pas la préimage mais tu vois qu’on s’en fout. CQFD



C’est pour cette raison qu’on salle les pass avant hashage. Si on trouve une collision sur un hash pré-salé alors il y a autant de chance de trouver un site où l’exploit soit utilisable ailleurs que de trouver le passe en claire çad aucune.



Alors on pourrait se dire “ben suffit de hasher-saller!”. Ben non. Dans sa connerie @Freud est quand même au-dessus du niveau “pillier comptoir” dont vous êtes les stéréotype (@David_L t’en fait partie). Quand il dit “SHA1 et MD5 sont donc aussi sûrs l’un que l’autre pour stocker un mot de passe, il a tout à fait raison, puisqu’il parle de la préimage! On fait des milliers de hash SHA512 en une toute petite seconde. ça va pas ralentir de beaucoup une attaque par bruteforce. On en fait



Un hash n’est pas suffisant : il faut chiffrer (oué toi là bas en page 2 ou 3, tu dis du caca de taureau quand tu te fous de la gueule d’un autre qui a dit crypté) Faut chiffrer… mais pas avec une opérations réversible. Le hash c’est quand on passe une fois à la moulinette. Quand vous sallé puis que vous hashez 5000x votre préimage, là vous avez chiffré.



Retournez boire votre mousse (ou rédigez des articles creux avec du placement de produits à tire larigots) et mettez vous dans la tête que la crypto c’est pas votre truc et que vous z’y pipez rien. Moi, je retourne juste boire ma mousse ; je sais déjà que la crypto j’y pipe rien.


votre avatar

Idée : L’utilisateur s’inscrit sur le site en fournissant : login + mdp + clef-publique



Comme ça le service peut enregistrer le mdp chiffré avec la clef publique.



Quand il le renvoie à l’utilisateur, il n’est “en clair” que pour le destinataire détenteur de la clef privée.





Faut jute pas perdre sa clef privée, mais çà c’est un minimum !

votre avatar

Sans parler des problèmes de stockage cryptés ou non du mdp:







  1. Demander à l’utilisteur son numéro de tel mobile et sa date de naissance obligatoire à l’inscription

  2. Envoyer un mot de passe temporaire par SMS

  3. A la premiere connexion demander à l’utilisateur de rentrer son mot de passe temporaire et dans la foulée de saisir le mot de passe pérenne puis de crééer question et réponse secrete.



    Si l’utilisateur perd son mdp on lui demandera sa date de naissance , la réponse à sa question secrete et on lui envoie un code temporaire puis retour à 3.



    Il n’y a qu’en croisant les canaux de communication qu’on rend l’authetification sécurisée. Inconvénient : tout le monde n’est pas pret à donner son numéro de tel ni sa vraie date de naissance. Le souscripteur peut aussi changer de nyuméro de mobile entre temps. Il faut donc un service hotline avec un vrai être humain capable de lui communiquer son numéro temporaire.

votre avatar

Y’en a qui ont hashé leur agressivité en sha512.

votre avatar







Weig a écrit :



Un service qui tourne en fond et sait intelligemment remplir automatiquement les mots de passe en fonction des url serait un bon progrès. Après ça ne marche que pour le web ça.





Le service peut tourner en tâche de fond, même pour ça version portable, il permet le remplissage automatique (par raccourci clavier), la gestion de macro (donc pas uniquement pour le web), le double obscurcissement (presse papier + auto-key).



Je l’utilise sur tout mais “service” web, le ssh, Winscp, pas mal de launcher exotique de jeu, Uplay (pas le choix), Steam, Origin (pas le choix non plus). On peu même le lieu à un compte local Windows, une session Active Directory ou LDAP (attention par compte il faut backup le compte dans ça globaliter car sinon tout est perdu)

Il est dispo sur toutes les plateforme, il existe un plugin firefox, et des appli WP, IOs et Androïd.

J’ai parfois utilisé un mot de passe “unique” (enfin plutôt un nomenclature que j’essayais de faire varier avant) mais depuis que j’ai Keepas aucune galère. En plus j’ai maintenant uniquement des mots de passe long (+de 12 caractères, même 20 en général) avec toute les combinaisons possible et adaptable à une politique sécu d’une appli ou d’un site web.

Ne pas l’utiliser (ou un autre) est un choix (chacun fait ce qu’il veut, mais tant pis pour lui face au conséquence), mais dire que Keepass, c’est trop compliqué, j’appellerais plutôt ça de la fainéantise.


votre avatar







lildadou a écrit :



Qu’est ce qu’on voit pas passer comme conneries sur PC INpact en se moment!







Tu en es le parfait exemple :)





On peut retrouver la préimage à partir du hash si tu retire ta blouse de scientifique frigide… c’est juste qu’on peut pas le prouver. Si tu trouves une collision qui donne “jesuistropbelle” il y a beaucoup de chances que tu ai trouvé la bonne pré-image. Et encore plus si les contraintes sur la préimage imposé par le site et supérieur aux contraintes imposée par le codage du charset. (en traduit ça donne: “si ta collision a un tiret et que le site t’envoi péter quand tu mets un tiret dans ton pass alors c’est pas la préimage”)





Sais-tu seulement la différence entre une attaque de préimage et une attaque de collision ? De toute évidence non. MD5 est encore résistant aux attaques de préimage. Pas vraiment aux collisions. Mais une attaque de collision implique que tu as un minimum de contrôle sur les deux messages d’origine, ce qui n’est pas le cas quand tu cherches à retrouver un message donnant un certain hash.





Une rainbow table c’est pas du bruteforce. Où alors je savais pas que le bruteforce pouvait avoir une complexité logarithmique





Et la rainbow table, elle a été créée comment ? Par magie ? Créer une rainbow table, c’est calculer des milliards de milliards de hashs, retirer les “intermédiaires”. L’utiliser pour trouver un mot de passe, c’est espérer que le mot de passe en questions faisait partie de ceux caculés lors de la création de la table. La base de la rainbow table reste du brute force, l’utiliser c’est un bruteforce “indirect” si je puis dire.





Bon… une collision pour un site A fonctionne très bien sur un site B s’ils utilisent la même implémentation. Si la victime utilise le même passe partout alors il existe une chance pour l’exploit soit exploitable ailleurs.

On n’a pas la préimage mais tu vois qu’on s’en fout. CQFD





Je ne vois pas le rapport avec le reste, mais bon.





C’est pour cette raison qu’on salle les pass avant hashage. Si on trouve une collision sur un hash pré-salé alors il y a autant de chance de trouver un site où l’exploit soit utilisable ailleurs que de trouver le passe en claire çad aucune.



Alors on pourrait se dire “ben suffit de hasher-saller!”. Ben non. Dans sa connerie @Freud est quand même au-dessus du niveau “pillier comptoir” dont vous êtes les stéréotype (@David_L t’en fait partie). Quand il dit “SHA1 et MD5 sont donc aussi sûrs l’un que l’autre pour stocker un mot de passe, il a tout à fait raison, puisqu’il parle de la préimage! On fait des milliers de hash SHA512 en une toute petite seconde. ça va pas ralentir de beaucoup une attaque par bruteforce. On en fait





Là j’ai vraiment du mal à te suivre, tes phrases deviennent incompréhensibles.





Un hash n’est pas suffisant : il faut chiffrer (oué toi là bas en page 2 ou 3, tu dis du caca de taureau quand tu te fous de la gueule d’un autre qui a dit crypté) Faut chiffrer… mais pas avec une opérations réversible. Le hash c’est quand on passe une fois à la moulinette. Quand vous sallé puis que vous hashez 5000x votre préimage, là vous avez chiffré.



Retournez boire votre mousse (ou rédigez des articles creux avec du placement de produits à tire larigots) et mettez vous dans la tête que la crypto c’est pas votre truc et que vous z’y pipez rien. Moi, je retourne juste boire ma mousse ; je sais déjà que la crypto j’y pipe rien.





En fait tes propos sont totalement incompréhensibles, sauf le début, qui n’est qu’un tissu de conneries.



Heureusement, tu nous expliques pourquoi : tu es bourré. <img data-src=" />


votre avatar







ren33 a écrit :





  1. Demander à l’utilisteur son numéro de tel mobile et sa date de naissance obligatoire à l’inscription



    1. Envoyer un mot de passe temporaire par SMS

    2. A la premiere connexion demander à l’utilisateur de rentrer son mot de passe temporaire et dans la foulée de saisir le mot de passe pérenne puis de crééer question et réponse secrete.



      Si l’utilisateur perd son mdp on lui demandera sa date de naissance , la réponse à sa question secrete et on lui envoie un code temporaire puis retour à 3.



      Il n’y a qu’en croisant les canaux de communication qu’on rend l’authetification sécurisée. Inconvénient : tout le monde n’est pas pret à donner son numéro de tel ni sa vraie date de naissance. Le souscripteur peut aussi changer de nyuméro de mobile entre temps. Il faut donc un service hotline avec un vrai être humain capable de lui communiquer son numéro temporaire.







      Les questions et réponses secrètes sont des failles énormes : un peu de “social engineering” et on connaît la réponse.

      Je hais les sites qui imposent cette méthode.



      Quand à l’humain qui donne un mot de passe temporaire, comment fait-il pour savoir que c’est la bonne personne qui l’appelle et qu’il faut l’autoriser à accéder au compte ?



votre avatar



puisque de la comparer à



<img data-src=" />

votre avatar







fochristo a écrit :



Et vos solutions à base de KeePass ou autre logiciel. Ça se passe comment le jour où votre ordinateur est perdu / volé / mort ?



Vous faites comment pour récupérer les mdp ? Ils sont stockés ailleurs que sur le PC ? Parce que sinon c’est la catastrophe quoi… Et ça en devient pas très intéressant pour le coup <img data-src=" />





ça tombe bien je me demandais la même chose <img data-src=" />


votre avatar







fochristo a écrit :



Et vos solutions à base de KeePass ou autre logiciel. Ça se passe comment le jour où votre ordinateur est perdu / volé / mort ?



Vous faites comment pour récupérer les mdp ? Ils sont stockés ailleurs que sur le PC ? Parce que sinon c’est la catastrophe quoi… Et ça en devient pas très intéressant pour le coup <img data-src=" />







Une pratique courante est de stocker le fichier contenant tous les mots de passe sur Dropbox.



Ce fichier est chiffré avec la clé AES-256 dérivé du master password, donc aucun problème<img data-src=" />



Ça permet en plus d’avoir tous les mots de passe à jour sur tous les PC/smartphone & co.


votre avatar







Freud a écrit :



cf mon commentaire #21



Chez PCinpact, il n’y a pas de HTTPS, donc les mots de passe transitent en clair pour commencer…



Sans compter les cookies de session.



Donc pour PCinpact : <img data-src=" /> on veut du HTTPS ! C’est bien beau de donner des leçons aux autres, commencez par balayer devant votre porte !







On ne donne de leçon à personne, et comme je l’ai dit moulte et moulte fois, le https arrivera avant la fin de l’année ;)


votre avatar







P-A a écrit :



On ne donne de leçon à personne, et comme je l’ai dit moulte et moulte fois, le https arrivera avant la fin de l’année ;)





Eh ben en voilà une bonne nouvelle<img data-src=" />


votre avatar







Freud a écrit :



Chez PCinpact, il n’y a pas de HTTPS, donc les mots de passe transitent en clair pour commencer…



Sans compter les cookies de session.







Tout à fait



J’utilise un mot de passe unique pour PCinpact, c’est bon <img data-src=" />


votre avatar

Donc la solution c’est d’avoir 50 mdp sur le web, ceux-ci n’étant pas ou mal cryptés on les protège tous avec un seul, beaucoup mieux crypté, mais dans un fichier qui se balade…



Je vois le principe et je comprends bien l’utilité. De là à dire que c’est la solution ultime … Peut être la “moins pire” alors…

votre avatar







fochristo a écrit :



Je vois le principe et je comprends bien l’utilité. De là à dire que c’est la solution ultime … Peut être la “moins pire” alors…





J’en arrive à cette conclusion également. J’ai commencé à coder une webapp HTML5 avec stockage offline pour faire ça.



C’est hyper moche, il manque de la synchro sur un truc style Dropbox, mais ça m’a l’air solide niveau crypto :http://matthieu.no-ip.org/passwordDB/


votre avatar







David_L a écrit :



C’est toujours mieux que les bouts de papier, ou le mot de passe unique. Surtout que pour le coup, l’ensemble peut être chiffré et protégé de manière assez complète.



Mais il n’y a pas de solution parfaite, et le mot de passe seul n’en est pas une de toutes façons. <img data-src=" />







Mot de passe unique et passphrase unique, je ne vois pas bien la différence, en fait. Et j’ignore si après x tentatives erronées, Keepass s’autodétruit.


votre avatar







FrenchPig a écrit :



ça tombe bien je me demandais la même chose <img data-src=" />





Bah chaque site a bien un procédure de récupération de mot de passe, non?



Oui c’est lourd il faut le faire pour tous, mais tu ne te fais pas voler ton PC tous les jours non plus.


votre avatar







Khalev a écrit :



Bah chaque site a bien un procédure de récupération de mot de passe, non?



Oui c’est lourd il faut le faire pour tous, mais tu ne te fais pas voler ton PC tous les jours non plus.







Et tu peux avoir une copie du fichier ailleurs comme ça a été dit. (clé USB attachée au bureau, stockage en ligne,…)


votre avatar



N’hésitez donc pas à vous en plaindre auprès du service client lorsque vous constatez que c’est le cas, et à nous indiquer au sein de nos commentaires ceux que vous avez pu repérer vous-même.





Voici une petite liste de sites de recherche d’emploi avec des problèmes de sécurité de mot de passe. J’ai fait ce travail en juillet pour voir là où il fallait que je mette des mots de passes uniques et je viens de vérifier que c’est encore le cas.



cadremploi :

login en http et pas https

mot de passe stocké en clair ou de façon réversible : visible dans le source de page “Gestion de mon Espace Perso ” même si apparaît avec des =&gt; faux sentiment de sécurité.

cadresonline :

exactement les mêmes problèmes



(Ces 2 sites sont du même groupe ainsi que le suivant : Le Figaro)



keljob :

login en http et pas https



APEC :

login en http et pas https

mot de passe stocké en clair ou de façon réversible : visible en clair sur page “Modifier votre compte Apec”. Au moins, on sait qu’il y a un risque !



J’avais alerté en insistant le site sur ce problème en juillet. J’avais même reçu une réponse du DSI m’expliquant qu’ils avaient en perspective de corriger sous peu cette faille. C’est toujours pareil aujourd’hui. On ne doit pas avoir la même idée du “sous peu”…



RegionsJob :

login en http et pas https



jobtic :

login en http et pas https



J’arrête là, mais il y avait aussi le problème sur des sites emploi de pas mal de SSII ou autres sociétés où j’ai des comptes.

votre avatar

Et comment ça se passe au niveau portabilité ?

Ça veut dire qu’il faut que l’application (ici KeePass) tourne sur tout OS (PC, smartphone, tablettes etc) et que le logiciel de partage de fichier aussi. (ici DropBox)



Ce n’est pas une situation très pérenne je trouve…

votre avatar







Weig a écrit :



Et comment ça se passe au niveau portabilité ?

Ça veut dire qu’il faut que l’application (ici KeePass) tourne sur tout OS (PC, smartphone, tablettes etc) et que le logiciel de partage de fichier aussi. (ici DropBox)



Ce n’est pas une situation très pérenne je trouve…







KeePass est open source. Le fichier de mots de passe est en format XML.



Tu peux toi-même coder ton utilitaire pour ouvrir ce fichier : c’est de l’AES-256, la clé est le sha256 du mot de passe.



KeePass tourne sous tout os. Dropbox est un exemple, on peut utiliser n’importe quel service de stockage en ligne, même un truc complètement public, vu que tout est chiffré.


votre avatar



En effet, alors que le stockage d’une empreinte du mot de passe au sein d’une base de données semble tenir du bon sens pour n’importe quel développeur ayant déjà produit plus de dix lignes de code dans sa vie





Semble, seulement … <img data-src=" />



Pour autant il y a du progrès chez les “pro”, je doute que ce soit le cas sur les petits sites communautaires …

votre avatar







Freud a écrit :



KeePass est open source. Le fichier de mots de passe est en format XML.



Tu peux toi-même coder ton utilitaire pour ouvrir ce fichier : c’est de l’AES-256, la clé est le sha256 du mot de passe.



KeePass tourne sous tout os. Dropbox est un exemple, on peut utiliser n’importe quel service de stockage en ligne, même un truc complètement public, vu que tout est chiffré.







Pas faux.


votre avatar







Weig a écrit :



Et comment ça se passe au niveau portabilité ?

Ça veut dire qu’il faut que l’application (ici KeePass) tourne sur tout OS (PC, smartphone, tablettes etc) et que le logiciel de partage de fichier aussi. (ici DropBox)



Ce n’est pas une situation très pérenne je trouve…





Au-delà de ces problèmes, c’est surtout le côté pas pratique qui est problématique.



J’ai utilisé Keepass quelques mois. Et franchement, dans un monde où tu passes ta vie à rentrer des mots de passe, c’est carrément casse-couilles, à chaque fois qu’on t’en demande un, de lancer Keepass, de retrouver le service, de copier le mot de passe, de le coller, etc…


votre avatar







Nathan1138 a écrit :



Sans doute.



Mais si tu écoutes les experts en sécurité, il faudrait avoir 50 mots de passe différents composés de 20 minuscules, majuscules, nombres et caractères spéciaux.



Prêts ? C’est parti : on commence par {Y3;qv3xV5 puis )iUL;e9g59 et ensuite K8(/qY2ck6 et après *UpXhf64#4…



Désolé, je suis pas R2D2.







Si tu avais lu la news ils parlent justement d’un logiciel qui permet de gérer ça pour un humain normal <img data-src=" />


votre avatar







Jean_Peuplus a écrit :



Si tu avais lu la news ils parlent justement d’un logiciel qui permet de gérer ça pour un humain normal <img data-src=" />





Si tu avais lu mes autres commentaires, tu aurais vu que j’ai déjà testé KeePass et que ce logiciel ne m’a absolument pas convaincu <img data-src=" />


votre avatar







Freud a écrit :



Tu en es le parfait exemple :)





Normal, le ‘dredi je me transforme en <img data-src=" /> Je trouve que je suis particulièrement en forme aujourd’hui.







Sais-tu seulement la différence entre une attaque de préimage et une attaque de collision ? De toute évidence non. MD5 est encore résistant aux attaques de préimage. Pas vraiment aux collisions. Mais une attaque de collision implique que tu as un minimum de contrôle sur les deux messages d’origine, ce qui n’est pas le cas quand tu cherches à retrouver un message donnant un certain hash.



Sais-tu seulement lire? Je vais te reformuler ce que j’avais écrit: si tu as l’ensemble des collisions possible pour un hash ALORS la préimage est dans cet ensemble. Évidement on ne peut pas avoir l’ensemble des collision si tu veux savoir comme résoudre ce point, relire mon commentaire.









Et la rainbow table, elle a été créée comment ? Par magie ? Créer une rainbow table, c’est calculer des milliards de milliards de hashs, retirer les “intermédiaires”. L’utiliser pour trouver un mot de passe, c’est espérer que le mot de passe en questions faisait partie de ceux caculés lors de la création de la table. La base de la rainbow table reste du brute force, l’utiliser c’est un bruteforce “indirect” si je puis dire.



Ouais ou encore capitaliser du calculus ou faire de la programmation dynamique (de loin j’avoue). Je dis pas, il faut remplir la table mais à l’usage ça n’a plus rien à voir! Ce qui est calculé et conservé. Pour moi il y a une grande différence, autant qu’entre la marche à pied et une catapulte.





Je ne vois pas le rapport avec le reste, mais bon.



Tu ne te préoccupes que de la préimage. J’ai donc cherché à montrer l’intérêt d’obtenir une collision. C’est plus facile d’obtenir une collision sur du MD5 que sur du SHA1 donc, dans certaines conditions, il est préférable d’utiliser le SHA1 que du MD5. C’est tout.









Là j’ai vraiment du mal à te suivre, tes phrases deviennent incompréhensibles.



Comme je suis capable d’empathie, je vais me mettre à ton niveau:

Collision =&gt; pirate entrer dans autres comptes

hash+sel =&gt; pirate pas entrer dans autres comptes

hash+sel =&gt; pirate utiliser rainbow table

hash+sel+rainbow table =&gt; pirate entrer dans autres comptes

hash*5000+sel =&gt; pirate pas pouvoir utiliser rainbow table

hash*5000+sel =&gt; pirate pas pouvoir entrer dans autres comptes







Tu peux pas fermer les yeux et crier “non non les rainbow table n’existe pas!”. Elles existent est permettent de pailler aux insuffisances du bruteforce bête et méchant. Elles ont rien de magique, elle permettent juste de calculer à l’avance.


votre avatar

En même temps, si le sel est simple, par brute force y’a un effet encore plus rigolo; tu trouves le sel ET le mot de passe, et du coup tu peux cracker les autres mots de passe encore plus facilement que le premier … <img data-src=" />



De toutes façons l’adage dit: quand la serrure a 3 points, pète le mur. Si les mecs y arrivent pas par brute force, il y a le social engineering, entre autres. Du coup ça se résume à : jusqu’à quel point tu as envie de faire chier les vilains pirates pour qu’ils essaient de trouver tes mdp ?

votre avatar







lildadou a écrit :



Comme je suis capable d’empathie, je vais me mettre à ton niveau:

Collision =&gt; pirate entrer dans autres comptes

hash+sel =&gt; pirate pas entrer dans autres comptes

hash+sel =&gt; pirate utiliser rainbow table

hash+sel+rainbow table =&gt; pirate entrer dans autres comptes

hash*5000+sel =&gt; pirate pas pouvoir utiliser rainbow table

hash*5000+sel =&gt; pirate pas pouvoir entrer dans autres comptes







J’avoue que c’est plus simple comme ça :)



Tu as oublié : hash+sel différent pour chaque compte =&gt; pirate pas pouvoir utiliser rainbow table

ou: hash(hash(password + sel) + sel2) =&gt; pirate pas pouvoir utiliser rainbow table



Mais j’avoue que j’avais du mal à comprendre ou tu voulais en venir, vu que depuis mon premier message j’ai expliqué que hash(pass) ou hash(pass + sel) ce n’est pas vraiment très sécurisé.





Tu peux pas fermer les yeux et crier “non non les rainbow table n’existe pas!”. Elles existent est permettent de pailler aux insuffisances du bruteforce bête et méchant. Elles ont rien de magique, elle permettent juste de calculer à l’avance.





Oui, d’où toutes les autres solutions que j’ai données depuis mon premier message.



D’où ma difficulté de comprendre où tu voulais en venir.


votre avatar

SHA-1 ? Non mais c’est une blague ou quoi ? Si c’est pour stocker en SHA-1, autant mettre les mots de passe en clair. Un GPU moderne déchiffre un milliard de hashes SHA-1 à la seconde, et sans rainbow table (donc osef du salting).

votre avatar

Edit : “Calcule et compare”, pas “déchiffre”.









David_L a écrit :



C’est toujours mieux que les bouts de papier, ou le mot de passe unique. Surtout que pour le coup, l’ensemble peut être chiffré et protégé de manière assez complète.





+1000







Freud a écrit :



La clé n’est pas créée de manière pseudo-aléatoire (qu’est-ce que ça veut dire d’ailleurs ?)





Les ordinateurs n’ont pas de générateur aléatoire, ils se content de partir d’une graine généralement liée à la valeur d’une horloge au début du procédé, puis d’y appliquer une série de transformations. Donc pseudo-aléatoire, plutôt qu’aléatoire. Pour moi c’est du pédantisme : à part au niveau quantique, tout ahasard est pseudo-aléatoire.







tsubasaleguedin a écrit :



LE probleme c’est que 80% des utilisateur non geek veulent retrouver leur MDP quand il clique sur “J’ai perdu mon mdp comme un con”, ce qui implique une maniere de le retrouver et pas uniquement stocker un md5.





Non, la majorité des utilisateurs demandent la possibilité de résoudre le problème du mot de passe oublié. Que ce soit par un renvoi du mdp d’origine ou d’un nouveau, ils s’en fichent.


votre avatar







HarmattanBlow a écrit :



SHA-1 ? Non mais c’est une blague ou quoi ? Si c’est pour stocker en SHA-1, autant mettre les mots de passe en clair. Un GPU moderne déchiffre un milliard de hashes SHA-1 à la seconde, et sans rainbow table (donc osef du salting).





Sachant que le SHA-1 fait 160 bits, en brute-force ça fait 2¹6° combinaisons. 1 milliard par seconde, ça en fait environ 2³°/s. Il faut donc 2¹³° secondes sur un tel GPU pour tester toutes les combinaisons.



Soit environ 43000 milliards de milliards de milliards d’années. Tu peux faire tourner plusieurs CPU en parallèle si ça te fait plaisir.


votre avatar







HarmattanBlow a écrit :



Les ordinateurs n’ont pas de générateur aléatoire, ils se content de partir d’une graine généralement liée à la valeur d’une horloge au début du procédé, puis d’y appliquer une série de transformations. Donc pseudo-aléatoire, plutôt qu’aléatoire. Pour moi c’est du pédantisme : à part au niveau quantique, tout ahasard est pseudo-aléatoire.





Si, depuis Ivy Bridge <img data-src=" />



pcinpact.com PC INpact


votre avatar







®om a écrit :



Sachant que le SHA-1 fait 160 bits, en brute-force ça fait 2¹6° combinaisons. 1 milliard par seconde, ça en fait environ 2³°/s. Il faut donc 2¹³° secondes sur un tel GPU pour tester toutes les combinaisons.



Soit environ 43000 milliards de milliards de milliards d’années. Tu peux faire tourner plusieurs CPU en parallèle si ça te fait plaisir.





Tu m’as mal compris (voir l’édition sur post suivant). Avec un GPU moderne, tu calcule les hashes d’un milliard de mdp par seconde.



Si on prend des mdp saltés et que tu disposes des salts (et si les types s’en foutent au point d’utiliser SHA-1, tu peux être sûr que tu les as eus en même temps que la DB), en pariant sur 100k tentatives en moyenne pour trouver la plupart des mdp, tu obtiens 10k mdp par seconde.



@David

Votre article parle bien de cette fonctionnalité mais ne dit rien quant à sa nature pseudo-aléatoire ou non. Tu es bien sûr que ce n’est pas pseudo-aléatoire ?


votre avatar

Le vrai problème ici c’est l’envoi du pass dans un mail. Comme à peu près personne n’envoi de mail over ssl ca veut dire que “n’importe qui” peux y accéder.



Après comme l’a déjà dis HarmattanBlow sha1 c’est guère plus sécurisé que du md5 niveau bruteforce (plus à cause des nombreuses rainbow table amha).

La “norme” en ce moment c’est les algos basé sur bcrypt qui l’avantage d’être très long pour faire un hash et donc du coup très long à bruteforcer. Sans compter qu’il est évolutif puisque qu’on fournit un coût à l’algo qui permet d’augmnter sa complexiter avec la puissance des machine.

votre avatar

La redoute.fr renvoie le mot de pass en clair dans un mail. Je les ai contacte mais je n’ai jamais eu la moindre réponse.



Je pense que des site aussi mal conçue il y en a des tonnes.

votre avatar

Apple stocke les mots de passe !



Ils m’ont obligé à changer de mot de passe, je l’ai donc fait puisque je n’avais pas le choix et aussitôt été dans l’option pour changer de mot de passe et remettre l’ancien. Ils ont détecté que le mot de passe avait déjà été utilisé. J’ai essayé de mettre un autre mot de passe et de le rechanger pareil.



Apple stocke votre mot de passe actuel ainsi que tous les anciens.

votre avatar



LDLC, high tech experience





<img data-src=" />



La preuve par l’exemple <img data-src=" />

votre avatar







linconnu a écrit :



Apple stocke les mots de passe !



Ils m’ont obligé à changer de mot de passe, je l’ai donc fait puisque je n’avais pas le choix et aussitôt été dans l’option pour changer de mot de passe et remettre l’ancien. Ils ont détecté que le mot de passe avait déjà été utilisé. J’ai essayé de mettre un autre mot de passe et de le rechanger pareil.



Apple stocke votre mot de passe actuel ainsi que tous les anciens.





Non, ca prouve rien.

Ie site a très bien pu comparer les hash (du mot de passe ancien perdu et du nouveau) et constater qu’ils étaient identique, donc que a priori, sauf gros pas de bol (collision), les mots de passe étaient les même.


votre avatar







lildadou a écrit :



Qu’est ce qu’on voit pas passer comme conneries sur PC INpact en se moment!







Je suis tout à fait d’accord, la preuve dans ce qui suit.









lildadou a écrit :



Les transferts de mail sont chiffrés… enfin normalement. Le problème c’est qu’on ne sait pas si tout les transferts entre les MTA ont eu lieu de façon chiffré. Vous ne pouvez être sur que du transfert entre les 2 derniers MTA… càd entre celui de votre client de messagerie ou browser (la taxonomie est pas exacte du coup mais on s’en fout) et le serveur de votre fournisseur de service.







https://support.mozillamessaging.com/fr/kb/configuration-des-principaux-fourniss…



Voilà une belle brochette de serveur POP et/ou IMAP absolument pas sécurisé/chiffré … Et ils font partis des plus utilisés par la majorité (on ne parle pas de la population plus que réduite de geeks et autres personnes sensibles à la sécurité au vu de la population française/mondiale)


votre avatar







Freud a écrit :



Tu as oublié : hash+sel différent pour chaque compte =&gt; pirate pas pouvoir utiliser rainbow table

ou: hash(hash(password + sel) + sel2) =&gt; pirate pas pouvoir utiliser rainbow table





Pour moi le sel est toujours différent pour chaque compte.

Dans ton premier c’est beaucoup moins efficace mais on peut encore rainbower. Le deuxieme apporte pas beaucoup plus (le cout calculatoire supplémentaire) car hash(hash(password + sel) + sel2) se simplifie en hash(password2+sel2).

hash(hash(hash(hash(…hash(pass+sel))))))…) c’est vraiment ce qu’il y a de plus efficace contre la rainbow car ajouter une entrée va être très couteux!







Ben j’ai pas dis que t’avais tort partout <img data-src=" />



Mais j’avoue que j’avais du mal à comprendre ou tu voulais en venir, vu que depuis mon premier message j’ai expliqué que hash(pass) ou hash(pass + sel) ce n’est pas vraiment très sécurisé.















David_L a écrit :



Si, depuis Ivy Bridge <img data-src=" />

pcinpact.com PC INpacthey ben, ct’architerchitecture CISC c k’sa ch’arrange pô ‘vec l’temps! V’là q’les processeeeeur font des truc pô déterministe. Le mode d’emploi doit être aussi épais que Jocelyne la putain aux triplés.



Plus sérieusement, @David_L les nombres produits par une machine ne sont pas aléatoire. Ils ont des propriétés qui font qu’ils sont exploitable en cryptographie mais ça en fait pas des nombres aléatoires. Les seuls nombres aléatoires disponibles dans une machine sont celles fourni par des mesures physique. Sous Linux ces valeurs sont précieusement stocké le reservoir entropique /dev/random il faut beaucoup de temps pour produire quelques malheureux bits réellement aléatoire. C’est pourquoi on va dériver ces très rares bits très aléatoires en beaucoup de bits un peu moins aléatoire.


votre avatar







tsyr2ko a écrit :



Voilà une belle brochette de serveur POP et/ou IMAP absolument pas sécurisé/chiffré … Et ils font partis des plus utilisés par la majorité (on ne parle pas de la population plus que réduite de geeks et autres personnes sensibles à la sécurité au vu de la population française/mondiale)





Mmmh et? T’es censé m’informer de quelque chose? T’as quand même conscience que tu parles des serveurs de messagerie du FAI? Le truc que seul Mme Michu utilise et que comme c’est Mme Michue alors elle le fait depuis ça connexion Internet. Tu peux me dire l’interet de chiffrer quelque chose qui reste sur son réseau?



M’enfin c’est pas pour ça que t’es le plus ridicule (j’en profite, encore 30m avant la fin du ‘dredi). Le plus important dans ce que je disais c’est le flou total des connections entre les MTA. Quand Samsung discute avec un serveur GMail, qui te dit qu’il le font de façon chiffrée?



De toute façon, pourquoi tu te préoccupes du chiffrement des connexion puisque au final je parie que t’heberge tes mails en clair sur GMail <img data-src=" />


votre avatar

Quelqu’un connait il Dashlane, et ce qu’il vaut ? J’ai un ami qui a installé ça sur son PC. Il en est content, et serait

https://www.dashlane.com/fr



“Toutes les données personnelles que vous enregistrez dans votre compte Dashlane sont chiffrées localement sur vos appareils en AES-256. “

votre avatar

Un article plutôt sympa sur le stockage de MDP:



https://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/



La partie INtéressante c’est qu’ils stockent le salt sur la machine frontale, pas dans la BDD, ça demande donc deux attaques différentes pour pouvoir commencer à espérer pouvoir décrypter les mdp.



Ça donne:



H: password -&gt; bcrypt(HMAC(password, local_salt), bcrypt_salt)



Et un autre qui aborde des conseils coté programmation et utilisateur (comme l’utilisation de passphrases en lieu et place des passwords, c’est peu souvent applicable car on est limité en taille ou en type de caractères)



http://www.codinghorror.com/blog/2012/04/speed-hashing.html

votre avatar







herbeapipe a écrit :



Quelqu’un connait il Dashlane, et ce qu’il vaut ? J’ai un ami qui a installé ça sur son PC. Il en est content, et serait

https://www.dashlane.com/fr



“Toutes les données personnelles que vous enregistrez dans votre compte Dashlane sont chiffrées localement sur vos appareils en AES-256. ”





Dashlane est un gestionnaire de mots de passe classique. Il va un peu plus loin en offrant un remplissage automatique des formulaires web et en signalant éventuellement les mots de passe corrompus parce que la DB d’un site a été volée (ceux qui l’ont signalé en tout cas). Si tu n’as pas besoin de ces fonctionnalités, un autre fera aussi bien l’affaire.



Est-il bien sécurisé ? Sans doute. Par contre leur générateur de mdp est assez basique : si quelqu’un utilise un tel gestionnaire, autant proposer des mdp utilisant toute la plage unicode. Un mdp à douze caractères mélangeant du sanscrit, du chinois, et autres, personne ne le violera avant des décennies. Je leur reproche aussi leur évaluation de mdp, trop simple et qui peut faussement mettre en confiance l’utilisateur.







Shinuza a écrit :



La partie INtéressante c’est qu’ils stockent le salt sur la machine frontale, pas dans la BDD, ça demande donc deux attaques différentes pour pouvoir commencer à espérer pouvoir décrypter les mdp.





Oui, c’est ce qui est recommandé par tout le monde et mis en oeuvre par bien trop peu de sites. ^^


votre avatar







fwak a écrit :



Je trouve idiot/dangereux de stocker tous ses mots de passe dans un seul outil.





Bof, tant qu’ils n’ont pas inventé de moyen discret et efficace de lire dedans, je vais continuer de garder tous mes mots de passe au même endroit, mon cerveau ;-)


votre avatar







Freud a écrit :



Un mot de passe renvoyé en clair peut être stocké chiffré avec un algorithme tel qu’AES par exemple.



Mais ça reste une mauvaise pratique, car le transit par mail est forcément en clair, sans parler du problème si la clé secrète est récupérée en même temps que la base de données par un attaquant.







Si l’attaquant connait un ou plusieurs mots de passe de la base (soit le sien, soit il repère des mots de passes multiples et en déduit que c’est “toto” ou “dieu” ou “justin bieber”, ça dépend du public cible du site), il peut (essayer de) bruteforcer la clé. Ça peut être long, bien sûr, mais pas besoin de la clé donc (ou plutôt, il y a parfois moyen de la reconstruire)







Spidard a écrit :



Ca par contre je plussoie. Comme pour l’email. Quelle intérêt de le faire répéter ? je suis sur que la plupart des gens le copie-collent d’un champ à l’autre.





Autant je plussoie pour l’email (surtout qu’il suffit d’appeler le champ “email” pour que le navigateur propose un peu d’aide), autant pour le mot de passe je vois l’intérêt, qui est d’éviter la faute de frappe idiote (surtout qu’on ne le voit pas)







fred42 a écrit :



Voici une petite liste de sites de recherche d’emploi avec des problèmes de sécurité de mot de passe. J’ai fait ce travail en juillet pour voir là où il fallait que je mette des mots de passes uniques et je viens de vérifier que c’est encore le cas.



cadremploi :

login en http et pas https

cadresonline :

keljob :

APEC :

RegionsJob :

jobtic :





Tu as postulé chez eux du coup ?







lildadou a écrit :



Les transferts de mail sont chiffrés… enfin normalement. Le problème c’est qu’on ne sait pas si tout les transferts entre les MTA ont eu lieu de façon chiffré. Vous ne pouvez être sur que du transfert entre les 2 derniers MTA… càd entre celui de votre client de messagerie ou browser (la taxonomie est pas exacte du coup mais on s’en fout) et le serveur de votre fournisseur de service.





Là tu confonds SMTP et POP3/IMAP. Tu as assez peu de garanties sur le voyage de ton email, et même si la connection entre deux serveurs SMTP est chiffrée, l’admin de chaque serveur peut voir le contenu du mail (s’il n’est pas chiffré lui même)







fred42 a écrit :



Les questions et réponses secrètes sont des failles énormes : un peu de “social engineering” et on connaît la réponse.

Je hais les sites qui imposent cette méthode.



Quand à l’humain qui donne un mot de passe temporaire, comment fait-il pour savoir que c’est la bonne personne qui l’appelle et qu’il faut l’autoriser à accéder au compte ?





Pour les questions secrètes, moi aussi je déteste. Je n’arrive jamais à me rappeler quelle réponse absurde j’ai pu donner à dans quelle ville êtes-vous né. Le choix de réponse est trop vaste, ça peut aller de Léningrad à “le compte est bon” en passant par dfklsjfdlks ou “Stéphanie de Monaco”.

Pour le mot de passe temporaire, il se base sur le fait que le client maitrise toujours son compte mail. Ce qui peut être un gros fail. Il peut mixer ça avec une question secrète que l’attaquant qui possède déjà le compte mail aura du mal à trouver. Dis maman, comment s’appelait déjà l’hôpital ou je suis né ?


votre avatar







yoda222 a écrit :



Bof, tant qu’ils n’ont pas inventé de moyen discret et efficace de lire dedans, je vais continuer de garder tous mes mots de passe au même endroit, mon cerveau ;-)





Autrement dit tu utilises des mots de passe simples, que tu réutilises d’un site à l’autre. Tout ce qu’il ne faut pas faire. ;)



Utilisez un gestionnaire de mot de passe, rogntudju ! Avec des mots de passe longs, complexes, plein de caractères exotiques, uniques (sauf sur les sites sans importance où l’on peut réutiliser le même à chaque fois).


votre avatar







®om a écrit :



Sachant que le SHA-1 fait 160 bits, en brute-force ça fait 2¹6° combinaisons. 1 milliard par seconde, ça en fait environ 2³°/s. Il faut donc 2¹³° secondes sur un tel GPU pour tester toutes les combinaisons.



Soit environ 43000 milliards de milliards de milliards d’années. Tu peux faire tourner plusieurs CPU en parallèle si ça te fait plaisir.









linconnu a écrit :



Apple stocke les mots de passe !

Tu prends le calcul à l’envers. Enfin tu supposes que ton utilisateur a un vrai mot de passe aléatoire. Ce qui est généralement faux. Il faut calculer combien de mots de passe se trouvent dans le sous ensemble que tu considères. Ça peut être [a-z], [a-zA-Z0-9], le même avec les caractères facilement accessible sur le clavier, [mot du dictionnaire]*, …

Si on prend [a-zA-Z0-9], avec n caractères, on a 62^n combinaisons. Si on prend 8 caractères, ça fait (à 1e9 mdp par seconde) 60 heures. Et franchement, 8 caractères alphanumériques, ça te trouve pas mal de monde (mais 60h/personne c’est beaucoup) Mais c’est plus efficace sur les dictionnaires de mots + variation de la case + insertion de chiffres.



Ils m’ont obligé à changer de mot de passe, je l’ai donc fait puisque je n’avais pas le choix et aussitôt été dans l’option pour changer de mot de passe et remettre l’ancien. Ils ont détecté que le mot de passe avait déjà été utilisé. J’ai essayé de mettre un autre mot de passe et de le rechanger pareil.



Apple stocke votre mot de passe actuel ainsi que tous les anciens.





votre avatar







HarmattanBlow a écrit :



Autrement dit tu utilises des mots de passe simples, que tu réutilises d’un site à l’autre. Tout ce qu’il ne faut pas faire. ;)



Utilisez un gestionnaire de mot de passe, rogntudju ! Avec des mots de passe longs, complexes, plein de caractères exotiques, uniques (sauf sur les sites sans importance où l’on peut réutiliser le même à chaque fois).





Non, pas vraiment. Enfin, ça dépend. Si je dois m’inscrire pour jouer à un jeu en flash, le mot de passe ce sera toto, je m’en fous. Si c’est pour mes banques ou mes mails ou autre truc critique, ce sera un différent dans chaque coup. Si c’est faiblement important mais que je ne veux quand même pas qu’on me le casse, ce sera toto_pci_tutu, ou quelque autres combinaisons comme ça. Et encore mieux, souvent, je mets un truc aléatoire, je dis à mon navigateur de prendre le cookie d’authentification, et j’oublie le mot de passe. Et j’en demande un neuf si j’ai besoin de me reconnecter. (si c’est eux qui le génère, c’est encore mieux)


votre avatar







lildadou a écrit :



Plus sérieusement, @David_L les nombres produits par une machine ne sont pas aléatoire. Ils ont des propriétés qui font qu’ils sont exploitable en cryptographie mais ça en fait pas des nombres aléatoires. Les seuls nombres aléatoires disponibles dans une machine sont celles fourni par des mesures physique. Sous Linux ces valeurs sont précieusement stocké le reservoir entropique /dev/random il faut beaucoup de temps pour produire quelques malheureux bits réellement aléatoire. C’est pourquoi on va dériver ces très rares bits très aléatoires en beaucoup de bits un peu moins aléatoire.







Bah justement : RTFM





Intel’s source of entropy inside the DRNG is thermal noise, samples from outside the chip. The source itself is a self-timed digital circuit that pushes a latch into metastability at about 3 GHz. The DRNG operates in two stages, one dedicated to conditioning entropy extraction, and the digital random number generation itself.


votre avatar







lildadou a écrit :



Mmmh et? T’es censé m’informer de quelque chose? T’as quand même conscience que tu parles des serveurs de messagerie du FAI? Le truc que seul Mme Michu utilise et que comme c’est Mme Michue alors elle le fait depuis ça connexion Internet. Tu peux me dire l’interet de chiffrer quelque chose qui reste sur son réseau?



M’enfin c’est pas pour ça que t’es le plus ridicule (j’en profite, encore 30m avant la fin du ‘dredi). Le plus important dans ce que je disais c’est le flou total des connections entre les MTA. Quand Samsung discute avec un serveur GMail, qui te dit qu’il le font de façon chiffrée?



De toute façon, pourquoi tu te préoccupes du chiffrement des connexion puisque au final je parie que t’heberge tes mails en clair sur GMail <img data-src=" />





Passons outre les attaques personnelles sur comment je gère mes mails, cela n’a rien à faire ici.



Le point soulevé ici est la transmission en clair du mot de passe dans un mail.



Pourquoi donc ?



Comme déjà expliqué, le fait que le mot de passe soit stocké en clair dans les mails de l’utilisateur est contraire à toute politique de sécurité. On ne peut pas raisonnablement dire “c’est pas de notre faute s’il n’a pas supprimé son mail” …



Ensuite, comme tu aimes employer des termes techniques, allons-y gaiement. Tu dis qu’on ne peut pas être sûr que les échanges entre MTA sont chiffrés, et uniquement de l’échange entre les deux derniers MTA … En fait, il s’agit plutôt du dernier échange entre le MTA et ton MUA. De plus, tu te moques royalement du fait que certains FAI/services n’utilisent pas de chiffrement (SSL/TLS ou autre) mais pourtant, lorsque notre société évolue de plus en plus vers la mobilité, nous ne sommes plus forcément derrière notre box sur notre PC mais un peu partout, et donc n’importe qui pouvant intercepter les paquets réseaux se fera une joie de recueillir ces données. (cf “Tu peux me dire l’interet de chiffrer quelque chose qui reste sur son réseau?”)

De plus, sur cette page, tu trouveras plein d’informations :fr.wikipedia.org WikipediaDonc, que les échanges soient chiffrés ou pas, le mieux étant de crypter le CONTENU avec PGP ou autres programmes du genre. (cf “Le plus important dans ce que je disais c’est le flou total des connections entre les MTA.” &lt;= osef puisqu’au final, c’est crypté par l’expéditeur)



Bref, visiblement, tu n’es là que pour troller et faire semblant d’étaler une science que tu n’as pas ou alors que tu n’arrives pas à exprimer dans le bon contexte en occultant complétement le problème principal : on n’envoie pas un mot de passe en clair par email, puisqu’on ne peut pas garantir que l’information sera transmise de manière sécurisée tout au long du transport.



A bon entendeur, salut.


votre avatar

Il y a fort longtemps que j’ai mis en œuvre les formes hashées des mots de passe pour mes services avec inscription.

Dans mon cas il s’agit de gérer ses devoirs en ligne.



Au début, j’utilisais un hashage CRC32 sans grain de sel, une horreur, mais bien meilleure que rien.

J’ai migré vers un hashage MD5 [du mot de passe et du CRC32 du mot de passe et d’une partie aléatoire constante] : efficace. J’ai mis en place la migration automatiquement lors de l’authentification des utilisateurs (car c’est le seul moment où je dispose de la version en clair).



De plus, les applications Facebook demandant la présence d’une politique de confidentialité sur le site, j’ai précisé en détails tout ce qui est conservé, ainsi que la forme du mot de passe.

votre avatar

Je voudrais aussi (désolé du multipost) préciser qu’il n’existe aucun cryptage d’aucune façon lors de l’envoi d’email.




  • Entre le serveur Web, qui envoie à un serveur SMTP d’envoi, il n’y a généralement pas de cryptage.

  • Entre le SMTP d’envoi et le SMTP de destination (celui qui inclut votre boîte), il n’y a aucun cryptage, c’est du SMTP en clair sur le port TCP 25.

  • Si vous n’êtes pas l’unique utilisateur de la boîte, il est possible que le mot de passe soit visualisé par un autre utilisateur (légitime ou non).



    C’est donc dangereux de toute façon d’envoyer par email un mot de passe.

votre avatar







HarmattanBlow a écrit :



Dashlane est un gestionnaire de mots de passe classique. Il va un peu plus loin en offrant un remplissage automatique des formulaires web et en signalant éventuellement les mots de passe corrompus parce que la DB d’un site a été volée (ceux qui l’ont signalé en tout cas). Si tu n’as pas besoin de ces fonctionnalités, un autre fera aussi bien l’affaire.



Est-il bien sécurisé ? Sans doute. Par contre leur générateur de mdp est assez basique : si quelqu’un utilise un tel gestionnaire, autant proposer des mdp utilisant toute la plage unicode. Un mdp à douze caractères mélangeant du sanscrit, du chinois, et autres, personne ne le violera avant des décennies. Je leur reproche aussi leur évaluation de mdp, trop simple et qui peut faussement mettre en confiance l’utilisateur.





Oui, c’est ce qui est recommandé par tout le monde et mis en oeuvre par bien trop peu de sites. ^^







Merci pour l’info ;)



Donc pas trop mal en définissant un mot de passe compliqué perso à chaque fois.


votre avatar



N’hésitez donc pas à vous en plaindre auprès du service client, ou à exiger de savoir comment était stocké votre mot de passe, lorsque vous constatez que c’est le cas, et à nous indiquer au sein de nos commentaires ceux que vous avez pu repérer vous-même.





Heureusement que tous les utilisateurs normaux ne lisent pas PCinpact sinon ça serait la rébellion au niveau du support client. <img data-src=" />



Et encore le mot de passe en clair c’est pas le pire. Le top de l’insécurité c’est de faire du mot de passe en clair avec vérification en casse insensible.



Comme pourrait dire un certain dirigeant si vous voulez qu’une information reste secrète il suffit de ne pas la donner. En gros si vous voulez que votre mot de passe reste secret, il suffit de ne pas l’utiliser.

votre avatar



Le mot de passe : une procédure de sécurité devenue insuffisante ?





Réponse : Oui



http://www.wired.com/gadgetlab/2012/11/ff-mat-honan-password-hacker/all/



Avec crypto-js, faudrait peut être démocratiser le hashage côté client, avant même que le POST soit fait… Est-ce une bonne idée selon vous ?

votre avatar







La news a écrit :



Ces derniers mois, nous avons d’ailleurs pu remarquer une pratique similaire chez de nombreux services importants lors de l’inscription. Si certains ont depuis effectué des changements, ce n’est pas le cas de Pizza Hut, Relay, Sarenza, le service de commande d’accessoires de SFR (Modelabs), Recatch.tv, Speed Burger ou Tiilt pour ne citer qu’eux. Les revendeurs high-tech ne sont d’ailleurs pas des cas à part puisque nous avons pu constater que Boulanger, Darty et LDLC faisaient de même :







Et Free aussi (vérifié à l’instant) <img data-src=" />


votre avatar







Florent_ATo a écrit :



Réponse : Oui



http://www.wired.com/gadgetlab/2012/11/ff-mat-honan-password-hacker/all/





Pas d’accord, d’autant qu’il n’y a aucune alternative valable (biométrie = mdp unique plus facile à voler qu’un mdp mémorisé). Le problème n’est pas de renoncer aux mots de passe, le problème est qu’il serait temps que l’on commence enfin à faire les choses comme elles auraient toujours dû être faîtes :

* Pas de SHA-1 ou de MD5 ! Ça fait des années que les agences de sécurité du monde entier le disent et ces fonctions de hashage sont encore très fréquentes. Avec toutes les techniques calculatoires et comportementales (listes de mpd fréquents, chaînes de Markov, …) aujourd’hui disponibles, même un bon mdp salé de 8 caractères ne tient pas face à un attaquant déterminé s’il a été hashé via SHA-1, point barre.

* Rendre les sels difficiles à obtenir et nécessitant une attaque distincte.

* Mettre fins aux systèmes à la con (question secrète et autres) pour la gestion du problème du mot de passe oublié, préférer une authentification via numéro de téléphone si l’utilisateur redoute avant tout une attaque en ligne, et dans le cas où il saisit une autre adresse mail, l’avertir que son mdp devra être différent.

* Cesser d’envoyer des mdp autres que temporaires.

* Utiliser des mdp exploitant toute la plage unicode, stcokés via un gestionnaire avec un solide mdp maître et une fonction de hashage prenant au moins une seconde.

* Que tout le monde éduque l’utilisateur pour qu’il comprenne qu’un mdp doit être unique, ne doit pas être un mot (même avec substitutions leetspeak ou SMA), nombre ou date, etc.

* Anti-malwares par défaut dans tous les OS. C’est la responsabilité d’un éditeur d’OS aujourd’hui.


votre avatar







flamaros a écrit :



La redoute.fr renvoie le mot de pass en clair dans un mail. Je les ai contacte mais je n’ai jamais eu la moindre réponse.



Je pense que des site aussi mal conçue il y en a des tonnes.





Cashstore.fr



Je comprends pas que des sites marchands soient autorisés à stocker les mots de passe en clair…


votre avatar







HarmattanBlow a écrit :



* Que tout le monde éduque l’utilisateur pour qu’il comprenne qu’un mdp doit être unique, ne doit pas être un mot (même avec substitutions leetspeak ou SMA), nombre ou date, etc.



Ça va dans les deux sens, il faut que l’utilisateur moyen le comprenne, mais aussi que le système le permette, à croire qu’en 2012 on ne sait pas stocker des caractères dans une base de données.


votre avatar







Florent_ATo a écrit :



Avec crypto-js, faudrait peut être démocratiser le hashage côté client, avant même que le POST soit fait… Est-ce une bonne idée selon vous ?





Ça me parait être une très bonne idée <img data-src=" />


votre avatar







Yangzebul a écrit :



Bah justement : RTFM



The DRNG operates in two stages, one dedicated to conditioning entropy extraction, and the digital random number generation itself.


Bah TFM il dit la même chose que moi. Il y a un générateur de nombre pseudo-aléatoire.











tsyr2ko a écrit :



Passons outre les attaques personnelles sur comment je gère mes mails, cela n’a rien à faire ici.





/troll=off

On est plus ‘dredi donc j’arrête la posture trollesque.

Dans la mesure où l’information transite par un tier on peut dire que la confidentialité des échanges est déjà rudement mis à mal. Même si les connexions sont sécurisées le tier ne l’est pas et toute la chaine de confiance est mis à mal.





Le point soulevé ici est la transmission en clair du mot de passe dans un mail.



Pourquoi donc ?



Comme déjà expliqué, le fait que le mot de passe soit stocké en clair dans les mails de l’utilisateur est contraire à toute politique de sécurité. On ne peut pas raisonnablement dire “c’est pas de notre faute s’il n’a pas supprimé son mail” …



Je t’ai mis les contradictions en gras. En tout cas tu distingues comme moi 2 dimensions dans le processus de communication du mdp par mail : sa transmission et son stockage.







Ensuite, comme tu aimes employer des termes techniques, allons-y gaiement. Tu dis qu’on ne peut pas être sûr que les échanges entre MTA sont chiffrés, et uniquement de l’échange entre les deux derniers MTA … En fait, il s’agit plutôt du dernier échange entre le MTA et ton MUA. De plus, tu te moques royalement du fait que certains FAI/services n’utilisent pas de chiffrement (SSL/TLS ou autre) mais pourtant, lorsque notre société évolue de plus en plus vers la mobilité, nous ne sommes plus forcément derrière notre box sur notre PC mais un peu partout, et donc n’importe qui pouvant intercepter les paquets réseaux se fera une joie de recueillir ces données. (cf “Tu peux me dire l’interet de chiffrer quelque chose qui reste sur son réseau?”)

De plus, sur cette page, tu trouveras plein d’informations :fr.wikipedia.org WikipediaJ’ai pourtant précisé que ceux qui utilise le FAI de leur hébergeur était probablement des Mme Michue et que cette Mme Michu utilisait probablement la connexion Internet de son domicile pour consulter ces mails. Ceux qui savent installer un client de messagerie et le parametrer ont probablement en tête beaucoup plus de problématiques en tête lors du choix de leur prestataire de service mail. C’était facile de m’attaquer sur un point dont je me déclare d’emblée hors champs.





Donc, que les échanges soient chiffrés ou pas, le mieux étant de crypter le CONTENU avec PGP ou autres programmes du genre. (cf “Le plus important dans ce que je disais c’est le flou total des connections entre les MTA.” &lt;= osef puisqu’au final, c’est crypté par l’expéditeur)



Je suis d’accord avec toi. GPG (j’utilise X.509) permet d’assurer l’intégrité et la non-répudiation des messages, la confidentialité si les clefs sont échangées.



Mais on est sur un plan théorique! Je parlais en situation pratique: “Mme Michu, sur son ordi fixe, à sa maison qui consulte les mails fourni par son FAI”. C’est relative suffisant, sauf l’échange entre les MTA qui se passent en dehors du résuau FAI.



Il faut relativiser. L’envoi du passe par mail n’est pas aussi horrible que de stocker les passes en clair dans la BDD du serveur car dans ce cas il y a une concentration.











EstevanTH a écrit :



Je voudrais aussi préciser qu’il n’existe aucun cryptage d’aucune façon lors de l’envoi d’email.




  • Entre le serveur Web, qui envoie à un serveur SMTP d’envoi, il n’y a généralement pas de cryptage.

  • Entre le SMTP d’envoi et le SMTP de destination (celui qui inclut votre boîte), il n’y a aucun cryptage, c’est du SMTP en clair sur le port TCP 25.

  • Si vous n’êtes pas l’unique utilisateur de la boîte, il est possible que le mot de passe soit visualisé par un autre utilisateur (légitime ou non).



    C’est donc dangereux de toute façon d’envoyer par email un mot de passe.





    C’est dommage. Il y a beaucoup de connaissance à avoir pour envoyer proprement un mail (DKIM, SPF, MX, …) ; les admins seraient donc bien formés et aurait donc forcer les échanges chiffrés. Surtout que l’opération est simple.


votre avatar







lildadou a écrit :



Bah TFM il dit la même chose que moi. Il y a un générateur de nombre pseudo-aléatoire.







Non.

Ce n’est pas en le souhaitant très fort que tu aura raison. Il n’est nul part écrit “pseudo-aléatoire” comme tu l’affirme.



Les Ivy bridge utilisent une mesure externe pour avoir une source réelle d’entropie (comme tu l’expliquait justement).



Mais bon si tu veux être un pauvre con qui imagine (pour ne pas dire hallucine) lire des trucs qui n’existent pas et qui ne veux pas accepter des faits pourtant indéniables c’est ton problème.


votre avatar

TFM qui explique la différence entre un PRNG et un TRNG et pourquoi les Ivy bridge font partis de la seconde catégorie.



software.intel.com Intel

votre avatar







Yangzebul a écrit :



Non.

Ce n’est pas en le souhaitant très fort que tu aura raison. Il n’est nul part écrit “pseudo-aléatoire” comme tu l’affirme.



Les Ivy bridge utilisent une mesure externe pour avoir une source réelle d’entropie (comme tu l’expliquait justement).



Mais bon si tu veux être un pauvre * qui imagine (pour ne pas dire hallucine) lire des trucs qui n’existent pas et qui ne veux pas accepter des faits pourtant indéniables c’est ton problème.







Calme-toi, s’il te plait, et essayons d’opposer des arguments. Il existe 3 famille de RNG:




  • les générateurs purs. ce ne sont pas vraiment des générateurs mais plutôt des capteurs. Ils fournissent de vrai nombres aléatoires puisqu’il les “pêchent”.

  • les générateurs simple. ils fournissent des nombres dont les propriétés d’aléa sont suffisante pour du jeux, de la modélisation, etc. Les LFSR sont un bon représentant de cette classe de générateur

  • les générateurs de nombres cryptographiquement sur. Ils fournissent des propriétés d’aléa supérieur aux générateurs simple. Mais ils ont besoin d’une source pure pour fonctionner.





    Lisons TFM:



    With respect to the RNG taxonomy discussed above, the DRNG follows the cascade construction RNG model, using a processor resident entropy source to repeatedly seed a hardware-implemented CSPRNG. Unlike software approaches, it includes a high-quality entropy source implementation that can be sampled quickly to repeatedly seed the CSPRNG with high-quality entropy. Furthermore, it represents a self-contained hardware module that is isolated from software attacks on its internal state. The result is a solution that achieves RNG objectives with considerable robustness: statistical quality (independence, uniform distribution), highly unpredictable random number sequences, high performance, and protection against attack.



    This method of digital random number generation is unique in its approach to true random number generation in that it is implemented in hardware on the processor chip itself and can be utilized through a new instruction added to the Intel 64 instruction set. As such, response times are comparable to those of competing PRNG approaches implemented in software. The approach is scalable enough for even demanding applications to use it as an exclusive source of random numbers and not merely a high quality seed for a software-based PRNG. Software running at all privilege levels can access random numbers through the instruction set, bypassing intermediate software stacks, libraries, or operating system handling.





    Je suis désolé mais il tombe dans la troisième classe de générateur. Génération de pseudo-aléa à partir d’un aléa. Les super-arguments (je les ai mis en gras) de THM sont:

  • on a une source d’entropie de qualité pas comme les générateurs logicielle: effectivement si on compare à un générateur simple. Mais les générateurs cryptographiquement ont une source entropique certainement de meilleurs qualité car elle proviennent de plusieurs sources. De plus, avec du logiciel on sait et on peut prouver comment est constitué la reserve entropique. Intel dit dans TFM que sa source est un thermomètre dans le CPU… waaaa, je suis ébahi par la qualité de cette source. En comparaison la reserve entropique de Linux utilise la température de TOUT les composants qui ont un thermomètre, les variations dans le voltages, les paquets réseaux, les mouvements de souris, …

  • on a un algo matériel que tu peux pas hacker: … et que tu peux pas prouver. En logiciel l’algorithme de dérivation public garantie qu’il n’y ai pas de backdoor (cf. le bug du RNG de OpenSSL dans les années 2000). seed the CSPRNG sa ressemble quand même pas mal à ils ont besoin d’une source pure pour fonctionner. Entropie dérivée DONC pseudo-aléatoire, CQFD.





    Au final, non seulement ce générateur est banal générateur de nombres pseudo-aléatoire (mais cryptographiquement sûr) mais en plus il opacifie le processus de génération des nombres et interdit une éventuelle correction de l’implémentation (car matérielle).



    Intel n’est surement pas la parole divine surtout quand il parle de ses propres produit. Faudrait penser à mettre son cerveau sur ON et faire des lectures critique des “informations”


votre avatar

Franchement David, tu crois encore que la CNIL en à quelque chose à faire des usagers du net?



Le père noël c’est en décembre je sais bien mais là tout de même tu es crédule. <img data-src=" />

votre avatar

La sécurité <img data-src=" />

votre avatar







ulhgard a écrit :



Franchement David, tu crois encore que la CNIL en à quelque chose à faire des usagers du net?



Le père noël c’est en décembre je sais bien mais là tout de même tu es crédule. <img data-src=" />





Je dis juste que ça devrait sans doute aussi faire partie de son job, pas qu’elle le fait (même si le guide devrait être lu par pas mal de monde).


votre avatar



Pour chaque mot de passe stocké en clair, un chaton adepte du SHA-1 se noie





<img data-src=" />





LDLC faisaient de même :





Wahou, j’ai bien raison de m’embêter à traverser tous Paris pour aller à leur magasin

votre avatar

Pour info, ce n’est pas parceque le mot de passe est envoyé par mail lors de l’inscription que ce n’est pas son SHA-1 + salt qui sont stockés en DB.



Donc vos exemples ne sont pas représentatifs.



Il faudrait plutôt faire un “j’ai oublié mon mon mot de passe” pour voir si le mot de passe nous est renvoyé, ou s’il faut obligatoirement en créer un nouveau.



Et encore :





  • s’il est renvoyé, ça ne veut pas dire qu’il n’est pas crypté à mort de l’autre côté

  • s’il nous est demandé de créer un nouveau mot de passe, ça ne veut pas dire qu’il n’est pas stocké en clair quand même.

votre avatar







BlackYeLL a écrit :



Pour info, ce n’est pas parceque le mot de passe est envoyé par mail lors de l’inscription que ce n’est pas son SHA-1 + salt qui sont stockés en DB.





J’allais faire la même remarque. Si par contre le site propose de vous le renvoyer quand on fait “mot de passe oublié” plutôt que de vous en envoyer un totalement nouveau et/ou temporaire…..

Edit : pas bien d’éditer son post pour dire la même chose :p


votre avatar



des outils tels que KeePass





Je vais toaster ça ce WE.

votre avatar







BlackYeLL a écrit :



Pour info, ce n’est pas parceque le mot de passe est envoyé par mail lors de l’inscription que ce n’est pas son SHA-1 + salt qui sont stockés en DB.



Donc vos exemples ne sont pas représentatifs.



Il faudrait plutôt faire un “j’ai oublié mon mon mot de passe” pour voir si le mot de passe nous est renvoyé, ou s’il faut obligatoirement en créer un nouveau.



Et encore :





  • s’il est renvoyé, ça ne veut pas dire qu’il n’est pas crypté à mort de l’autre côté

  • s’il nous est demandé de créer un nouveau mot de passe, ça ne veut pas dire qu’il n’est pas stocké en clair quand même.





    Et donc le mot de passe, il est tiré du papa noël ?


votre avatar

En partie faux…



Je m’explique :



Recevoir le mot de passe en clair à l’inscription ne prouve pas que le service stocke les mots de passe en clair, car au moment de l’inscription il ne lit pas le mot de passe à partir de la base de donnée mais à partir du formulaire d’inscription, où le mot de passe est en clair (puisque rentré à la main par le nouvel utilisateur)





La vraie preuve est lors d’une procédure “mot de passe oublié” : si vous recevez votre mot de passe en clair à ce moment là alors il y a un problème de sécurité.



Sur mon site certaines personnes flippent car mal informées, et ce n’est pas cet article qui va rassurer. Merci de corriger :)

votre avatar







David_L a écrit :



Je dis juste que ça devrait sans doute aussi faire partie de son job, pas qu’elle le fait (même si le guide devrait être lu par pas mal de monde).









Le travail de la CNIL c’est d’avoir plus de pouvoir pour toujours avoir plus de budget car la soupe est bonne pour ces hauts fonctionnaires.

A part ça son utilité est de servir de caution morale pour tout un tas de personnes qui ne nous veulent pas du bien.

Voilà pour la réalité.



Dans la théorie je suis d’accord la sécurité des usagers du net devrait être une de leur principale préoccupation. Encore faudrait il que tout ces gens soient compétents ou embauchent en conséquence. Mais ça donnerait un sacré coup de rabot au budget restaurant, petits fours, voitures de fonctions et parties fines.



<img data-src=" />


votre avatar







winch a écrit :



En partie faux…



Je m’explique :



Recevoir le mot de passe en clair à l’inscription ne prouve pas que le service stocke les mots de passe en clair, car au moment de l’inscription il ne lit pas le mot de passe à partir de la base de donnée mais à partir du formulaire d’inscription, où le mot de passe est en clair (puisque rentré à la main par le nouvel utilisateur)





La vraie preuve est lors d’une procédure “mot de passe oublié” : si vous recevez votre mot de passe en clair à ce moment là alors il y a un problème de sécurité.



Sur mon site certaines personnes flippent car mal informées, et ce n’est pas cet article qui va rassurer. Merci de corriger :)





J’avais rajouté une précision pour que ce soit plus clair à ce niveau, mais il n’y a que moi qui trouve dingue l’idée d’envoyer un mot de passe en clair non temporaire par mail, pour quelque raison que ce soit ? Le formulaire est SSL j’espère ? <img data-src=" />



PS : merci d’éviter d’en profiter pour faire de l’auto-promo ;)


votre avatar







winch a écrit :



En partie faux…



Je m’explique :



Recevoir le mot de passe en clair à l’inscription ne prouve pas que le service stocke les mots de passe en clair, car au moment de l’inscription il ne lit pas le mot de passe à partir de la base de donnée mais à partir du formulaire d’inscription, où le mot de passe est en clair (puisque rentré à la main par le nouvel utilisateur)





La vraie preuve est lors d’une procédure “mot de passe oublié” : si vous recevez votre mot de passe en clair à ce moment là alors il y a un problème de sécurité.



Sur mon site lesParrains.fr certaines personnes flippent car mal informées, et ce n’est pas cet article qui va rassurer. Merci de corriger :)





Toujours est-il que perso je pense qu’un mot de passe ne devrait dans aucun cas être marqué en clair dans un quelconque email, même d’inscription.

SI quelqu’un accède à la boite mail de la personne, il lui suffirait alors d”un petit tour dans les emails pour accéder aux infos.

C’est un peu comme marquer le code de sa carte bleue dans son agenda, c’est tenter le diable <img data-src=" />


votre avatar







BlackYeLL a écrit :



Pour info, ce n’est pas parceque le mot de passe est envoyé par mail lors de l’inscription que ce n’est pas son SHA-1 + salt qui sont stockés en DB.







SHA-1 est un algo de hashage donc théoriquement non réversible. Par contre les possibilités de trouver des collisions sont plutôt grande, donc préférez dans tous les cas SHA-256 +salt (et encore vu les bases à dispo maintenant ce n’est pas non plus infaillible)









winch a écrit :



En partie faux…



Je m’explique :



Recevoir le mot de passe en clair à l’inscription ne prouve pas que le service stocke les mots de passe en clair, car au moment de l’inscription il ne lit pas le mot de passe à partir de la base de donnée mais à partir du formulaire d’inscription, où le mot de passe est en clair (puisque rentré à la main par le nouvel utilisateur)







même si cela ne passe pas par la BDD, il n’y a, à mon avis, rien de moins sûr qu’un mail. Aucune garantie de transfert sécurisé et de toute manière et ça crée aussi un endroit (la BAL utilisateur) où le password est stocké en clair. Donc à bannir aussi.


votre avatar



Le spécialiste de la vente de pièces auto OSCARO.

Mot de passe non chiffré et connection au compte en http.

[MàJ] Mots de passe envoyés par mail, une pratique encore assez répandue

  • Pour chaque mot de passe stocké en clair, un chaton adepte du SHA-1 se noie

  • Le mot de passe unique : une erreur à ne pas commettre

  • Le mot de passe : une procédure de sécurité devenue insuffisante ?

Fermer