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.
