Activision est dans la tourmente car les joueurs ont découvert que lorsque l’on demande au site Call of Duty Elite à pouvoir récupérer son mot de passe, ce dernier était envoyé en clair comme montré dans la capture d’écran ci-dessous :
Je vous rassure, ce n'est pas mon vrai mot de passe ;)
Contacté, Activision se défend de stocker ses mots de passe en clair et assure qu’ils sont cryptés et qu’ils vont désactiver cet envoi de mail pour une procédure plus sécurisée :
All Call of Duty Elite personal data, including passwords are saved and stored using encryption. Call of Duty Elite does not store any sensitive data in plain text. [...] We are in the process of altering our password recovery procedure so that passwords are no longer delivered in plain text
Autant l’intention est louable autant on peut se poser des questions sur la sécurité employée quand on connait la différence entre « cryptage » et « hachage ».
Dans un processus de cryptage (ou chiffrement si on veut respecter le français à la lettre), un algorithme tel que DES ou AES est utilisé pour transformer la chaîne en une autre chaîne. Pour schématiser, si le mot de passe fait 12 caractères, le mot de passe crypté fera 12 caractères aussi. L’inconvénient du cryptage est qu’il est justement prévu pour être décrypté et il est donc plus ou moins facile, en fonction de l’algorithme, de retrouver le mot de passe initial.
Dans un processus de hachage on utilise des algorithmes comme MD5 ou SHA1 pour calculer une empreinte pour la chaîne. Si votre mot de passe fait 12 caractères l’empreinte calculée pourra faire 8, 32 voire même plus de 100 caractères suivant l’algorithme utilisé. Il n’y pas de possibilité pour « dé-hacher » et il est impossible de retrouver la chaîne initiale. La seule manière de voir si un mot de passe est correct et de hacher celui reçu et de voir si l’empreinte des 2 mots est identique. Par contre, 2 mots de passes différents peuvent avoir la même empreinte. En effet, c’est la seule solution pour faire tenir des chaînes de 12 caractères sur une empreinte de 8 caractères.
Malheureusement il existe sur Internet de nombreux dictionnaires avec des mots et leurs empreintes déjà calculées pour permettre à des hackers de voir si le hachage qu’ils ont trouvé en piratant une base correspond à une chaîne connue. Pour contrer cela, les sites utilisent communément un « seed » qui consiste à concaténer au mot de passe initial une autre chaîne.
Si vous reprenez votre mot de passe de 12 caractères et lui appliquez un seed de 5 caractères vous aurez un mot de 17 caractères avec une empreinte toujours sur 8 caractères par exemple. Si le malandrin arrive à faire correspondre cette empreinte avec un mot connu il ne pourra toujours pas se connecter à votre compte puisque le site va appliquer le seed et du coup le calcul de la nouvelle empreinte sera différente.
Une fois ces concepts maîtrisés on ne peut qu’être inquiet de voir Activision continuer à employer le mot de cryptage et non de hachage car désactiver simplement l’envoi d’email va enlever une faiblesse du système mais ne vas pas forcément renforcer la sécurité. Pour être vraiment blindés ils devraient décrypter chaque mot de passe, le hacher grâce à un seed et sauvegarder cette nouvelle empreinte.
Sur Internet, les gens soucieux de la sécurité utilisent le hachage pour stocker vos mots de passe, les amateurs utilisent le cryptage. Il faudra voir dans quelle catégorie Activision voudra être classé. 4 millions d’utilisateurs, dont 1 million de payants, observent.
Le Journal du Geek
himura_kenshin
2 déc, 2011, 14:35 #1Ah ah ah !
Même pour les sites web de mes clients on utilise le hash, voire le hash + salt, alors que les infos sont loin d’être sensibles… alors oui c’est chiant on peut pas renvoyer comme ça le mot de passe. Mais au moins c’est fait pour que certains se cassent les dents un bon moment dessus en cas d’attaque.
Et là en gros ils disent qu’ils vont modifier leur système pour que les mots de passe ne soient plus envoyés en plain text, mais ils ne vont pas renforcer leur sécurité concernant leur stockage pour autant !!! Donc en cas d’intrusion, ça sera la fête du slip !!! Aberrant !!!
Léo
2 déc, 2011, 14:42 #2Faut voir le nombre de sites soit-disant « sérieux » qui utilisent le même genre de « sécurité »…
Enfin, utiliser des hashs de 8 caractères, ça ne se fait pas trop, éventuellement pour les mots de passe Unix sur de vieilles distributions. Mais pour le web on utilise au minimum du MD5, voir même de plus en plus du SHA1 ou supérieur, MD5 comportant une faille.
« Sur Internet, les gens soucieux de la sécurité utilisent le hachage pour stocker vos données personnelles »
Les mots de passe seulement, parce que le reste des données, en revanche, doit pouvoir être lu.
dio94
2 déc, 2011, 14:59 #3Ah les boulets
David
2 déc, 2011, 15:21 #4Ouais sauf que bon, le hash MD5 il saute en 10mn maintenant.
J’exagère à peine mais par exemple si le mdp est « soleil », ben on regarde dans une bibliothèque md5 et on connait le lien ;p
Franck | SkullyFM
2 déc, 2011, 15:28 #5@Léo: les 8 caractères c’était plus pour l’exemple ici. Pour les « données personnelles », tu as raison; j’ai modifié ce passage depuis. On est d’accord qu’il faut faire du hash pour les pass et du cryptage pour le reste.
@David: d’où l’intérêt du seed (ou salt). Si ton mot de passe est « soleil » et que le seed est « toto », la chaine sur laquelle on calcule le MD5 est « soleiltoto » ce qui donne 29515f6279879a433b770e41c64cf68b. Si jamais cette empreinte est disponible dans un dictionnaire elle ne pourra pas être utilisée car le site va y recoller le seed qui donnera un MD5 différent.
Mais on est d’accord, SHA1 est plus sécurisé que MD5 mais il vaut mieux se servir d’un seed quand même.
himura_kenshin
2 déc, 2011, 15:39 #6@David
D’où l’utilisation du salt qui rend caduque ces dictionnaires.
Exemple :
mon mot de passe est « soleil ». Le md5 de ce mot de passe est « 23206deb7eba65b3fbc80a2ffbc53c28″, ça se trouve effectivement en 2 secondes dans un annuaire.
Mais si en plus j’utilise en plus un salt de 8 caractères généré aléatoirement pour augmenter la sécurité, j’aurais par exemple « soleilazertyui ». Que je hash ensuite avec un MD5. Ce qui me donne « 6ac97dc25d5a2ab3175e22c1610065be » (qui ne correspond pas à « soleil » dans un dico md5). Auquel je concatène mon salt, pour pouvoir réeffectuer mes tests d’identification. En gros j’enregistre dans ma base de données cela : « 6ac97dc25d5a2ab3175e22c1610065be:azertyui »
Un autre utilisateur utilise « soleil », avec un autre salt aléatoire, j’obtiens « soleilqsdfghjk ». Une fois hashé, j’obtiens « b881a0386b0d7621418fb6b52d239c69″ (qui ne correspond toujours pas à « soleil » dans un dico md5. En concaténant le salt pour mes tests d’identifications, j’enregistre dans ma base de données « b881a0386b0d7621418fb6b52d239c69:qsdfghjk ».
Bref avec ces 2 exemples on peut voir que le mot « soleil » génère des hash totalement différents lorsqu’on lui ajoute un salt aléatoire. C’est un peu plus chiant à gérer c’est vrai, mais niveau sécurité, on monte d’un cran…
himura_kenshin
2 déc, 2011, 15:44 #7Grillé par Franck, en plus je me rends compte que mon pavé doit être du charabia pour le commun des mortels
Léo
2 déc, 2011, 15:46 #8Surtout qu’utiliser un dictionnaire donne la même chose, qu’on soit en MD5, SHA1 ou autre. C’est aussi pour ça qu’un bon mot de passe n’est pas un mot du dictionnaire.
Franck | SkullyFM
2 déc, 2011, 15:50 #9@himura_kenshin: ton exemple est bien plus complet… moi je n’ai pas abordé les salt aléatoires de peur de perdre des lecteurs en route
kikasstou
2 déc, 2011, 16:34 #10Bah au moins on connait tous la cible de la prochaine attaque de hacker. Il ne reste plus qu’à parier sur le nombre de jour qu’il faudra passé cette news.
bumbo
2 déc, 2011, 19:11 #11Je pense que beaucoup d’entre vous seraient surpris des données (coordonnées complètes, RIB, salaire, etc…) clients stockées en clair dans les bases de données de grosses entreprise et accessibles à beaucoup de personne travaillant dans les services informatique.
Bref, des données beaucoup plus sensibles que des mots de passe.
Fablastor
2 déc, 2011, 23:21 #12C’est pas faux ! *reponse du commun des mortels*. Ceci dit, débat très intéressant
Somm15
2 déc, 2011, 23:54 #13Je ne veux pas vexer l auteur de l article mais il est tout à fait possible de crypter une DB et de stocker les hasch des passwords dedans. Maintenant quand le mec qui fait la communication écrit, ben souvent il n y connaît pas autant en IT que les admins. Du coup il simplifie et dit qu il crypte ls pwd. Je vois rien de choquant à ça…
Franck | SkullyFM
3 déc, 2011, 01:42 #14@Somm15: je ne suis pas vexé, je ne suis juste pas sûr d’avoir compris ta réponse… Pour moi le gros problème d’Activision n’est pas d’envoyer le mot de passe en clair (même si c’est très grave) mais de savoir qu’ils ont le moyen de le retrouver. Une vraie politique de sécurité est quand on ne stoque que le hash et qu’on ne peut pas retrouver le mdp original. Or quand le lis le communiqué de presse ca dit « We are in the process of altering our password recovery procedure » mais ça ne mentionne pas qu’ils vont changer de procédure, juste éviter de renvoyer le pass en clair. Après c’est peut-être la faute du RP qui a simplifié au maximum le propos mais c’est pour ça que je laisse ma conclusion ouverte.
Maintenant, si j’ai mal interprété ton commentaire n’hésite pas à me le préciser et c’est avec plaisir que j’essayerais d’y répondre mieux.
marmoute
3 déc, 2011, 01:53 #15Petite listes de remarque à ne pas prendre mal:
* On soulignera que les mail transite en claire sur internet et qu’il est trivial d’en récupérer le contenu pour toute personne voyant passer le trafic. (internet est un ensemble de
* On utilise plutôt le terme salt que seed pour les mots de passe (on ajoute du sel pour changer le gout)
* Le problème du cryptage n’est pas vraiment sa robustesse on fait des choses de nos jours qui résiste très bien. Le problème est plutôt que si quelqu’un c’est introduit dans le système pour récupérer les fichiers de mots de passe, il n’aura pas forcement plus de mal à récupérer la clé stocké quelque part d’autre (voir dans la mémoire de la machine). N’importe quel coffre fort ne tient pas très longtemps fasse à un voleur qui en possède la clef.
* Les probabilités de collision entre deux mots de passe choisit par des humain sont trop faible pour être significative.
* En revanche les algorithmes de hashage les plus anciens ne sont plus sur. Cela fait au moins 5 ans qu’on génère des collisions md5 en moins d’une minute. SHA0 est également tombé, SH1 à pris du plomb dans l’aile même si il est encore assez solide. La solution générique de référence actuellement est sha256.
* Comme dit dans l’article, le salt complique fortement la génération de collision. Généralement plus le salt est long plus il sera compliqué de retrouver le mot de passe. Ceci ne dispense pas d’utiliser un algorithme de hashage robuste.
My 2 cents
Franck | SkullyFM
3 déc, 2011, 02:40 #16@marmoute: rien à rajouter, très bonne conclusion. J’ai essayé d’être le plus pédagogue possible sans faire un article pour être publié dans MISC et j’ai du coup du vulgariser pas mal de chose.
Quant à « seed » vs « salt » je dirais que ça dépend des écoles et de l’age du capitaine probablement
OtaK
3 déc, 2011, 03:01 #17Nice @marmoute.
Cependant petite précision, le cryptage est toujours très efficace, quand on voit qu’un algo comme le Blowfish qui a près de 15-20 ans maintenant et qui ne peut être que bruteforcé (dans sa version à 16 tours certes) au jour d’aujourd’hui… Bref.
Le hashage c’est bien gentil, mais faut utiliser que du sha256 si on veut paraître un tant soit peu sérieux.
somm15
3 déc, 2011, 10:33 #18@Franck | SkullyFM: Je me relis ce matin et je me rends compte que j’ai effectivement pas été très clair. Je voulais juste dire que à mon avis, ils n’ont juste pas été précis pcq ce ne sont pas les admins système ou architectes qui écrivent les communications. Je me dis juste qu’il est possible que la DB soit cryptée dans sont ensemble et que les hash des mots de passe soient stockés dedans.
Sinon, je ne connais pas le système mais le problème n’est pas tant que le mot de passe transite en clair. La majorité des sites vous envoient votre mot de passe ou lien de récupération en clair car il n’y a pas vraiment d’autre solution. Le problème est que le mot de passe reste valide dans le temps après avoir été transmis, contrairement au lien de récupération qui n’est valide qu’une fois et oblige (souvent) à change immédiatement le mot de passe.
Désolé pour le message d’hier
Franck | SkullyFM
3 déc, 2011, 19:42 #19@somm15: ok, je comprends mieux… effectivement le mec de la communication a pu simplifier le propos d’où ma conclusion qui ne condamne pas mais est attentiste.
Par contre je ne suis pas d’accord sur « La majorité des sites vous envoient votre mot de passe ou lien de récupération en clair car il n’y a pas vraiment d’autre solution ».
Envoyer le mot de passe en clair veut dire qu’il n’est que crypté et qu’on peut donc le décrypter (je passe sur le fait que les mails passent en clair sur le réseau et que donc le mot de passe est presque visible de tous). Envoyer un lien est déjà plus pro mais ne garanti pas que le site hash ses mot de passe, ca peut simplement être une procédure pour faire genre.
JohnWitt
5 déc, 2011, 10:04 #20En meme temps 90% des sites du net font pareil :\
dozhwal
5 déc, 2011, 10:49 #21merci pr ces infos sur l’interet du MD5 dans les mots de passe.
je n’avais pas compris l’interet ds les script PHP.
Jeux de Guerre
7 déc, 2011, 12:14 #22C’est grave quand même de stocker les mdp en clair, quand on voit que même des entreprises comme Sony peuvent se faire pirater..