it-swarm.com.de

Warum sollte die Überprüfung des Passwort-Hash zeitlich konstant sein?

Im asp.net-Kern PasswordHasher gibt es eine Bemerkung zur VerifyHashedPassword-Methode

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

Und um dann die Hashes zu vergleichen, wird Code verwendet, der absichtlich nicht optimiert und geschrieben wurde, und keine frühen Exits in der Schleife.

// 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;
}

Zuerst dachte ich, dass ohne dieses Timing bestimmt werden könnte, wie nah der Hash ist. Wenn es länger dauert, ist mehr Hash gleich.

Dies ist jedoch nicht sinnvoll, da der Hash zu diesem Zeitpunkt 1000 Iterationen von SHA256 durchlaufen hat. Jede Änderung des Passworts würde also einen völlig anderen Hash erzeugen, und wenn Sie wissen, dass Ihr Passwort fast den richtigen Hash erzeugt, können Sie den richtigen nicht finden.

Was ist der Zweck, um eine konstante Zeit-Hash-Überprüfung sicherzustellen?

29
trampster

Angenommen, keiner der Hashes ist geheim und die Hashes sind sicher (was SHA-256 ist), gibt es keinen Grund, den Hash in konstanter Zeit zu überprüfen. Tatsächlich ist das Vergleichen von Hashes eine der bekannten Alternativen zum Überprüfen von Passwörtern innerhalb einer konstanten Zeitroutine. Ich kann nicht sagen, welchen Grund die Entwickler dafür angeben würden, aber es ist technisch nicht notwendig, die Zeit konstant zu halten. Höchstwahrscheinlich waren sie nur vorsichtig. Nicht konstanter Zeitcode in einer kryptografischen Bibliothek macht Auditoren ängstlich.

Weitere Informationen zu den theoretischen Schwächen werden in einer Antwort auf der Cryptography-Site diskutiert. Es wird erklärt, wie es mit einer signifikanten Anzahl von Abfragen möglich sein kann, die ersten mehreren Bytes des Hash zu ermitteln, wodurch es möglich wird, eine auszuführen Offline-Berechnung, um Kandidatenkennwörter zu verwerfen, die offensichtlich nicht übereinstimmen (ihr Hash stimmt nicht mit den ersten entdeckten Bytes des echten Hash überein) und zu vermeiden, dass sie an den Kennwortprüfungsdienst gesendet werden, und warum dies wahrscheinlich kein echtes Problem ist.

42
forest