web-dev-qa-db-fra.com

Pourquoi la vérification du hachage de mot de passe devrait-elle être constante dans le temps?

Dans le noyau asp.net PasswordHasher , il y a une remarque sur la méthode VerifyHashedPassword

 /// <remarks>Implementations of this method should be time consistent.</remarks>

Et puis pour comparer les hachages, il utilise du code qui n'est délibérément pas optimisé et écrit ne fait pas de sorties précoces dans la boucle.

// Compares two byte arrays for equality. The method is specifically written so that the loop is not optimized.
[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
private static bool ByteArraysEqual(byte[] a, byte[] b)
{
    if (a == null && b == null)
    {
        return true;
    }
    if (a == null || b == null || a.Length != b.Length)
    {
        return false;
    }
    var areSame = true;
    for (var i = 0; i < a.Length; i++)
    {
       areSame &= (a[i] == b[i]);
    }
    return areSame;
}

Au début, je pensais que sans cette synchronisation, on pourrait déterminer à quelle distance le hachage était proche, si cela prend plus de temps, alors plus de hachage est le même.

Cependant, cela n'a pas de sens car le hachage a traversé 1000 itérations de SHA256 à ce stade. Ainsi, tout changement de mot de passe produirait un hachage complètement différent, et savoir que votre mot de passe produit presque le hachage correct ne vous aide pas à trouver le bon.

Quel est le but d'assurer une vérification de hachage à temps constant?

passwordshash
29
trampster

En supposant qu'aucun des hachages n'est secret et que les hachages sont sécurisés (ce qui est SHA-256), il n'y a aucune raison de vérifier le hachage en temps constant. En fait, la comparaison des hachages est l'une des alternatives bien connues à la vérification des mots de passe dans une routine à temps constant. Je ne peux pas dire quelle raison les développeurs donneraient pour cela, mais il n'est pas techniquement nécessaire de le faire en temps constant. Très probablement, ils étaient juste prudents. Un code temporel non constant dans une bibliothèque cryptographique inquiète les auditeurs.

Plus d'informations sur les faiblesses théoriques sont discutées dans une réponse sur le site de Cryptographie. Il explique comment, avec une quantité importante de requêtes, il peut être possible de découvrir les premiers octets du hachage, ce qui permet d'effectuer une calcul hors ligne pour éliminer les mots de passe candidats qui ne correspondraient évidemment pas (leur hachage ne correspond pas aux premiers octets découverts du vrai hachage) et éviter de les envoyer au service de vérification des mots de passe, et pourquoi il est peu probable que ce soit un vrai problème.

42
forest