Oui, la comparaison de chaînes (et/ou la recherche d'index) peut, en principe, divulguer le nombre d'octets de début identiques que le hachage de mot de passe stocké dans la base de données et celui calculé à partir du partage de mot de passe saisi.
En principe, un attaquant pourrait l'utiliser pour apprendre de manière itérative un préfixe du hachage du mot de passe, octet par octet :il trouve d'abord un hachage qui partage son premier octet avec le hachage de la base de données, puis un qui partage ses premiers deux octets, etc.
Non, cela n'aura certainement pas d'importance.
Pourquoi? Eh bien, pour plusieurs raisons :
-
Une attaque temporelle peut permettre à l'attaquant d'apprendre une partie du hachage du mot de passe de l'utilisateur. Un schéma de hachage de mot de passe bien conçu (utilisant un sel et un étirement de clé ), doit cependant rester sécurisé (en supposant, bien sûr, que les mots de passe eux-mêmes ne soient pas facilement devinables) même si l'attaquant connaît l'intégralité hachage du mot de passe. Ainsi, même si l'attaque temporelle réussit, les mots de passe eux-mêmes seront en sécurité.
-
Pour mener à bien l'attaque, l'attaquant doit soumettre des mots de passe dont il connaît la valeur de hachage. La valeur de hachage dépend du sel. Ainsi, à moins que l'attaquant ne connaisse déjà le sel, cette attaque n'est pas possible.
(Il est vrai que, dans la plupart des analyses de sécurité des schémas de hachage de mots de passe, le sel est supposé être une information publique. Cependant, c'est uniquement parce que ces analyses supposent le pire scénario mentionné ci-dessus, où l'attaquant a déjà obtenu une copie de l'ensemble de la base de données utilisateur, sels et hachages et tout. Si l'attaquant ne connaît pas encore le hachage, il n'y a aucune raison de supposer qu'il connaîtrait le sel.)
-
Même si l'attaquant connaît le sel, afin de mener à bien l'attaque itérative décrite ci-dessus, il devra générer des mots de passe qui hachent une valeur avec un préfixe souhaité. Pour toute fonction de hachage sécurisée, la seule façon pratique de le faire est d'essayer une erreur, ce qui signifie que le temps nécessaire pour le faire évolue de manière exponentielle avec la longueur du préfixe.
Ce que cela signifie en pratique, c'est que, pour extraire suffisamment de bits du hachage pour pouvoir effectuer une attaque par force brute hors ligne contre lui (qui n'a pas besoin d'être tous; juste plus que la quantité effective d'entropie dans le mot de passe), l'attaquant doit effectuer à peu près autant de calculs que nécessaire pour déchiffrer le mot de passe lui-même. Pour un schéma de hachage de mot de passe bien conçu et un mot de passe choisi en toute sécurité, cela n'est pas faisable.
-
Ce que l'attaque itérative peut donner à l'attaquant, en principe, est la possibilité de faire la plupart des calculs de force brute localement de son côté, tout en ne soumettant qu'un nombre assez restreint de mots de passe à votre système. Cependant, même cela ne vaut que s'ils reçoivent des informations de chronométrage détaillées et fiables de chacun mot de passe soumis. En pratique, les attaques en temps réel sont extrêmement inefficaces , et nécessitent de nombreuses requêtes (souvent des milliers ou des millions) pour produire tout informations utiles du tout. Cela annulera très probablement tout avantage potentiel en termes de performances que l'attaque temporelle pourrait fournir à l'attaquant.
Ce point est amplifié si vous utilisez un schéma de hachage de mot de passe d'étirement de clé approprié, car ces schémas sont délibérément conçus pour être lents. Ainsi, la comparaison de chaînes dans la base de données prendra probablement un temps négligeable par rapport au hachage du mot de passe en premier lieu, et toutes les variations de synchronisation causées par celui-ci seront ainsi perdues dans le bruit.
