Twitter appelle des centaines de millions de personnes à changer leur mot de passe., Réactions à la publication du 04/05/2018

[Lionel]

Twitter a demandé à des centaines de millions de clients de changer leur mot de passe.

A priori ils n'ont pas été dérobés mais suite à un bug ils ont pu être stockés en clair sur des serveurs.

Lien vers le billet original

[hellomorld]

Un bug qui déchiffre une base et la sauvegarde ? Gros bug

En fait le bug est le suivant :

En raison d'un bug, les mots de passe ont été enregistrés dans un journal interne avant le processus de hachage.

Plutôt que bug, je dirai que c'est un "oubli" d'un développeur mais qu'un tel journal soit passé inaperçu depuis son existence laisse rêveur !

Ce message a été modifié par hellomorld - 4 May 2018, 07:54.

[Pat94]

Je vais me répéter mais les réseaux sociaux c'est le

[yponomeute]

Plutôt que bug, je dirai que c'est un "oubli" d'un développeur mais qu'un tel journal soit passé inaperçu depuis son existence laisse rêveur !

Tu semble connaitre la date d'apparition de ce bug, tu peux partager ta source ? Je n'ai rien trouvé à ce sujet pour ma part.

[DarkAngel5666]

C'est plutôt clean de la part de Twitter de prévenir les gens potentiellement touchés AVANT un leak plutôt qu'après , et ce même si ça va forcément attirer l'attention sur eux.

[hellomorld]

Plutôt que bug, je dirai que c'est un "oubli" d'un développeur mais qu'un tel journal soit passé inaperçu depuis son existence laisse rêveur !

Tu semble connaitre la date d'apparition de ce bug, tu peux partager ta source ? Je n'ai rien trouvé à ce sujet pour ma part.

Non, je ne connais pas la date d'apparition de ce bug, mais vu que tous les clients semblent concernés ont pu penser que c'est depuis la création du réseau !

[SartMatt]

Non, je ne connais pas la date d'apparition de ce bug, mais vu que tous les clients semblent concernés ont pu penser que c'est depuis la création du réseau !

Ben non, pas forcément. Parce que le mot de passe il est transmis aussi quand on se connecte. Ça peut être à ce moment qu'il est mis dans un fichier log.
Donc ce ne sont pas forcément que les comptes créés après apparition du bug qui sont concernés, mais peut-être tous ceux qui se sont connectés depuis l'apparition du bug.

Je vais me répéter mais les réseaux sociaux c'est le

C'est quoi le rapport avec les réseaux sociaux là ? Il s'agit d'un problème strictement technique, qui n'a rien à voir avec la finalité du produit. Ça pourrait aussi arriver avec un forum, le service en ligne d'une banque, un webmail, un OS... Bref, tout ce qui manipule des mots de passe et des fichiers log.

[_Panta]

Je vais me répéter mais les réseaux sociaux c'est le

Pourquoi ?

[Sgt.Pepper]

Je vais me répéter mais les réseaux sociaux c'est le

Pourquoi ?

Il dit ça pour se socialiser.

[Eagle Kiss]

Je vais me répéter mais les réseaux sociaux c'est le

Le réseau social c'est comme la télé, c'est un outil. On peut ne pas en avoir, l'utiliser intelligemment ou en faire une vraie merde

[Pascal Funk]

Voila ,c'est un outil.....A utiliser a bon escient.

[Pat94]

Je vais me répéter mais les réseaux sociaux c'est le

Pourquoi ?

Je sais , je suis un asocial croisé avec un vieux dinosaure , mais ayant passé une grosse partie de ma carrière à concevoir, réaliser et mettre au point des Data-centers importants, je connais un peut les cibles de certains de leurs clients utilisants ces surfaces pour l'héberger de leurs serveurs.

De base les réseaux sociaux ont été créer pour rapprochent familles et citoyens, ils nourrissent la curiosité et aident (en théorie) à la défense de causes importantes .

Mais les dommages collatéraux des Facebook, Instagram, Twitter,  ou Snapchat suscitent de plus en plus de questions et critiques, sur deux points en particulier :

