C# Passwörter verschlüsseln

[Nick_SMI]

Hallo zusammen!

Ich möchte ein Programm erstellen, wo man von einem Benutzer das Passwort braucht.
Nun möchte ich es verschlüsseln und habe das gefunden:

System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(Password, "MD5"))

Ist dies sinnvoll und wenn ja, wäre ein Zugang beispielsweise so:
Ich erstelle den Benutzer, dass Passwort wird dann über MD5 verschlüsselt in die Datenbank eingetragen.
Dann muss ich hingehen, dies abfragen und dass eingegebene Passwort auch verschlüsseln und prüfen, ob das gleich ist!?

So oder doch was besseres?

Grüße und danke im Voraus!

 

[HominiLupus]

Da gibts noch zwei Dinge dazu:
1. Salt verwenden
2. kein MD5, kein SHA-1 sondern SHA-256 oder ähnliches.

 

[Fellor]

Hashen ist nicht verschlüsseln.

Du speicherst das gehashte PW in die Datenbank und prüfst in Zukunft das eingegebene, ebenfalls gehashte Passwort. MD5 würde ich nicht mehr nutzen

 

[hroessler]

Hallo,
dein Ansatz an sich ist korrekt.

Bei der Wahl des Hashalgorithmus kann man sich sicher streiten, ich würde aber einen SHA nehmen. In der Praxis wird der Hash noch gesalzen bzw. gepfeffert um Wörterbuchattacken ins leere laufen zu lassen. Ob das notwendig ist, musst du selbst entscheiden.

greetz
hroessler

 

[wirelessy]

Inwiefern brauchst du das Passwort? Wird gegen das Passwort geprüft? Musst du auf das Passwort wieder im Klartext zugreifen können?
Ggf. hilft dir auch ein SecureString schon weiter - https://msdn.microsoft.com/de-de/library/system.security.securestring(v=vs.110).aspx

 

[ichmich2000]

Bei der Wahl des Hashalgorithmus kann man sich sicher streiten, ich würde aber einen SHA nehmen. In der Praxis wird der Hash noch gesalzen bzw. gepfeffert um Wörterbuchattacken ins leere laufen zu lassen. Ob das notwendig ist, musst du selbst entscheiden.

