Pour que la banque puisse demander 3 chiffres sur 6, il faut qu'elle ait stocké chacun des 6 chiffres dans sa BDD. En effet, en temps normal, tu demandes un seul mot de passe à l'utilisateur, tu le haches, tu compares le hash à celui qui est dans ta BDD, si ça correspond, c'est bon, l'utilisateur est authentifié. Ceci permet de ne pas stocker de mot de passe en clair dans ta base de données.
Mais pour pouvoir demander les chiffres 1, 2 et 5, il faut que les chiffres 1, 2 et 5 soient dans ta BDD. De cette façon, tu peux demander à l'utilisateur les chiffres 1, 2 et 5 de son code, tu haches chaque chiffre, et tu compares le hash du chiffre 1 avec celui de ta base de données, idem pour le hash du chiffre 2 et celui du chiffre 5.
Au final, tu as donc stocké 6 hashs (un par chiffre) de 1 chiffre chacun. Le problème, c'est que ça facilite fortement l'attaque, le jour où ta BDD fuite.
En effet, on ne sait pas retrouver facilement l'antécédent d'un hash donné. La seule façon de faire est de calculer tous les hashs de tous les antécédents possibles et de les comparer à la BDD. C'est long, surtout si on a choisi une fonction de hash un peu lente. La question est donc : combien d'antécédents sont possibles ? Autrement dit, combien de mots de passe sont possibles ?
Pour un mot de passe de 6 chiffres de 0 à 9, la réponse est simple : il y a 106 possibilités. C'est peu. Mais c'est déjà bien plus que pour le mot de passe divisé en 6 chiffres stockés séparément ! En effet, pour retrouver le premier caractère, l'attaquant n'aura qu'a hacher les chiffres de 0 à 9 jusqu'à trouver le bon. Idem pour le second caractère. Et ainsi de suite. Un attaquant qui a accédé à la base de données des mots de passe n'a donc que 10 hashs à calculer. Si le concepteur a été prudent et a combiné une chaîne de caractères aléatoire (stockée dans la même base de données) au chiffre et a pris 6 chaînes de caractères différentes (une par chiffre), alors on monte péniblement à 60 hashs.
Autrement dit, on vend à l'utilisateur un faux sentiment de sécurité ("c'est plus compliqué à utiliser, c'est donc forcément plus sécurisé") qui aboutit en pratique à diminuer la sécurité.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
# 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par Liorel . En réponse au journal Sécurité et authentification des sites bancaires.. Évalué à 10.
Pour que la banque puisse demander 3 chiffres sur 6, il faut qu'elle ait stocké chacun des 6 chiffres dans sa BDD. En effet, en temps normal, tu demandes un seul mot de passe à l'utilisateur, tu le haches, tu compares le hash à celui qui est dans ta BDD, si ça correspond, c'est bon, l'utilisateur est authentifié. Ceci permet de ne pas stocker de mot de passe en clair dans ta base de données.
Mais pour pouvoir demander les chiffres 1, 2 et 5, il faut que les chiffres 1, 2 et 5 soient dans ta BDD. De cette façon, tu peux demander à l'utilisateur les chiffres 1, 2 et 5 de son code, tu haches chaque chiffre, et tu compares le hash du chiffre 1 avec celui de ta base de données, idem pour le hash du chiffre 2 et celui du chiffre 5.
Au final, tu as donc stocké 6 hashs (un par chiffre) de 1 chiffre chacun. Le problème, c'est que ça facilite fortement l'attaque, le jour où ta BDD fuite.
En effet, on ne sait pas retrouver facilement l'antécédent d'un hash donné. La seule façon de faire est de calculer tous les hashs de tous les antécédents possibles et de les comparer à la BDD. C'est long, surtout si on a choisi une fonction de hash un peu lente. La question est donc : combien d'antécédents sont possibles ? Autrement dit, combien de mots de passe sont possibles ?
Pour un mot de passe de 6 chiffres de 0 à 9, la réponse est simple : il y a 106 possibilités. C'est peu. Mais c'est déjà bien plus que pour le mot de passe divisé en 6 chiffres stockés séparément ! En effet, pour retrouver le premier caractère, l'attaquant n'aura qu'a hacher les chiffres de 0 à 9 jusqu'à trouver le bon. Idem pour le second caractère. Et ainsi de suite. Un attaquant qui a accédé à la base de données des mots de passe n'a donc que 10 hashs à calculer. Si le concepteur a été prudent et a combiné une chaîne de caractères aléatoire (stockée dans la même base de données) au chiffre et a pris 6 chaînes de caractères différentes (une par chiffre), alors on monte péniblement à 60 hashs.
Autrement dit, on vend à l'utilisateur un faux sentiment de sécurité ("c'est plus compliqué à utiliser, c'est donc forcément plus sécurisé") qui aboutit en pratique à diminuer la sécurité.
Ça, ce sont les sources. Le mouton que tu veux est dedans.