D'abord, ils rendent leurs utilisateurs accros, en accaparant leur attention par des microstimulations répétées et frustrantes.

Ensuite, dans ce contexte d'incitations frénétiques, ils colportent des fake news (fausses informations) malveillantes , dont nous commençons seulement à découvrir le vertigineux pouvoir de nuisance .

[iAPX]

Un bug qui déchiffre une base et la sauvegarde ? Gros bug

En fait le bug est le suivant :

En raison d'un bug, les mots de passe ont été enregistrés dans un journal interne avant le processus de hachage.

Plutôt que bug, je dirai que c'est un "oubli" d'un développeur mais qu'un tel journal soit passé inaperçu depuis son existence laisse rêveur !

Surtout qu'une "bug" similaire est arrivée à GitHub ces dernières semaines.

J'ai été choqué que tweeter utilise bcrypt() et non scrypt().

[fcoull]

Un bug qui déchiffre une base et la sauvegarde ? Gros bug

En fait le bug est le suivant :

En raison d'un bug, les mots de passe ont été enregistrés dans un journal interne avant le processus de hachage.

Plutôt que bug, je dirai que c'est un "oubli" d'un développeur mais qu'un tel journal soit passé inaperçu depuis son existence laisse rêveur !

Surtout qu'une "bug" similaire est arrivée à GitHub ces dernières semaines.

J'ai été choqué que tweeter utilise bcrypt() et non scrypt().

Il y a aucune raison a choisir scrypt() sur bcrypt() hormis de par sa conception et par sa lenteur le scrypt() est moins vunerlable au bruteforce.. Mais rien n'empeche de rajouter des derivation supplementaires a bcrypt.

[iAPX]

Un bug qui déchiffre une base et la sauvegarde ? Gros bug

En fait le bug est le suivant :

En raison d'un bug, les mots de passe ont été enregistrés dans un journal interne avant le processus de hachage.

Plutôt que bug, je dirai que c'est un "oubli" d'un développeur mais qu'un tel journal soit passé inaperçu depuis son existence laisse rêveur !

Surtout qu'une "bug" similaire est arrivée à GitHub ces dernières semaines.

J'ai été choqué que tweeter utilise bcrypt() et non scrypt().

Il y a aucune raison a choisir scrypt() sur bcrypt() hormis de par sa conception et par sa lenteur le scrypt() est moins vunerlable au bruteforce.. Mais rien n'empeche de rajouter des derivation supplementaires a bcrypt.

