Ist es in Ordnung, ein Salz aus einem Passwort abzuleiten und dann das Passwort + abgeleitetes Salz zu hashen?

Question

Ich verwende NHibernate und habe einen benutzerdefinierten Typ zum Verschlüsseln von Kennwörtern in der Datenbank, sodass ich Zeichenfolgeneigenschaften zur Darstellung von Kennwörtern verwenden kann, aber NHibernate transformiert/verschlüsselt den Wert, bevor er in der Datenbank gespeichert wird. Momentan speichere ich einen Salt-Wert und einen Verschlüsselungsschlüssel in der Konfigurationsdatei, aber ich würde lieber zu einem Passwort-Hash wechseln. Der benutzerdefinierte NHibernate-Typ weiß jedoch nichts über das Objekt, das gespeichert wird, außer dem Wert der Eigenschaft, mit der es behandelt werden soll. Daher kann ich kein zufälliges Salz generieren und es mit dem Objekt in einer anderen Eigenschaft innerhalb dieses benutzerdefinierten Typs speichern .

Da ich das Salz nicht getrennt speichern kann, frage ich mich, ob es in Ordnung wäre, das Salz aus dem Passwort selbst abzuleiten, und dann die Kombination der beiden Hash-Werte. Zum Beispiel könnte ich das Passwort nehmen, MD5 es Hash, dann verwenden Sie den MD5-Hash als Salz. Wäre das in Ordnung? Dies würde es mir ermöglichen, das Passwort deterministisch beizubehalten, während ich einen eindeutigen (aber abgeleiteten) Salt-Wert pro Passwort verwende, aber gibt es irgendwelche Sicherheitsüberlegungen, wenn es so gemacht wird?

EDIT:

Da alle Antworten habe ich bisher erhalten habe versäumt für den Kontext der Frage zu erklären, mir die Unterschrift des in NHibernate Begriffe definiert Methode darstellen lassen.

public override void Set(IDbCommand cmd, object value, int index) 
{ 
    var param = (IDataParameter)cmd.Parameters[index]; 

    if (value == null) 
    { 
     param.Value = null; 
    } 
    else 
    { 
     var temp = value.ToString(); 
     var encrypted = encryptor.Encrypt(temp); 
     param.Value = encrypted; 
    } 
} 

Das ist alles, was NHibernate mir gibt. Ich erhalte das IDbCommand-Objekt, einen Wert und einen Parameterindex. Ich weiß nichts über die Parameter selbst oder den Typ des Objekts, das beibehalten wird. Ich habe nur einen Wert. Ich kann kein zufälliges Salz erzeugen und es in einer separaten Eigenschaft speichern, weil ich nicht weiß, welche Eigenschaften auf dem Objekt bestehen und welche Reihenfolge sie in der Parametersammlung gespeichert sind. Mein Ziel ist es, das Passwort so sicher wie möglich zu hashen im Rahmen dieser Methode Anruf. Wenn Sie gegen meinen Vorschlag argumentieren, wäre es hilfreich, eine alternative Idee in diesem Zusammenhang zu erhalten.

Answer 1

Nein! Wenn Sie Salz vom Passwort ableiten, haben alle dasselbe Passwort den gleichen Hash und das Salz wurde unbrauchbar.

Versuchen mit

var temp = value.ToString(); 
var salt = generateRandonSalt(); 
var encrypted = encryptor.Encrypt(temp + salt); 
param.Value = salt + encrypted; 

Mit „+“ Ich meine, einen Verkettung Operanden oder etwas mit Ihrem Wert kompatibel. Und natürlich müssen Sie immer die Salzlänge kennen, damit Sie das Passwort nächstes Mal überprüfen können.

Answer 2

Das Problem mit Ihrem Beispiel ist, dass wenn ein Angreifer eine Übereinstimmung finden wollte, könnten sie eine Rainbow-Tabelle erstellen, wo alle Passwörter von ihren MD5 Counterparts gesalzen werden.

Salze sollten für jeden Eintrag eindeutig sein, so dass ein Hacker eine umgekehrte Tabelle aller möglichen Kombinationen des md5 mit jedem möglichen Salz haben müsste.

Answer 3

Der Zweck einer Hash-Funktion ist es, etwas aus dem Passwort abzuleiten. Wenn Sie das Salz aus dem Kennwort ableiten, ist diese Ableitung effektiv Teil Ihrer Hash-Funktion. Sie haben gerade die Hashing-Funktion geändert/erweitert und haben kein Salz mehr.

Salze müssen zufällig sein.

Ihre Aufgabe besteht darin, es schwerer zu machen, ein Passwort brutal zu erzwingen. Wenn ein Salz zum Beispiel 65536 verschiedene Werte hat, bedeutet dies, dass das gleiche Passwort 65536 verschiedene Hashes haben kann.Wenn jemand ein Wörterbuch erstellen möchte, das Hashes zurück in Passwörter umkehrt, benötigt sein Wörterbuch 65536 Einträge für nur ein Passwort.

Das Salz muss nichts mit dem Passwort zu tun haben, damit diese Idee funktioniert.

Answer 4

Wenn der Zweck Ihres salt-like-Schemas darin besteht, das Kennwort für einen Wörterbuchangriff mit vorher festgelegten Hashes resistent zu machen, ist Ihr Ansatz möglicherweise ein wenig sicherer als ein ungesalzener Hash, aber nicht annähernd so sicher wie die Verwendung ein gültiges Salz.

Ein wichtiger Sicherheitsvorteil eines gültigen Saltes besteht darin, dass zwei Instanzen desselben Kennworts zwei verschiedene Hashwerte ergeben. Wenn Sie das Kennwort und den Hash eines Benutzers kennen, kann ein Angreifer unter Umständen dieselben Kennwörter eines anderen Benutzers mit demselben Hash ableiten.