Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Des chercheurs ont trouvé des failles dans le système de protection de mots de passe d'Ashley Madison
Qui fait appel à la fonction de hash bcrypt

Le , par Stéphane le calme

20PARTAGES

7  0 
Il y a quelques jours, Ashley Madison, le site canadien de rencontre en ligne pour les hommes mariés, a fait l’objet d’un piratage qui s’est soldé par la publication de la base de données des utilisateurs de la plateforme.

Les réguliers du service avaient été assurés que leurs mots de passe n’étaient pas conservés en texte clair mais étaient protégés par la fonction de hash bcrypt. Cette fonction est connue comme étant adaptative (c'est-à-dire que l'on peut augmenter le nombre d'itérations pour rendre le sel de l’algorithme plus lent) et donc très résistante aux attaques par recherche exhaustive malgré l’augmentation de la puissance de calcul. Dans ce cas particulier, les développeurs s’étaient servis d’un paramètre « cost » (coût souhaité de l’algorithme, il s’agit de la puissance de deux du nombre d’itération choisi) d’un facteur de 12.

Aussi, au lieu d’utiliser une attaque exhaustive dans son analyse des données rendue publique par les pirates, CynoSure Prime, un groupe qui a fait de sa spécialité le déchiffrement des mots de passe, a décidé de s’y prendre autrement. « Nous avons identifié deux fonctions qui ont suscité notre intérêt et, après une analyse plus approfondie, nous avons réalisé que nous pourrions exploiter ces fonctions comme catalyseurs dans l’accélération du déchiffrement des hashs de bcrypt. Par les deux méthodes non sécurisées de la génération de la variable $logkinkey dans deux fonctions différentes, nous avons été en mesure de gagner une énorme augmentation dans la vitesse de déchiffrement des mots de passe hashés par bcrypt », ont-ils assuré.

« Au lieu de nous attaquer directement aux hashs bcrypt, qui font la une en ce moment, nous avons pris une approche plus efficace en attaquant plutôt les tokens md5(lc($username).”::”.lc($pass)) et md5(lc($username).”::”.lc($pass).”:”.lc($email).”:73@^bhhs&#@&^@8@*$”). Ayant déchiffrés les tokens, nous n’avions plus qu’à les faire correspondre à leur équivalent en bcrypt », ont-ils avancé. Résultat ? En une dizaine de jours, ce sont plus de 10 millions de mots de passe qui ont pu être déchiffrés.

Cette décision par donc de deux observations. La première porte sur amlib_member_create.function.php et plus précisément sur la fonction amlib_member_create() aux lignes 69 et 70. La ligne 70 suggère que la variable $loginkey a été générée en convertissant en caractères minuscules les variables username et password dans md5 ( $loginkey = md5(strtolower($username).'::'.strtolower($password)) ).

La seconde observation porte sur AccountProvider.php et plus précisément sur la fonction generateLoginKey() aux lignes 78 et 79. « Cette fonction utilise une routine légèrement différente pour générer la variable $loginkey puisqu’elle incorpore l’utilisation des variables $username, $password et $email avec une constante salt de type string appelée $hash. Ensemble, ces variables ont été hachées dans l’algorithme MD5. Il apparaît que la fonction generateLoginKey() est invoquée lorsqu’un utilisateur modifie les attributs de son compte (username, password et email). La résultante est qu’un nouveau loginkey est généré pour ce compte. De ce que nous avons compris, il apparaît que bcrypt n’a pas toujours été utilisé pour hasher le mot de passe avant qu’il ne soit introduit dans la fonction generateLoginKey(). Ce qui signifie que cette méthode pourrait être utilisée pour récupérer les mots de passe de comptes qui avaient été modifiés avant cette modification du code », ont-ils expliqué.

Le groupe a fait savoir qu’il ne publierait pas les mots de passe qu’il a réussi à déchiffrer afin de protéger les utilisateurs. Cynosure Prime a émis l’hypothèse selon laquelle ce hashage insécurisé pourrait avoir été mis sur pied afin de s’assurer que les utilisateurs puissent se connecter au site rapidement.

Source : blog Cynosure Prime

Et vous ?

Qu'en pensez-vous ?

Forum Sécurité

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Aramiil
Nouveau membre du Club https://www.developpez.com
Le 13/09/2015 à 16:03
Bonjour,

Citation Envoyé par Neckara Voir le message

Non, ce que tu dis est faux.

Un mot de passe "fort", ne peut pas être retrouvé par force brute.
Non, ce que tu dis est faux. Fais le test par toi-même : sur un ordinateur de bureau (certes orienté jeu, en l'occurence un GE60 de MSI) j'ai mis un peu moins de 20 minutes à trouver un mot de passe "fort", ou plus exactement retrouver un mot de passe de 8 caractères incluant des majuscules, minuscules, chiffres et caractères spéciaux. La force d'un mot de passe n'y fait donc rien (sauf à choisir un mot de passe vraiment très long, et encore, on pourrait trouver des collisions... et la plupart des utilisateurs ne le retiendrons de toutes manières probablement pas).

Citation Envoyé par Neckara Voir le message

Le sel n'est pas là pour se protéger des attaques par force brute.
Oui, c'est précisément ce que je dis...

Citation Envoyé par Neckara Voir le message
???

Les rainbow table sont une attaque, pas un algorithme de hashage comme md5.
C'est aussi précisément ce que je dis (ne pas hésiter à lire le message avant de le citer par petit bouts en ne le comprenant pas...)

Citation Envoyé par Neckara Voir le message

Pas nécessairement. Avoir plusieurs sels d'origine différente peut être un plus si on considère qu'un des générateur génère des sels "faibles" ("peu aléatoire", ou qu'on ne lui fait pas vraiment confiance.
??? Le sel doit de toutes manières être stoqué en clair et à part du mot de passe pour pouvoir faire une comparaison de hash. Le seul intérêt du sel, c'est d'empêcher les attaques par rainbow table (puisque même si le mot de passe est dans la table, le mot de passe + sel n'y sera lui probablement pas). Pour plus d'informations : https://fr.wikipedia.org/wiki/Salage...cryptographie)

Citation Envoyé par Neckara Voir le message

Non.

Si tu utilises un algorithme de chiffrement, c'est que tu peux le déchiffrer. Quand bien même tu utiliserais une fonction de compression, tu pourrais retrouver un mot de passe différent de l'original qui sera accepté.

Il faut donc utiliser des fonctions de compression non-réversibles, une sorte de fonction de hash en somme. Mais dans ce cas là, on ne parle plus d'algorithme de chiffrement.
Et pourtant, le blowfish est bien un algorithme de chiffrement, et le bcrypt est bien une fonction de hash. L'utilisation d'un algorithme de chiffrement n'interdit pas d'obtenir, en l'intégrant dans un second algorithme, une fonction de hash (les deux liens de la phrase précédente te donnerons des informations plus complètes sur le sujet).

Citation Envoyé par Neckara Voir le message

Non, le plus important, ce n'est pas la durée d'un test mais de la complexité de l'attaque.

Si un test par brute force prend 10 fois plus de temps, il suffit d'avoir des machines 10 fois plus performantes ou 10 fois plus de machines à notre disposition, cela n'offre donc pas une réelle sécurité.

D'autant plus qu'on ne peut pas non plus rendre l'algorithme trop lent si on veut qu'il soit utilisable.
Sur ce point, c'est vrai. Mais ce n'est qu'une question de sémantique. En l'occurence, sur des attaques sur des mots de passe hashés, le but est d'obtenir une collision (c'est à dire un texte donnant le même hash que celui connu au départ). Si on excepte le cas de faiblesse propres à l'algorithme, qui sont rares et donc peuvent temporairement être ignorées, on aura à s'intéresser à deux cas de figures (en tous cas à l'heure actuelle) : tester toutes les possibilités (bruteforce) ou regarder une liste de hash déjà connus (rainbow tables). Le sel sert à éviter la seconde, on va donc s'intéresser à la première.

Dans le cas d'une attaque par brute force, le but recherché va être, comme tu le dis, d'augmenter la complexité de l'attaque. Ta première phrase est donc vraie (tout le reste est faux). En effet, lorsque la complexité augmente, il faut plus de ressources à un ordinateur (ou un cluster d'ordinateurs) pour obtenir une collision. Le résultat est donc qu'avec une quantité de ressources limitées, on est dans l'obligation de mobiliser plus de temps (ou d'assembler plus de ressources, donc plus de machines ou des machines plus puissantes) pour casser le hash et obtenir une collision.

Pour empêcher l'attaquant d'obtenir plus de ressources, les fonctions dites "adaptatives", telles que bcrypt, ont un facteur dit de "coût". Je cite wikipedia pour clarifier ce terme "on peut augmenter le nombre d'itérations pour le rendre plus lent. Ainsi il continue à être résistant aux attaques par recherche exhaustive malgré l'augmentation de la puissance de calcul.". En d'autres termes, pour exécuter l'algorithme une fois et donc tester une clef, il faut en fait exécuter des sous-éléments de l'algorithme un nombre plus grand de fois, ce qui implique plus de puissance de calcul, donc plus de temps si la puissance disponible à un instant T est limitée (et elle le sera toujours jusqu'à ce qu'on découvre un ordinateur de puissance infinie). Cela offre donc une réelle sécurité, contrairement à ce que tu sembles penser.

Enfin, l'algorithme ne sera jamais trop lent au sens où nous sommes ici sur des vitesses "informatiques" : un chiffrement par bcrypt, par exemple, prendra une ou deux secondes avec un paramètre de coût adapté. C'est négligeable pour un utilisateur normal qui ne le verra qu'une seule fois (au moment d'entrer son mot de passe), mais pour un attaquant, c'est différent. En imaginant que chaque test demande 1 seconde avec une capacité de calcul normale, que l'attaquant est en mesure (comme tu le suggère) de multiplier par 10 sa puissance de calcul, et que le mot de passe est composé de six lettres minuscules (et rien d'autre, donc nous sommes ici sur un mot de passe très faible), il lui faudra environ 15 milliard d'années pour pouvoir trouver une collision. En admettant une forte augmentation de puissance de calcul (mettons un facteur 1000 pour l'attaquant), nous restons face à plus de 150 millions d'années (et là, nous parlons d'un attaquant disposant de 1000 machines équivalentes à celles utilisées pour la génération du mot de passe). Pour donner un ordre d'idée plus précis, en admettant que la totalité du plus gros botnet recensé sur wikipedia, soit 30 millions de machines, cherche à casser un seul mot de passe, il faudrait plus de 5000 ans.

Citation Envoyé par Neckara Voir le message

Pas nécessairement.
En soit, c'est exact : si quelqu'un s'amuse à passer les millions d'années dont j'ai parlé juste avant pour générer tous les sels possibles en plus des mots de passe, la table obtenue serait utile. Mais comme c'est en pratique impossible, si, un sel utilisé dans un algorithme de hash adapté permet de rendre les rainbow table inutiles.

Citation Envoyé par Neckara Voir le message

Faux.

MD5 et SHA1 ne sont effectivement plus recommandée.
SHA2 l'est encore et on a désormais SHA3.

Et si, cela peut bien servir au stockage de mots de passes, en revanche, les algorithmes de chiffrement, que tu recommandes, eux ne servent pas à ça !
Faux. Comme précisé plus haut, je ne recommande pas d'algorithme de chiffrement mais un algorithme de hash.

Pour la comparaison sha2/sha3 vs bcrypt, je t'invite à te reporter à ce papier : http://codahale.com/how-to-safely-st...re-a-password/

Si tu tiens vraiment à utiliser une fonction sha* au lieu de blowfish, il faut se tourner vers PBKDF2 qui est d'ailleurs recommandé par le Department of Commerce pour ce genre d'usage et est techniquement plus sécurisé encore que bcrypt. Mais il fonctionne de la même manière, en particulier avec un facteur de coût qui le rends plus lent (et j'emploi le terme à dessin : oui, on cherche à ralentir l'algorithme).

Dans tous les cas, une fonction de hash seule (donc sha2/sha3/sha512) ne suffit pas. Un autre lien pour t'en convaincre : https://news.ycombinator.com/item?id=2004962 (au cas où, le ycombinator est l'incubateur d'où viennent dropbox, 4chan, 9gag, et pas mal d'autres).
11  2 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 15/12/2016 à 19:28
Donc un site qui promeut les affaires extra-conjugales, ment à ses utilisateurs, et vole leur argent sur la base de ses mensonges, non seulement n'amène pas à des peines de prison, mais en plus on lui demande de poursuivre en améliorant sa sécurité pour que ses méfaits puissent être mieux protégés ?

Je ne m'attendais pas à ce que les USA soient aussi sans gêne...
6  0 
Avatar de Aramiil
Nouveau membre du Club https://www.developpez.com
Le 14/09/2015 à 7:47
Je ne vais pas reciter les liens du précédent message. Je t'invite juste à consulter la quasi-totalité des papiers récents sur bcrypt / sha512, d'où qu'ils émanent (en particulier les agences de sécurité américaine qui en font régulièrement) qui disent tous l'exact contraire de tes messages, et que le fait de ralentir l'algorithme sert compliquer le bruteforce. Suis les liens que j'ai mis dans mon précédent message, apprends ce qu'est le bcrypt et en quoi il _utilise_ mais _n'est pas_ un algorithme de chiffrement. C'est toi qui mélange un peu tout, et cela discrédite nettement tes réponses de ne pas prendre le temps de lire celles des autres et de t'informer sur le sujet...
5  1 
Avatar de rawsrc
Modérateur https://www.developpez.com
Le 25/08/2016 à 11:35
Citation Envoyé par Stéphane le calme  Voir le message
[B][SIZE=4]De plus, comme l’avaient déjà indiqué The Impact Team, malgré la suppression par l’utilisateur, la désactivation d’un compte ou même l’inactivité d’un profil (c’est à dire un profil qui n’a pas été consulté par son propriétaire une longue période), Ashley Madison conservait en réalité les informations personnelles de ses clients

Les gendarmes de la vie privée canadien et australien ont donné une série de recommandations que Ruby a accepté de suivre comme par exemple fournir une option gratuite pour supprimer les informations des utilisateurs une fois qu’ils suppriment leurs profils (les utilisateurs devaient payer 15 dollars US).

Quand on vous dit que vos informations (privées ou pas) valent une fortune, c'est pas des blagues...

On croit rêver, allez une dernière petite louchette (15 $) juste pour bien te faire sentir l'énorme manque à gagner quand l'utilisateur décide de supprimer son compte et ses données (quand elles sont réellement effacées... et pas, comme trop souvent, juste archivées et soi-disant inaccessibles).
4  0 
Avatar de Jimmy_
Membre éprouvé https://www.developpez.com
Le 26/08/2016 à 15:26
Moi je ne comprend pas pourquoi ces gens utilisent leur véritable identité pour aller sur ce genre de site.

Bonjour je viens tromper ma femme : voici toutes mes coordonnées, vous pouvez la contacter et tout lui révéler ...


Cela montre que beaucoup de gens sont prêt à sacrifier leur vie privée en l'a vendant à un site internet et des inconnus.
Après effectivement ils sont mauvais en sécurité ils n'ont même pas protégé leurs données.

Désolé si je choque, mais pour l'adultère : un pseudonyme et une carte sim pré-payé, c'est quand même la base pour préserver sa vie.
4  0 
Avatar de bedane
Membre habitué https://www.developpez.com
Le 12/09/2015 à 11:10
Parce que un hash bcrypt, ça prend du temps, et c'est d'ailleurs fait pour ça. (long -> dur à brute force)

Les concepteurs du système se sont tirés une balle dans le pied en stockant des md5 du mot de passe concaténé avec d'autres données apparemment, bcrypt reste une manière sécurisée (paranoïaque ?) de stocker les mots de passe.
3  0 
Avatar de TheLastShot
Membre extrêmement actif https://www.developpez.com
Le 25/08/2016 à 16:32
@NSKis, le problème c'est que pour beaucoup ils s'en rendent compte... Mais il s'en fiche totalement. La notion de vie privée (et pis encore, de respect de la vie privée) est quelque chose qui se perd de plus en plus depuis quelques années. Sous prétexte qu'on a des outils qui permettent de données des informations sur soi, certains se sentent "obligé" de tout dire sur eux et sur les autres... Il suffit de voir comment ont pulluler les émissions de télé-rézlité, le succès des tabloids, la prolifération de photos ou vidéos à caractère privé sur youtube (bien sûr au détriment de celui qui est photographié ou filmé, et sans réfléchir à l'impact que ça peut avoir...)
Alors après tout, si ces personnes sont prêt à tout déballer, pourquoi les services se gèneraient pour exploiter leurs données ?
(bien sûr je ne cautionne absolument pas ce système, mais j'ai trouvé un moyen très simple de le contrer: il n'y a que très peu d'information sur moi sur internet, et absolument rien de privé !)
3  0 
Avatar de Jarodd
Membre expérimenté https://www.developpez.com
Le 28/08/2016 à 15:57
Citation Envoyé par rawsrc Voir le message
Quand on vous dit que vos informations (privées ou pas) valent une fortune, c'est pas des blagues...

On croit rêver, allez une dernière petite louchette (15 $) juste pour bien te faire sentir l'énorme manque à gagner quand l'utilisateur décide de supprimer son compte et ses données (quand elles sont réellement effacées... et pas, comme trop souvent, juste archivées et soi-disant inaccessibles).
Plus proche de nous, la RATP fait payer 5€ son Pass Navigo Découverte pour anonymiser les données de transport.
(ouvrir le menu "Sur quel passe charger votre forfait ?"
3  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 29/08/2016 à 16:00
Citation Envoyé par Songbird_ Voir le message
Mais malgré le manque de vigilance d'une grande majorité des utilisateurs, ce que je trouve encore plus triste, c'est que tant que les CGU stipulent qu'ils abusent leurs utilisateurs: c'est légitime.
Faux.
Les CNIL de toute l'Europe tapent sur les clauses abusives.
Ce n'est pas parce que c'est écrit dans les CGU que c'est légal.
Le hic est que la force de frappe des CNIL est juste risibles donc entre le moment où la clause abusive est inscrite et exploitée et le moment où elle est retirée, il peut se passer du temps, beaucoup de temps.
Bref, le mal est déjà fait.
3  0 
Avatar de Jarodd
Membre expérimenté https://www.developpez.com
Le 30/08/2016 à 10:13
Citation Envoyé par Songbird_ Voir le message
Bonjour,

Oui, plutôt d'accord pour le coup.

Mais malgré le manque de vigilance d'une grande majorité des utilisateurs, ce que je trouve encore plus triste, c'est que tant que les CGU stipulent qu'ils abusent leurs utilisateurs: c'est légitime.

Il suffirait que les CGU obligent l'utilisateur à fournir un rein à l'entreprise pour que ça puisse passer sans soucis.

J'extrapole, mais je trouve ça vraiment dangereux.
Tu n'es pas si loin de la vérité

3  0