Für eine Webanwendung sollte es mindestens ein SHA-Hash mit Salt sein. Besser wären noch Geschichten wie bcrypt (https://bcrypt.codeplex.com/), damit bei Diebstahl nicht das Passwort des Benutzers ermittelt werden kann.

 

[Nick_SMI]

Hat jemand beispiele, wie ich es nun richtig anwende (Aus dem String ein geschütztes Passwort zu machen)

Das, was ich angewendet habe, war nicht geschützt, da es bei egal welchem String das gleiche herauskam ^^ :/

 

[r15ch13]

Mit dem BCrypt Paket welches ichmich2000 gepostet hat geht es wie folgt:

// Hashen und speichern (Datenbank etc.)
// Nicht irritieren lassen das bei jedem Durchlauf ein anderer Hash rauskommt. Das ist bei BCrypt normal.
var hash = BCrypt.Net.BCrypt.HashPassword("wurst");


// Passwort vom Login mit Hash aus der Datenbank vergleichen
var password = "wurst";
var hashdb = "$2a$10$2zRtxO2g.Vkg6AI/2Bjv0edYGzrNDPRAVA1iXc5MCzHb/4/Z.V.BK";
if (BCrypt.Net.BCrypt.Verify(password, hashdb))
{
    // login erfolgreich
}

 

[wirelessy]

Reine verstaendnisfrage meinerseits zu bcrypt: wieso kann ich bei bcrypt bei Verlust der db die Inhalte nicht wiederherstellen, bei salted sha-2 aber schon?

 

[r15ch13]

Was meinst du mit wiederherstellen? Die eigentliche Information ist aus einem Hash nicht wiederherstellbar.
Auch bei SHA2 nicht.

 

[Nick_SMI]

Hat auch jemand ein Beispiel ohne BCrypt Paket, mit SHA256 o.Ä.?

 

[hroessler]

Hallo,
da ich per PN um ein Beispiel geben worden bin. Bitte entschuldige, dass ich das für alle Poste. Hier wird in einem Beispiel eine Datei gehasht.

https://msdn.microsoft.com/de-de/library/system.security.cryptography.sha256(v=vs.110).aspx

Funktioniert mit strings genauso. Du musst nur einen Stream durchschieben...

greetz
hroessler

 

[r15ch13]

http://stackoverflow.com/a/14709940/2710739 (Post von: Nico Dumdum) zweiter Codeschnipsel.

var hash = sha256("wurst");

if(sha256("wurst") == "72befc4a7ce090cc58d0a95e7b5f7f7845168a68210f23aa2b763c51403b10c1")
{
    // login erfolgreich
}

 

[wirelessy]

Für eine Webanwendung sollte es mindestens ein SHA-Hash mit Salt sein. Besser wären noch Geschichten wie bcrypt (https://bcrypt.codeplex.com/), damit bei Diebstahl nicht das Passwort des Benutzers ermittelt werden kann.

Den Post meinte ich. Bislang bin ich auch der Meinung, dass ich SHA-2 nicht so ohne weiteres rückgängig machen kann - aber man weiß ja nicht alles. BCrypt kann ich nicht bewerten, daher die Nachfrage.
Ich würd aber nicht soweit gehen und sagen, dass ich die Information aus Hashes grundsätzlich nicht wiederherstellen kann

Zum Thema: Sinngemäß kannst du r15ch13's Code einfach in C# übernehmen. Wichtig: Das Passwort speicherst du nirgends im Code ab, nur in gehashter Form! Für alles was Klartext ist, willst du Input zur Laufzeit.

//e: Oben wurde ja nativer C#-Code schon im msdn-Link gepostet, den kannst du quasi kopieren.

 

[crvn075]

Den Post meinte ich. Bislang bin ich auch der Meinung, dass ich SHA-2 nicht so ohne weiteres rückgängig machen kann - aber man weiß ja nicht alles. BCrypt kann ich nicht bewerten, daher die Nachfrage.

Hashfunktionen sind per Definition nicht injektiv und können nicht "rückgängig gemacht" werden, auch als mittlerweile schwach eingestufte Hashfunktionen wie MD5 nicht und auch meine gerade in diesem Moment erfundene Hashfunktion h(x) = x mod 13 nicht. An letzterer wird dir aber vielleicht klar, dass es auch gar nicht nötig ist, eine Umkehrfunktion zu besitzen, denn durch reines Ausprobieren (also Brute-Force) wirst du für einen gegebenen Hash trotzdem schnell mögliche x-Werte finden. Wenn du jetzt hingehst und für jedes einzelne User-Passwort einen individuellen Salt s hinzufügst, am besten eine Zufallszahl, dann wird die Sache schon etwas sicherer: h(x, s) = (x + s) mod 13 führt dazu, dass gleiche Passwörter x bei unterschiedlichem s auch in einem unterschiedlichen Hash resultieren (also bei mod 13 natürlich nicht unbedingt, aber die Funktion ist ja auch nur zum Veranschaulichen). Das führt dann dazu, dass ein Angreifer das Passwort eines jeden einzelnen Users individuell berechnen muss, was sich kaum lohnt.

Das mit dem Salt musst du bei SHA und Konsorten selbst erledigen, bei bcrypt ist es schon von Haus aus integriert. bcrypt hat außerdem einen weiteren Vorteil: du kannst einen Work-Faktor angeben, also eine Zahl, die bestimmt, wie lange bcrypt tatsächlich an einem einzelnen Hash rumrechnet - die Idee ist, diesen Faktor im Laufe der Jahre mit steigender Rechenleistung der CPUs zu erhöhen. Wenn du den Faktor erhöhst, dann heißt das zwar, dass dein Server bei einem Nutzer-Login länger braucht, um das PW zu validieren - aber eben auch, dass Brute-Force für einen Angreifer sehr kostspielig wird, da dieser ja eine sehr große Anzahl an Hashes berechnen muss.

Die Aussage von ichmich2000, auf die du dich beziehst, ist imho etwas irritierend: der Einsatz einer Hashfunktion im Kontext von Nutzerpasswörtern ist IMMER darin begründet, die Herleitung der tatsächlichen Passwörtern zu erschweren, egal ob bcrypt oder nicht.

 

[Demon0no]

Ergänzend noch ein Link zum Thema:
https://crackstation.net/hashing-security.htm

Empfehle ich immer wieder gerne, ist imo ganz nett zu lesen.