Si on vol la DB, on a les 20 hash.
Tu fais quoi ensuite ?
Réduisons le problème à 2 questions au lieu de 20:
le mot de passe est 789123
première question: "entrez le premier, troisième et cinquième chiffre".
Le bon code est: 792. Je prends: 135792 (les trois chiffres de la question, les trois chiffres de la réponse). Je rajoute un sel et obtient un hash et ça me donne par exemple AAAAAA. Je le sauve dans la base de donnée.
deuxième question: "entrez le premier, troisième et sixième chiffre".
Le bon code est: 793. Je prends: 136793 (les trois chiffres de la question, les trois chiffres de la réponse). Je rajoute un sel et obtient un hash et ça me donne par exemple BBBBBB. Je le sauve dans la base de donnée.
Lorsque je veux tester si le client a entré le bon code, je prends les 3 chiffres de la question + les trois chiffres de la réponse, je rajoute le sel et obtient le hash. Si le résultat est AAAAAA ou BBBBBB, c'est que le code est bon (je n'ai même pas besoin de retenir que AAAAAA correspond à la question un, car s'il n'y a pas de collisions, impossible que le hash de la question deux puisse correspondre à un hash obtenu avec une question un).
Tu noteras que prendre les trois chiffres de la question n'est qu'un exemple: en pratique, avec juste la base de données, tu ne sais pas ce qui est fait: à la place de 135 pour la question un, il se peut qu'on utilise 531, ou 001 ou n'importe quel identifiant associé en dur à "question un" dans le protocole.
Comment fais-tu à partir de AAAAAA ou BBBBBB pour pouvoir répondre à, disons, la question un (tu ne peux pas savoir si AAAAAA ou BBBBBBB correspond à la question un, vu que comme expliqué, il n'est pas nécessaire pour la banque de le savoir et donc elle les a mélangé lors de leur création) ?
Pour la question un, même si tu connais le début (mais comme expliqué, il n'y a aucune raison pour que ce soit le cas), il te faut trouver 792. Tu ne peux pas comparer AAAAAA et BBBBBB avec toutes les combinaisons 792000 792001 792002 ... à cause du sel.
Comme dit par ailleurs, au final, cela revient simplement à donner au client 20 mots de passe différents. Vu que dans le système en question, la force brute est inutile (car plusieurs essais finiront par lancer une alerte et bloquer la carte) et le réel danger est l'interception du mot de passe initial (789123), la solution me parait plutôt intelligente.
[^] # Re: 3 chiffres sur 6, c'est 6 hashs de 1 chiffre chacun
Posté par j-c_32 . En réponse au journal Sécurité et authentification des sites bancaires.. Évalué à 2.
Je ne suis pas sur de comprendre.
Si on vol la DB, on a les 20 hash.
Tu fais quoi ensuite ?
Réduisons le problème à 2 questions au lieu de 20:
le mot de passe est 789123
première question: "entrez le premier, troisième et cinquième chiffre".
Le bon code est: 792. Je prends: 135792 (les trois chiffres de la question, les trois chiffres de la réponse). Je rajoute un sel et obtient un hash et ça me donne par exemple AAAAAA. Je le sauve dans la base de donnée.
deuxième question: "entrez le premier, troisième et sixième chiffre".
Le bon code est: 793. Je prends: 136793 (les trois chiffres de la question, les trois chiffres de la réponse). Je rajoute un sel et obtient un hash et ça me donne par exemple BBBBBB. Je le sauve dans la base de donnée.
Lorsque je veux tester si le client a entré le bon code, je prends les 3 chiffres de la question + les trois chiffres de la réponse, je rajoute le sel et obtient le hash. Si le résultat est AAAAAA ou BBBBBB, c'est que le code est bon (je n'ai même pas besoin de retenir que AAAAAA correspond à la question un, car s'il n'y a pas de collisions, impossible que le hash de la question deux puisse correspondre à un hash obtenu avec une question un).
Tu noteras que prendre les trois chiffres de la question n'est qu'un exemple: en pratique, avec juste la base de données, tu ne sais pas ce qui est fait: à la place de 135 pour la question un, il se peut qu'on utilise 531, ou 001 ou n'importe quel identifiant associé en dur à "question un" dans le protocole.
Comment fais-tu à partir de AAAAAA ou BBBBBB pour pouvoir répondre à, disons, la question un (tu ne peux pas savoir si AAAAAA ou BBBBBBB correspond à la question un, vu que comme expliqué, il n'est pas nécessaire pour la banque de le savoir et donc elle les a mélangé lors de leur création) ?
Pour la question un, même si tu connais le début (mais comme expliqué, il n'y a aucune raison pour que ce soit le cas), il te faut trouver 792. Tu ne peux pas comparer AAAAAA et BBBBBB avec toutes les combinaisons 792000 792001 792002 ... à cause du sel.
Comme dit par ailleurs, au final, cela revient simplement à donner au client 20 mots de passe différents. Vu que dans le système en question, la force brute est inutile (car plusieurs essais finiront par lancer une alerte et bloquer la carte) et le réel danger est l'interception du mot de passe initial (789123), la solution me parait plutôt intelligente.