Linkedin: pas 6143150 sha1 volés, seulement 5545381

Bon, ça fait un petit moment maintenant que je geek avec les sha1 LinkedIn qui ont fuité (qui ont fui?). Deux choses m'intéressent particulièrement.

1) La proportion de mot de passes utilisés par plusieurs personnes

Au début je croyais que ce serait facile à calculer genre a=(sort sha1.txt|uniq|wc -l) b=(sort sha1.txt|wc -l) et puis (b-a)/b. Ouais, ben en fait non. Ce calcule là donne 0.

Est-ce à dire que personne n’utilise le même mot de passe ? Oh que non. Je pense plutôt que la liste a été nettoyée de ses doublons. Dans un sens tant mieux parce que la connaissance du taux de réutilisation facilite un peu le cassage de certains mots de passe.

Du coup je me suis rabattu sur les "quasi" doublons. Il s’agit des sha1 dans le fichier qui apparaissent avec juste des zéros au début genre b2d21130f300016…5ce61f9 et 00000130f300016…5ce61f9. Là on peut calculer la proportion de quasi doublons. Il suffit d’enlever, mettons, les dix premier caractères de chaque sha1, de trier, et de compter ce qui sort en double.

Ça nous donne : a = nombre de lignes dans le fichier sha1.txt = 6143150. b = nombre de lignes dans la version sans doublons = 5545381. (a-b)/a=0,097… En arrondissant c’est presque 10% de quasi doublons.

Conclusion : j’en sais rien. Certains blogs disent que les quasi-doublons correspondent aux sha1 dont l’antécédent a déjà été trouvé. Hmmm... Difficile à prouver.

En tout cas ce ne sont pas 6143150 sha1 qui ont fuité, mais seulement 5545381. Nous voilà rassurés ! (ou pas)

2) Le nombre de mots de passe d'utilisateurs français

Déjà, mon mot de passe y est. Or LinkedIn a dans les 165 millions d’utilisateurs et le fichier ne contient que 5545381 vrais sha1 (cf. point 1). Quand on y pense, ça représente seulement 3,4% des utilisateurs. Faut vraiment pas avoir de bol pour y être !

Par curiosité, j’ai demandé leur sha1 à quelques amis français. Plus précisément à 5 amis français, que je remercie de leur confiance au passage. Et bien ils apparaissent tous dans le fichier. Tous. J’aime pas calculer des probas à 4 heures du matin, mais là quand même ça semble bizarre. Certes, il n’y a aucune raison pour que les sha1 volés soient uniformément répartis sur l’ensemble des utilisateurs LinkedIn. On peut par exemple imaginer que les comptes volés sont ceux d’un datacenter européen (mettons celui de Dublin, au hasard) contenant notamment les utilisateurs français. C’est ce que je pense, et ça corrobore le fait que seulement 5545381 aient été volés. L’ordre de grandeur est le même que les 11 millions d’utilisateurs en Europe (et 2 millions en France).

3) Les comptes à qui appartiennent les mots de passe

Je sais : j'ai dit que *deux* choses m’intéressaient particulièrement. Mais quand deux choses m’intéressent, c'est souvent la troisième qui retient mon attention.

Avoir les mots de passe c’est intéressant. Mais sans les comptes correspondant ça devient vite lassant. Evidemment, ça serait plus facile s’il existait une correspondance entre l’ordre d’apparition des sha1 dans le fichier et, mettons, l’ordre des comptes LinkedIn. Bien sûr pour ça il faudrait que les comptes LinkedIn soient ordonnés, avec des identifiants énumérables... On me murmure dans l’oreillette que c’est le cas ; j’y reviendrais d'ailleurs dans un autre post parce que les identifiants énumérables c’est mal.

Voilà qui réduit considérablement la combinatoire ! En effet, il suffit de prendre dans le fichier deux mots de passe de personnes dont on connait l’identité (genre le mien et celui d’un copain). Si l’ordre du fichier est bien le même que l’ordre des identifiants, alors ça nous dit que tous les mots de passe entre le mien et celui du copain correspondent à des identifiants entre le mien et celui du copain.

Ça reste une hypothèse de travail pour l’instant, essentiellement parce que ça impleek de tester de vrais mots de passe sur de vrais comptes appartenant à de vrais gens, et ça j’ai arrêté il y a très longtemps (en même temps que l’héroïne et les fraises tagada).