BCrypt

  • VB.NET

Es gibt 27 Antworten in diesem Thema. Der letzte Beitrag () ist von nogood.

    BCrypt

    Hey,

    ich habe mich mal daran versucht, ein Passwort per BCrypt in eine Access-DB zu speichern.

    An sich funktioniert das auch.

    VB.NET-Quellcode

    1. Private Sub savedata()
    2. Dim password As String = txtPassword.Text
    3. Dim hashedPassword As String = BCrypt.Net.BCrypt.HashPassword(password)
    5. Dim drv = DirectCast(Me.Tabelle1BindingSource.Current, DataRowView)
    7. drv("Passwort") = hashedPassword
    9. Tabelle1BindingSource.EndEdit()
    10. Tabelle1TableAdapter.Update(Database2DataSet.Tabelle1)
    11. End Sub


    Das Passwort wird auch angelegt, aber auch wenn ich jedes mal das gleiche PW (z.B. 1234) hinterlege kommen unterschiedliche Hashes heraus.
    Die Frage ist nun wie ich den beim Login erzeugten Hash mit dem aus der DB vergleiche, wenn diese dann unterschiedlich sind.

    Habe ich was falsch verstanden oder ist es doch so, dass das Passwort als Hash in der DB abgelegt wird und dieser dann mit dem generierten Hash aus dem eingegebenen Anmelde-PW verglichen wird.

    @uNbRaKe Das "besondere" an BCrypt.Net.BCrypt.HashPassword() besteht in der Verwendung eines Salt-Wertes.
    Du musst sicherstellen, dass bei beiden Hash-Berechnungen derselbe Salt-Wert verwendet wird:
    Spoiler anzeigen

    C#-Quellcode

    1. public partial class MainForm : Form
    2. {
    3. private readonly string salt;
    4. public MainForm()
    5. {
    6. this.InitializeComponent();
    7. this.salt = BCrypt.GenerateSalt();
    8. }
    10. private void Button1_Click(object sender, EventArgs e)
    11. {
    12. string password = "abcde";
    13. string hashedPassword = BCrypt.HashPassword(password, this.salt);
    14. this.listBox1.Items.Add(hashedPassword);
    15. }
    16. }

    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „RodFromGermany“ ()

    Das sollte doch dann so sein, jedoch geht es so ebenso nicht.

    VB.NET-Quellcode

    1. ​
    2. Private Sub savedata()
    3. Dim password As String = txtPassword.Text
    4. Dim specifiedSalt As String = txtuser.Text
    5. Dim hashedPassword As String = BCrypt.Net.BCrypt.HashPassword(password, specifiedSalt)
    7. Dim drv = DirectCast(Me.Tabelle1BindingSource.Current, DataRowView)
    9. drv("Passwort") = hashedPassword
    11. Tabelle1BindingSource.EndEdit()
    12. Tabelle1TableAdapter.Update(Database2DataSet.Tabelle1)
    13. End Sub

    uNbRaKe schrieb:

    jedoch geht es so ebenso nicht.
    Lesen bildet.

    RodFromGermany schrieb:

    this.salt = BCrypt.GenerateSalt();
    Kommentar zum Parameter salt im BCrypt-Quelltext:

    C#-Quellcode

    1. /// <param name="salt"> the salt to hash with (best generated using <see cref="BCrypt.GenerateSalt()"/>).</param>
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ohne Salt ist Hashing weniger sicher. Denn man kann durch Cleveres rumprobieren wohl eine effiziente Rekonstruktion ermöglichen.

    Ein Saltwert ist eigentlich nur ein zweites Passwort. Je nachdem ob Zugriff auf Hashwerte besteht, besteht somit auch Zugang zum Salt, was wiederum suboptimal ist. Wird der Salt anders gespeichert als die Hashwerte heißt der Salt dann Pepper. Soll also wiederum den Zugriff erschweren.

    Verschlüsselung ist ein Katz- und Mausspiel

    BCrypt erzeugt für ein und das selbe Passwort unterschiedliche Hashes das ist so gewollt. Ich hab in .NET noch nicht damit gearbeitet, nutze es aber in PHP ausschließlich. Dort gibt es eine Verify Funktion um PlainText mit Hash zu vergleichen. Die dürfte es in .NET auch geben. Also einfach mal gucken ob die BCrypt Klasse sowas anbietet

    Ein Blick in die Readme verrät: BCrypt.Verify("my password", passwordHash);

    Source: github.com/BcryptNet/bcrypt.net

    Haudruferzappeltnoch schrieb:

    Wird der Salt anders gespeichert als die Hashwerte heißt der Salt dann Pepper.
    Da sagt aber Wikipedia was anderes: Salt wird im Klartext gespeichert und versalzt vor allem Rainbow-Tables, Pepper: geheim, um es noch komplizierter für Angreifer zu machen.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Hm, wenn der geheim gespeichert wird, dann müsste er ja invertierbar sein, damit man ihn benutzen kann. (Ist er vielleicht auch weiß ich nicht)
    Aber egal was Wikipedia sagt, beabsichtigt ist ja dennoch, was ich auch gesagt habe.
    Ob durch einen anderen Ort oder andere Sicherheitskriterien, das ist meiner Meinung nach nicht entscheidend für die Definition des Peppers.
    Oder anders ausgedrückt ich sehe den Widerspruch nicht.

    Du schriebst, dass Salt zu Pepper wird. Also das eine in seinen Eigenschaften verändert wird, sodass es etwas anderes wird. Ich schrieb: Dienst ist Dienst und Schnaps ist Schnaps. Das eine ist Salt, das andere ist Pepper. Also, dass es zwei Komponenten sind, die beide gleichzeitig existieren. Vielleicht hattest Du das auch so gemeint. Aber es las sich anders. Daher mein Einspruch.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Was bei mir "wird" ist "anders gespeichert". Aber am Ende ist ein Pepper auch immer ein Salt. Daher verwende ich dirkekt Salt als Bezeichnung und nicht "zweite Zeichenfolge zum Verbinden"
    Oder meinst du sowohl ein Salt als auch ein Pepper wird auf ein Passwort angewendet, wie beim Essen? Das habe ich so nicht explizit berücksichtigt.
    Ich denke auch, dass das den Salt redundant macht.

    Haudruferzappeltnoch schrieb:

    Ich denke auch, dass das den Salt redundant macht.
    Ich halte es für merkwürdig, dass es eine Hash-Prozedur gibt, die ohne Salt-Parameter nicht reproduzierbar ist.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Das ist Mathematik. Funktionen deren Inversen alles andere als trivial sind.
    Die Methoden um das zu Knacken, ist keine echte Reproduktion, nur ein effizient genug gestaltbares Rumprobieren. Heißt über eine entsprechende Schlüsselgröße kann man das auch abstellen, nur ist ein riesiger Schlüssel auch nicht erstrebenswert.
    Man muss außerdem beachten eine Hashfunktion ist nicht zwangsläufig ununmkehrbar. Im Speziellen gibt es umkehrbare Hashfunktionen.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Haudruferzappeltnoch“ ()

    Haudruferzappeltnoch schrieb:

    Man muss außerdem beachten eine Hashfunktion ist nicht zwangsläufig ununmkehrbar.
    Mit welchem Hintergrund?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ich würde mal kühn behaupten, die BCrypt-Schreiber haben diesen Default-Case falsch implementiert, sie hätten da einen Default-Salt-Wert nehmen müssen.
    Und da haben wir wieder das allgemeine Problem: Es wird viel zu wenig getestet.
    Es werden keine Pflichtenhefte geschrieben, es wird kein Code-Review durchgeführt und schon gar nicht mit mehr als zwei Augen.
    Hm. :/
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Haudruferzappeltnoch schrieb:

    Bei einem Default muss der folglich jedem bekannt sein.
    Jawoll, Mister Holmes. ;)
    Zumindest an diesem einen Rechner.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Was aber bei Salt eh anscheinend gewollt ist, dass es jeder sehen kann.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

Facebook
Telefonspende