Le bcrypt est massivement parallelisable, on parle de dizaine de milliers de threads sur une GPU, le scrypt ne l'est pas (ou très peu) on parle plutot d'une dizaine de thread par GPU car pouvant utiliser une grosse quantité de mémoire (1Go par thread par exemple sur un serveur d'authentification), sans être plus lent sur une CPU si on a un bon ratio RAM/threads: il est mille fois plus lent à attaquer avec des GPU. CQFD

Ce message a été modifié par iAPX - 6 May 2018, 12:25.

[castor74]

Un bug qui déchiffre une base et la sauvegarde ? Gros bug

En fait le bug est le suivant :

En raison d'un bug, les mots de passe ont été enregistrés dans un journal interne avant le processus de hachage.

Plutôt que bug, je dirai que c'est un "oubli" d'un développeur mais qu'un tel journal soit passé inaperçu depuis son existence laisse rêveur !

Surtout qu'une "bug" similaire est arrivée à GitHub ces dernières semaines.

J'ai été choqué que tweeter utilise bcrypt() et non scrypt().

Il y a aucune raison a choisir scrypt() sur bcrypt() hormis de par sa conception et par sa lenteur le scrypt() est moins vunerlable au bruteforce.. Mais rien n'empeche de rajouter des derivation supplementaires a bcrypt.

Le bcrypt est massivement parallelisable, on parle de dizaine de milliers de threads sur une GPU, le scrypt ne l'est pas (ou très peu) on parle plutot d'une dizaine de thread par GPU car pouvant utiliser une grosse quantité de mémoire (1Go par thread par exemple sur un serveur d'authentification), sans être plus lent sur une CPU si on a un bon ratio RAM/threads: il est mille fois plus lent à attaquer avec des GPU. CQFD

Et en langage classique (disons Jules Verne, pour faire simple), ça donne quoi?

[iAPX]

Un bug qui déchiffre une base et la sauvegarde ? Gros bug

En fait le bug est le suivant :

En raison d'un bug, les mots de passe ont été enregistrés dans un journal interne avant le processus de hachage.

Plutôt que bug, je dirai que c'est un "oubli" d'un développeur mais qu'un tel journal soit passé inaperçu depuis son existence laisse rêveur !

Surtout qu'une "bug" similaire est arrivée à GitHub ces dernières semaines.

J'ai été choqué que tweeter utilise bcrypt() et non scrypt().

Il y a aucune raison a choisir scrypt() sur bcrypt() hormis de par sa conception et par sa lenteur le scrypt() est moins vunerlable au bruteforce.. Mais rien n'empeche de rajouter des derivation supplementaires a bcrypt.

Le bcrypt est massivement parallelisable, on parle de dizaine de milliers de threads sur une GPU, le scrypt ne l'est pas (ou très peu) on parle plutot d'une dizaine de thread par GPU car pouvant utiliser une grosse quantité de mémoire (1Go par thread par exemple sur un serveur d'authentification), sans être plus lent sur une CPU si on a un bon ratio RAM/threads: il est mille fois plus lent à attaquer avec des GPU. CQFD

Et en langage classique (disons Jules Verne, pour faire simple), ça donne quoi?

TL;DR bcrypt comme PBKDF2 a été conçu pour la NSA, scrypt a été conçu contre la NSA

Que scrypt ne prends pas plus de temps que bcrypt pour créer ou vérifier une authentification sur un serveur, il prend beaucoup plus de mémoire en revanche, et il protège contre les attaques via des GPU ou des FPGA voire ASIC, il a été spécifiquement créé pour empêcher les gentilles organisations à 3 lettres et les groupes de hacker organisés d'attaquer facilement les mots-de-passe par force brute, contrairement à bcrypt qui a plutôt été conçu pour leur simplifier la vie en donnant l'impression de sécuriser

Dit autrement, scrypt augmente sérieusement le coût de cassage de mot-de-passe, comme dans cet article de 2012 préconisant de ne pas utiliser bcrypt, mais scrypt en lieu et place, dont j'ai extrait le tableau récapitulatif de coût d'attaque et en sachant qu'entre-temps le coût a largement diminué pour bcrypt, mais moins pour scrypt, creusant encore plus l'écart entre les deux, probablement un ratio actuel de 100X.


Ce message a été modifié par iAPX - 6 May 2018, 13:38.

[SartMatt]

Le bcrypt est massivement parallelisable, on parle de dizaine de milliers de threads sur une GPU, le scrypt ne l'est pas (ou très peu) on parle plutot d'une dizaine de thread par GPU car pouvant utiliser une grosse quantité de mémoire (1Go par thread par exemple sur un serveur d'authentification), sans être plus lent sur une CPU si on a un bon ratio RAM/threads: il est mille fois plus lent à attaquer avec des GPU. CQFD

Mais quand on voit le hashrate de GPU sur bcrypt, c'est déjà bien suffisant...

Voilà par exemple un bench réalisé sur 8 GTX 1080 : https://gist.github.com/epixoip/a83d38f412b...9bbef804a270c40

À peine 105 kH/s avec un bcrypt à 5 itérations. À ce train là, même avec 100 fois plus de GPU, il faut jusqu'à 6 mois pour casser le hash (et comme le bcrypt est salé, on en casse un à la fois...) d'un bête mot de passe alphanumérique de 8 caractères. 800 GPU pendant 6 mois pour casser un pauvre mot de passe Twitter, c'est beaucoup trop de moyens pour que ça soit viable... Rien qu'en budget électricité, on doit être autour des 100 000€. Et plusieurs fois ça en budget matériel. Donc c'est largement suffisant pour des mots de passe Twitter (on parle pas d'un mot de passe protégeant des données chiffrées de très haute valeur là...).

Et encore, y a des chances que Twitter utilise plus de 5 itérations...

Ce message a été modifié par SartMatt - 6 May 2018, 14:13.

[iAPX]

Le bcrypt est massivement parallelisable, on parle de dizaine de milliers de threads sur une GPU, le scrypt ne l'est pas (ou très peu) on parle plutot d'une dizaine de thread par GPU car pouvant utiliser une grosse quantité de mémoire (1Go par thread par exemple sur un serveur d'authentification), sans être plus lent sur une CPU si on a un bon ratio RAM/threads: il est mille fois plus lent à attaquer avec des GPU. CQFD

Mais quand on voit le hashrate de GPU sur bcrypt, c'est déjà bien suffisant...

Voilà par exemple un bench réalisé sur 8 GTX 1080 : https://gist.github.com/epixoip/a83d38f412b...9bbef804a270c40

À peine 105 kH/s avec un bcrypt à 5 itérations. À ce train là, même avec 100 fois plus de GPU, il faut jusqu'à 6 mois pour casser le hash (et comme le bcrypt est salé, on n'en casse un à la fois...) d'un bête mot de passe alphanumérique de 8 caractères. 800 GPU pendant 6 mois pour casser un pauvre mot de passe Twitter, c'est beaucoup trop de moyens pour que ça soit viable... Rien qu'en budget électricité, on doit être autour des 100 000€. Et plusieurs fois ça en budget matériel. Donc c'est largement suffisant pour des mots de passe Twitter (on parle pas d'un mot de passe protégeant des données chiffrées de très haute valeur là...).

Et encore, y a des chances que Twitter utilise plus de 5 itérations...

Pourquoi donc vouloir casser un mot-de-passe d'un compte spécifique?
Ou vouloir casser absolument tous les comptes?

Avec 105 KH/s, tu peux casser 30% des comptes à raison de d'une vingtaine de compte par seconde, 72 000 comptes par heure, ça suffit largement pour faire plein de choses intéressantes

PS: il reste aussi un problème de manque d'études sur bcrypt qui pourrait se révéler avoir des problèmes un jour ou l'autre et être attaquable bien plus rapidement qu'on ne le pense.

Ce message a été modifié par iAPX - 6 May 2018, 13:56.

[SartMatt]

Avec 105 KH/s, tu peux casser 30% des comptes à raison de d'une vingtaine de compte par seconde, 72 000 comptes par heure, ça suffit largement pour faire plein de choses intéressantes

Euh, je te rappelle qu'il y a normalement un sel différent pour chaque compte, à moins qu'ils aient fait leur propre implémentation de bcrypt (les implémentations "standard" génèrent un sel pour chaque création de hash).

Donc non, si tu lances un bruteforce, tu peux pas attaquer plusieurs comptes à la fois. Parce que le sel doit faire partie de tes paramètres d'entrée.

Ce message a été modifié par SartMatt - 6 May 2018, 14:08.

[iAPX]

Avec 105 KH/s, tu peux casser 30% des comptes à raison de d'une vingtaine de compte par seconde, 72 000 comptes par heure, ça suffit largement pour faire plein de choses intéressantes

Euh, je te rappelle qu'il y a normalement un sel différent pour chaque compte.

Donc non, si tu lances un bruteforce, tu peux pas attaquer plusieurs comptes à la fois. Parce que le sel doit faire partie de tes paramètres d'entrée.

Je sais faire ce genre de choses depuis longtemps, et je parle bien de craquer autour de 30% des comptes à raison d'une vingtaine par seconde, avec 105Kh/s de débit.

C'est l'intérêt d'une attaque sur tous les comptes, mot-de-passe par mot-de-passe (en commençant par les plus probables évidemment), c'est que tu ne récupèreras pas tout, mais tu vas maximiser ton ratio de passe cassé/temps au début avec un très bon taux de retour qui va évidemment diminuer à chaque nouveau mot-de-passe essayé, mais sur une base installé aussi grande que celle de Twitter, tu vas avoir accès à des milliers de comptes très rapidement.

Et évidemment tu dois recalculer le hash bcrypt pour chaque compte, mais c'est pas grave, surtout que comme tu l'indiques, ça se parallélise parfaitement: ça a été conçu pour être attaquable par de grandes fermes de calculs (maintenant probablement en FPGA voir ASIC chez nos amis à 3 lettres), contrairement à scrypt qui lui est conçu pour ne pas être massivement parallélisable, donc on peut oublier les GPU, FPGA ou ASIC, sauf à les équiper de mémoire en conséquence ce qui est totalement illusoire (compter entre 1To et 30To pour une GPU puissante, suivant l'empreinte mémoire choisie!)

Ce message a été modifié par iAPX - 6 May 2018, 14:18.

[SartMatt]

C'est l'intérêt d'une attaque sur tous les comptes, mot-de-passe par mot-de-passe (en commençant par les plus probables évidemment), c'est que tu ne récupèreras pas tout, mais tu vas maximiser ton ratio de passe cassé/temps au début avec un très bon taux de retour qui va évidemment diminuer à chaque nouveau mot-de-passe essayé, mais sur une base installé aussi grande que celle de Twitter, tu vas avoir accès à des milliers de comptes très rapidement.

À 100 kH/s, tu vas pas pouvoir en tester des masses des mots de passe les plus probables sur tous les comptes... Il y a plus de 400 millions de comptes sur Twitter, donc pour tester UN mot de passe sur tous les comptes à 100 kH/s, tu en as pour plus d'une heure... En six mois tu auras testé les 4000 mots de passe les plus courants, au mieux.

Alors oui, tu auras sans doute cassé le mot de passe d'une palanquée de comptes. Mais que des comptes avec un mot de passe faible. Donc probablement pas de comptes suffisamment intéressants pour avoir un retour sur investissement.

Et encore, ça c'est en supposant que Twitter ne se rende pas compte dans un délai raisonnable que tu as réussi à aspirer tous les hash...

D'ailleurs, l'article que tu cites en référence le dit lui même dès le début : si tu utilises bcrypt sur un projet existant, c'est probablement suffisant, mais si tu lances un nouveau projet, alors faut envisager d'utiliser autre chose.

Ce message a été modifié par SartMatt - 6 May 2018, 14:23.

[iAPX]

C'est l'intérêt d'une attaque sur tous les comptes, mot-de-passe par mot-de-passe (en commençant par les plus probables évidemment), c'est que tu ne récupèreras pas tout, mais tu vas maximiser ton ratio de passe cassé/temps au début avec un très bon taux de retour qui va évidemment diminuer à chaque nouveau mot-de-passe essayé, mais sur une base installé aussi grande que celle de Twitter, tu vas avoir accès à des milliers de comptes très rapidement.

À 100 kH/s, tu vas pas pouvoir en tester des masses des mots de passe les plus probables sur tous les comptes... Il y a plus de 400 millions de comptes sur Twitter, donc pour tester UN mot de passe sur tous les comptes à 100 kH/s, tu en as pour plus d'une heure... En six mois tu auras testé les 4000 mots de passe les plus courants, au mieux.

Alors oui, tu auras sans doute cassé le mot de passe d'une palanquée de comptes. Mais que des comptes avec un mot de passe faible. Donc probablement pas de comptes suffisamment intéressants pour avoir un retour sur investissement.

Et encore, ça c'est en supposant que Twitter ne se rende pas compte dans un délai raisonnable que tu as réussi à aspirer tous les hash...

C'est au contraire les plus intéressants, ceux avec des mots-de-passe faible

Tu peux parier qu'un grand nombre auront le même mot-de-passe ou similaire (dérivé et on sait créé des dérivés automatiquement pour faire des attaques sur ce type de schéma très courant), tu as accès à leur adresse email et une fois le compte email piraté tu vas pouvoir pirater leurs comptes ailleurs les doigts dans le nez et automatiquement.
Si le compte email a un mot-de-passe très différent, ça n'empêche pas d'essayer le mot-de-passe trouvé (ou un dérivé) sur les autres sites en ligne habituels, là aussi les chances sont grande d'avoir accès à d'autres comptes un peu partout...

PS: l'article est de 2012, il y a 6 ans, maintenant il faut prendre Argon2 ou scrypt, les deux ayant une empreinte mémoire paramétrable les rendant inattaquables pratiquement dans une ferme de GPU/FPGA/ASIC!
Par exemple la NSA doit être près d'un millliard de hash bcrypt par seconde (1 000 000 000 Kh/s par 105 Kh/s) en utilisant des ASIC dédié et c'est pour ce genre de capacité que bcrypt a été créé, leur laisser la possibilité de casser la plupart des mots-de-passe créés par des humains très rapidement (surtout qu'ils ciblent leurs attaques) en nous donnant l'impression d'être protégé (ce qui est le cas face à de petits joueurs). scrypt est fait pour nous protéger des attaques effectuées par la NSA.

Ce message a été modifié par iAPX - 6 May 2018, 15:20.

[SartMatt]

Tu peux parier qu'un grand nombre auront le même mot-de-passe ou similaire (dérivé et on sait créé des dérivés automatiquement pour faire des attaques sur ce type de schéma très courant), tu as accès à leur adresse email et une fois le compte email piraté tu vas pouvoir pirater leurs comptes ailleurs les doigts dans le nez et automatiquement.
Si le compte email a un mot-de-passe très différent, ça n'empêche pas d'essayer le mot-de-passe trouvé (ou un dérivé) sur les autres sites en ligne habituels, là aussi les chances sont grande d'avoir accès à d'autres comptes un peu partout...

Oui. Sauf que ça restera des accès de faible valeur par rapport aux moyens mis en œuvre pour les trouver.

Parce que le compte mail et le Twitter de Tartempion, ça ne vaut rien. Des accès à des comptes mail, ça se vend autour de 1 dollar les 1000 comptes...

Les 105 kh/s, ils coûtent rien qu'en électricité 25cts/h, au moins le double en comptant l'amortissement du matériel. Et je suis pas convaincu qu'avec ça tu sortes une moyenne de 2000 comptes mail par heure pendant 6 mois (parce que pour amortir le matériel, c'est plusieurs millions de comptes mails qu'il va falloir trouver)... Et ce, à supposer déjà que tu as accès aux hash. Ce qui va déjà nécessiter d'investir pas mal de temps et de ressources pour pénétrer les serveurs de Twitter...

Au final, je suis pas convaincu que pour celui qui a les ressources matériel ça soit vraiment rentable de faire ça plutôt que du minage de cryptomonnaies par exemple...

[iAPX]

Tu peux parier qu'un grand nombre auront le même mot-de-passe ou similaire (dérivé et on sait créé des dérivés automatiquement pour faire des attaques sur ce type de schéma très courant), tu as accès à leur adresse email et une fois le compte email piraté tu vas pouvoir pirater leurs comptes ailleurs les doigts dans le nez et automatiquement.
Si le compte email a un mot-de-passe très différent, ça n'empêche pas d'essayer le mot-de-passe trouvé (ou un dérivé) sur les autres sites en ligne habituels, là aussi les chances sont grande d'avoir accès à d'autres comptes un peu partout...

Oui. Sauf que ça restera des accès de faible valeur par rapport aux moyens mis en œuvre pour les trouver.

Parce que le compte mail et le Twitter de Tartempion, ça ne vaut rien. Des accès à des comptes mail, ça se vend autour de 1 dollar les 1000 comptes...

Les 105 kh/s, ils coûtent rien qu'en électricité 25cts/h, au moins le double en comptant l'amortissement du matériel. Et je suis pas convaincu qu'avec ça tu sortes une moyenne de 2000 comptes mail par heure pendant 6 mois (parce que pour amortir le matériel, c'est plusieurs millions de comptes mails qu'il va falloir trouver)... Et ce, à supposer déjà que tu as accès aux hash. Ce qui va déjà nécessiter d'investir pas mal de temps et de ressources pour pénétrer les serveurs de Twitter...

Au final, je suis pas convaincu que pour celui qui a les ressources matériel ça soit vraiment rentable de faire ça plutôt que du minage de cryptomonnaies par exemple...

Content que tu ai compris l'intérêt de scrypt par rapport à bcrypt: justement augmenter le coût de l'attaque pour rendre celle-ci moins rentable

D'où mon premier tableau, daté et ne correspondant plus du tout aux coûts actuels, qui a drastiquement diminué pour bcrypt, mais moins diminué pour scrypt, rendant celui-ci probablement 100X plus cher pour les mêmes résultats. Et qui doit faire vraiment chier la NSA, pour ça que le NIST ne le recommande pas et recommande PBKDF2 et on peut voir où il se situe dans le tableau. CQFD



Les gentils cypher inventés par la NSA, choisis par elle-même, recommandés par le NIST, que tout le monde utilise obligeamment ne sont choisi ou conçu que pour apporter un peu de sécurité en laissant des possibilités d'attaques, mathématique ou par force-brute sur ceux-ci, le SHA (renommé SHA-0) étant un exemple parfait, et le SHA-1 est maintenant bien cassé car on sait maintenant modifier des parts de documents (bit toggling) en gardant la même signature SHA-1.

Ce message a été modifié par iAPX - 6 May 2018, 15:28.

[SartMatt]

Content que tu ai compris l'intérêt de scrypt par rapport à bcrypt: justement augmenter le coût de l'attaque pour rendre celle-ci moins rentable

J'avais bien compris ça dès le début hein... Mais quand elle n'est déjà pas rentable, ça n'apporte donc rien.

[iAPX]

Content que tu ai compris l'intérêt de scrypt par rapport à bcrypt: justement augmenter le coût de l'attaque pour rendre celle-ci moins rentable

J'avais bien compris ça dès le début hein... Mais quand elle n'est déjà pas rentable, ça n'apporte donc rien.

$4000 USD de matos (8xGPU + le reste et je vois grand), en moyenne $1.66 USD par compte piraté (des chiffres ici), équilibre vers 2400 comptes piratés donc pour Twitter.

Je pense que l'équilibre sera atteint en moins d'une heure une dizaine de minutes. C'est pas du Bitcoin, là c'est rentable tout de suite!
Et je ne compte pas les comptes piratés par ricochet surtout si tu prends le controle du compte email: là ton bousin tu l'amorti en moins d'une minute (la moyenne est en-dessous de $10 USD soit 400 passes à casser) !

Et c'est pour ça que le NIST aux États-Unis préconise PBKDF2 encore plus économique à casser (surtout pour la NSA) plutôt que Argon2 ou scrypt, qui ont tous les deux été conçu contre ce schéma et sa très belle rentabilité.

PS: dans la pratique Amazon AWS est ton ami, pas besoin de s'emmerder à monter un gros PC, d'investir, prends juste deux heures sur une eg1.2xlarge (oui ça va te coûter près de $1 USD, mais faut pas être cheap) et tu peux aussi en prendre une poignée et les laisser tourner tant qu'il te rapportent plus qu'ils ne coutent par heure (ça va durer longtemps!).
Retour sur investissement dès la première seconde: c'est pas du BitCoin ça!

Ce message a été modifié par iAPX - 6 May 2018, 15:47.

[SartMatt]

$4000 USD de matos (8xGPU + le reste et je vois grand)

Tu vois grand ? LOL. Pour ce prix là, tu as même pas les 8 GTX 1080... La moins chère sur Amazon.com est à 580$... Mais avec 140$ de frais de port.

en moyenne $1.66 USD par compte piraté (des chiffres ici)

Ces chiffres me paraissent totalement délirant par rapport à ce qu'on peut trouver ailleurs... Le must étant le compte Netflix à 8$32... Comment dire... c'est quasiment le prix d'un compte Netflix officiel

équilibre vers 2400 comptes piratés donc pour Twitter.

À condition d'avoir mis la main sur leur base de hash (je rappelle ça à chaque fois, mais toi parles comme si la base avait déjà fuité... ce n'est pas la cas). Et qu'ils n'utilisent qu'un coût de 5 dans leur configuration de bcrypt, ce qui, comme je l'ai dit plus haut, me parait hautement improbable...
Si par exemple ils utilisent un coût de 10 (ce qui est par exemple la valeur par défaut utilisé par PHP), tu divises ton rendement par 32...

Ce message a été modifié par SartMatt - 6 May 2018, 15:49.

[iAPX]

...

équilibre vers 2400 comptes piratés donc pour Twitter.

À condition d'avoir mis la main sur leur base de hash (je rappelle ça à chaque fois, mais toi tu sembles faire comme si la base avait déjà fuité... ce n'est pas la cas. Et qu'ils n'utilisent qu'un coût de 5 dans leur configuration de bcrypt, ce qui, comme je l'ai dit plus haut, me parait hautement improbable...
Si par exemple ils utilisent un coût de 10 (ce qui est par exemple la valeur par défaut utilisé par PHP), tu multiplies divises ton rendement par 32...

Tu crois qu'on assaisonne et hash les mots-de-passe pour quelle raison?
Justement en cas de fuite de ces données (en fait car on sait qu'elles vont être accédées et exfiltrée à un moment ou un autre). CQFD

Pour revenir sur le rendement, tu peux compter moins de $10 USD par compte "faible" bien exploité (donc les autres plateformes), ce qui te donne 3H de GPU à l'équilibre par compte cassé (32 Millions de passes essayables et je ne tiens même pas compte de la progressivité de la perte de rentabilité).
1 seule GPU sur 10 heures (coût $4.00 USD), avec les paramètres que tu amènes sur bcrypt, limitant celle-ci à 400 passes par seconde va trouver autour de 14000 comptes, avec une valeur moyenne sous les $10 USD, amenant $139 996 USD de bénéfice (et seulement $13 996 USD de bénéfice si on veut bien compter $1 USD par compte mais c'est bien plus).

Très très rentable, on est pas dans le BitCoin là, surtout que bcrypt est fait pour etre attaquable de façon massivement parallèle (comme PBKDF2 recommandé par le NIST)

Ce message a été modifié par iAPX - 6 May 2018, 16:04.

[SartMatt]

Tu crois qu'on assaisonne et hash les mots-de-passe pour quelle raison?
Justement en cas de fuite de ces données (en fait car on sait qu'elles vont être accédées et exfiltrée à un moment ou un autre).

Oui, bien sûr. Au cas où. Mais toi tu parles comme si la fuite avait déjà eu lieu.

Pour revenir sur le rendement, tu peux compter moins de $10 USD par compte "faible" bien exploité (donc les autres plateformes), ce qui te donne 3H de GPU à l'équilibre par compte cassé.

Avec un GPU et un coût à 10 au lieu de 5, en 3h tu testes UN mot de passe sur 1% des comptes Twitter. Ta probabilité d'avoir un match ET que l'utilisateur utilise ce même mot de passe pour son compte mail, elle est sans doute très inférieure à 1...

De toute façon, si c'était si rentable que tu le prétends, les prix devraient s'écrouler, puisqu'il y aurait énormément d'offre sur le marché... C'est le principe de base sur un marché, s'il y a une rentabilité énorme, ça attire beaucoup de monde, et la rentabilité s'écroule...

Donc soit les tarifs que tu donnes sont totalement délirants (8$32 le compte Netflix... j'en rigole encore... qui payerait ce prix pour un compte Netflix dont tu as aucune garantie qu'il durera plus d'un mois* ? et ce alors qu'il suffit de créer un compte Netflix avec un mail et un numéro de CB jetable pour avoir un mois gratuit garanti... quand aux compte mails, quand on voit d'autres sources donnant des prix mille fois plus faibles, on peut sérieusement se demander d'où 01Net sort ses chiffres...), soit c'est quand même beaucoup plus compliqué que tu le dis... En pratique, sans doute un mix des deux : des prix qui sont bien plus faibles que ce que tu dis (diminuant donc la rentabilité) et une complexité bien plus grande, parce que c'est bien joli d'avoir la puissance pour hasher menu, mais encore faut-il avoir la base à craquer, ce qui est une autre paire de manches...


* tiens d'ailleurs... Si c'était vraiment ce prix, qu'est ce qui empêcherait les pirates de créer plein de comptes et de les revendre ? L'abonnement de base est à moins de 8$ dans certains pays, donc ça serait directement rentable...

Ce message a été modifié par SartMatt - 6 May 2018, 16:11.