2016-09-23 4 views
0

Ich habe eine Registrations Tabelle, in die neue Benutzer hineingelegt werden. Ein späterer Prozess erstellt eine Datenbank für diesen Benutzer und fügt einen ASP.NET-Identitätsbenutzerdatensatz aus den Daten in der Registrierungstabelle ein (E-Mail-Name &).Generiere ein PasswordHash und SecurityStamp

Ich möchte dies so erweitern, dass Benutzer bei der Registrierung ihr Passwort eingeben können, das dann in der neuen Datenbank eingerichtet wird.

Um dies richtig zu tun, müsste ich einen SecurityStamp Wert erstellen und dann das Passwort verschlüsseln, um die PasswordHash zu bekommen, glaube ich. Dann würde ich diese Werte in der Registrierungstabelle speichern und sie dann in die neue Datenbank des Benutzers kopieren, wenn diese eingerichtet ist, und sie könnten sich mit dem von ihnen registrierten Passwort anmelden.

Wie würde ich das tun - generieren Sie die SecurityStamp und dann das Passwort hash?

+0

Identität behandelt dies alles für Sie, Sie sind nicht die 'UserManager'-Klasse? – DavidG

+0

@DavidG Die Datenbank existiert zum Zeitpunkt der Registrierung nicht. Ich möchte das Kennwort sicher speichern, bis ein späterer Prozess die Datenbank erstellt und anschließend die UserManager-Klasse zum Erstellen des ersten Benutzerkontos verwendet. – Sean

Antwort

1

SecurityStamp kann alles zufällig sein, nicht wiederholbar - Guid.NewGuid().ToString() macht den Job schön.

Für Passwort UserManager Hashing hat Eigenschaft PasswordHasher, die für Sie nicht Passwort-Hashing:

var userManager = new UserManager(context); 
var passwordHash = userManager.PasswordHasher.HashPassword("mySecurePassword"); 
+0

Hmm. Daher muss ich den SecurityStamp nicht in der Registrierungstabelle speichern. Ich muss nur das Passwort hashen und speichern, oder? Und zweitens spielt es keine Rolle, ob ich das Passwort mit 'contextA' hashe und dann den Wert im Feld PasswordHash in einer User-Tabelle in' contextB' aktualisiere - ist das richtig? – Sean

+0

@Sean Korrigieren Sie auf allen Konten. Änderungen in SecurityStamp machen die bestehenden Cookies aller Benutzer ungültig - sie müssen sich erneut anmelden. Wenn Sie den Kennwort-Hash an einen anderen Ort verschieben, wirkt sich dies nicht auf das Kennwort aus. Salt wird zusammen mit dem tatsächlichen Hash in derselben Spalte eingebettet und das tatsächliche Hashing hängt nicht von einer der Speicherimplementierungen ab. – trailmax