MySQL: Ein Feld mit md5 verschlüsselt übertragen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • MySQL: Ein Feld mit md5 verschlüsselt übertragen

    Hallo,

    soweit klappt alles ganz gut. Ich habe mich jetzt an einem Login versucht und dort kann man neue User anlegen. Ich würde den Wert $Kennwort gerne mit md5 verschlüsseln. Ich habe einiges versucht, jedoch bringt er mir einen Fehler, wenn ich md5 voren dazuschreibe. Ohne md5 trägt er den User ganz ordentlich ein, jedoch mit Kennwort im Klartext. Meine Frage: Wie muss die Abfrage aussehen, bzw. wo muss ich das md5 dazwischensetzen, damit es mir das Kennwort md5-verschlüsselt einträgt?

    Quellcode

    1. $query = "insert into admin values
    2. ('" . $Nickname . "', '" . $Kennwort . "', '" . $Nachname . "', '" . $Vorname . "')";


    Gruß tron
  • ah, ok sorry. Hier ist die Tabellenstruktur:

    Quellcode

    1. CREATE TABLE admin (
    2. Id Int(11) NOT NULL auto_increment,
    3. Nickname VarChar(50) NOT NULL default '',
    4. Kennwort VarChar(50) NOT NULL default '',
    5. Nachname VarChar(50) NOT NULL default '',
    6. Vorname VarChar(50) NOT NULL default '',
    7. PRIMARY KEY (Id)
    8. );


    Es ist ein Parse-Error in Zeile

    Die ganze Datei sieht so aus:

    Quellcode

    1. <?php
    2. include ("checkuser.php");
    3. ?>
    4. <?php include ("./header.php"); ?>
    5. <?php include ("./navi.php"); ?>
    6. <?php include ("./adminnavi.php"); ?>
    7. <?php include ("./db.php"); ?>
    8. <?php
    9. // kurze Variablennamen erstellen
    10. $Nickname = $_POST['Nickname'];
    11. $Kennwort = $_POST['Kennwort'];
    12. $Nachname = $_POST['Nachname'];
    13. $Vorname = $_POST['Vorname'];
    14. if (!$Nickname || !$Kennwort || !$Nachname || !$Vorname) {
    15. echo 'Sie haben nicht alle notwendigen Details eingegeben.<br />'
    16. . 'Bitte gehen Sie zurück und versuchen es noch einmal.';
    17. exit;
    18. }
    19. if (!get_magic_quotes_gpc()) {
    20. $Nickname = addslashes($Nickname);
    21. $Kennwort = addslashes($Kennwort);
    22. $Nachname = addslashes($Nachname);
    23. $Vorname = addslashes($Vorname);
    24. }
    25. if (mysqli_connect_errno()) {
    26. echo 'Fehler: Verbindung zur Datenbank nicht möglich. Versuchen Sie es zu einem späteren Zeitpunkt nochmal.';
    27. exit;
    28. }
    29. $query = "insert into admin values
    30. ('" . $Nickname . "', '" . $Kennwort . "', '" . $Nachname . "', '" . $Vorname . "')";
    31. $result = $db->query($query);
    32. if ($result)
    33. echo '<br />';
    34. echo $db->affected_rows . ' <img src="img/ok.jpg" border="0"> Der User <font color=#FF0000>"' . $Nickname . '"</font> wurde erfolgreich in die Datenbank eingetragen.<br /><br />';
    35. $db->close();
    36. ?>
    37. <?php include ("./footer.php"); ?>
    Alles anzeigen


    Ich dachte mir, das md5 kommt irgendwie in Zeile 33 vor $Kennwort.

    Gruß tron
  • Hi BennyBunny,

    danke, Dein Code ist wirklich kürzer und übersichtlicher. Ich habe mein Problem gelöst und zwar so:

    Quellcode

    1. $Kennwort = md5 ($value["Kennwort"]);
    2. $query = "INSERT INTO admin VALUES ('Id', '$Nickname', '$Kennwort', '$Nachname', '$Vorname')";
    3. $result = $db->query($query);


    Das funktioniert prima :)

    Gruß tron
  • Danke für all die Tipps. So funktioniert es jetzt und auch das Kennwort wird richtig verschlüsselt. addslashes() bei Kennwort habe ich rausgemacht:

    Quellcode

    1. $Kennwort = md5 ($Kennwort);
    2. $query = "INSERT INTO admin VALUES ('Id', '$Nickname', '$Kennwort', '$Nachname', '$Vorname')";
    3. $result = $db->query($query);


    Gruß tron
  • Und wieder ein Thread, den ich gern entstauben mag. O-)

    Alles ist schön und wunderprächtig, aber ich mag da doch noch meinen Senf hinzugeben:

    Eine Verschlüsselung allein durch md5 ist heutzutage nicht gerade ratsam, da es mittlerweile genügend Projekte gibt, die Rainbowtables ins Netz stellen. md5 ist zwar eine Einweg-Codierung, aber was nützt das, wenn alle halbwegs üblichen Passwörter bereits in einer Datenbank auch als md5-String verfügbar sind?
    Aus diesem Grund verwendet man heutzutage besser Salted-Hash-Funktionen, also meinetwegen auch md5, bei dem jedoch vorher dem Passwort ein zufällig ausgewählter String hinzugefügt wird.
    "hanswurst" wird vielleicht häufiger als Passwort verwendet und findet sich mit Sicherheit auch in einer Rainbow-Table. - "hanswurstabcdef" allerdings dürfte nicht in solchen Tabellen auftauchen. Da nützt es auch nichts, wenn ein Angreifer weiß, daß dem PW abcdef hinzugefügt wurde.
    Und um die Sache perfekt zu gestalten, kann man auch ohne https das Passwort sicher übertragen, indem es bereits clientseitig per javascript vor dem Abschicken umgewandelt wird:

    aktuell.de.selfhtml.org/artikel/javascript/md5/index.htm

    ----snipp----

    Dann noch zwei Anmerkungen:
    ich seh immer wieder auch hier ne separate php-Zeile, in der dem Passwort md5() aufgefropft wird. md5() versteht mysql aber auch selbst. Da bedarf es keiner separaten Zeile.

    Und zum anderen die Sache mit den addslashes. Ob und wann addslashes notwendig sind oder nicht, hängt von der Serverkonfiguration ab. magic_quotes_gpc sollte einst mal als Erleichterung verstanden werden und fügte jedem Übergabeparameter, gleich ob get, post oder cookie (gpc) , slashes hinzu. Ob dies der Fall ist, läßt sich mit der Funktion get_magic_quotes_gpc() abfragen. - 0 bedeutet aus, 1 für an.
    Sollte es auf 1 stehen, ist ein stripslashes angesagt, um anschließend, egal bei welcher Serverkonfiguration die Daten in die Datenbank per mysql_real_escape_string() sicher maskiert hochzuschubsen.

    Und da man viel labern kann, gibt's hier was zu Bestätigung
    php.net - mysql_real_escape_string - Beispiel #3 Optimale Vorgehensweise zur Querybehandlung
    Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Jeder glaubt, er hätte genug davon.
    --------------------------------------------------(Rene Descartes)
  • Stimmt, im Prinzip ist doppelt gemoppeltes sha1 genauso sicher.
    Wenn sich diese Vorgehensweise allerdings einbürgern würde, dann würden die Rainbow-Table Betreiber einfach ein weiteres Feld zu ihren bisherigen Klartext -> md5() bzw. ->sha1() Tabellen packen und all jene Werte nochmal pauschal durchrechnen. Sowas muß man bei einem hinzugefügten Zufalls-String nicht befürchten.
    Naja, Hauptsache ist imho, daß die Leute nicht glauben mit einmal md5 wär das Thema Sicherheit erledigt.
    Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Jeder glaubt, er hätte genug davon.
    --------------------------------------------------(Rene Descartes)
  • Tipp: Salted-Hashes dynamisch verwenden, sprich z.B. den Benutzernamen als Salt nehmem, um das Passwort damit und mit sha1 (was übrigens auch bereits mehr oder weniger geknackt wurde) verschlüsseln - dann wirds langsam nur noch sehr schwer zu knacken, wohingegen sha1(sha1()) keine große Herausforderung für Anbieter dieser beliebten Tabellen ist...
  • Schau, es geht doch um was grundsätzliches: Deine Kombination ist für JEDEN errechenbar, ergo mit steigener Rechenleistung wird in 1-2 Jahren sowieso jeder Pups so eine Tabelle anlegen können. Meine Variante setzt mehr Daten voraus, die im Prinzip - von dem GAU eines Datenklaus mal abgesehen - nicht einsehbar sein können und somit eine relative Sicherheit bieten, die auch in die Zukunft reicht.

    Grundsätzlich ist das für die 0815-Anwendungen die 99% der Nutzer hier programmieren aber sowieso völlig unerheblich.
  • Naja, dann muß man aber auch noch unterscheiden zwischen den Systemen, die ein einheitliches Salt für alle PW nehmen, und diejenigen, die für jedes PW ein eigenes Salt generieren.
    Nach einem erfolgreichen Forumsangriff kennt ein Cracker die kodierten PWs und das einheitliche Salt oder aber die jeweils separat generierten Salts für jeden User. Sollte die Rechenleistung schon soweit steigen, daß ein Einzelner eine recht nutzbare Rainbow-Table erzeugen kann, dann könnte er bei einem einheitlichen Salt auch "mal eben" eine Rainbowtable individuell für das gecrackte Forum erzeugen. (gilt z.B. beim Woltlab)

    Ist das Salt aber stets verschieden, dann müßte der Angreifer für jeden einzelnen User die gesamte Rainbowtable mit dem individuellen Salt runterrattern lassen. Bei meinen eigenen Anwendungen verwende ich diesen Weg tatsächlich. Fällt mir ja kein Zacken aus der Krone, für jeden User nen individuellen Salt-String zu generieren...

    Würde hingegen das verschlüsselte PW bei einem bekannten Forensystem z.B. aus sha1(sha1()) bestehen, dann kann man Wetten abschließen, wieviele Tage es braucht, bis die ersten Rainbowtables mit eben diesen Werten im Netz auftauchen. Es ist halt eben nur solange sicher, solange dieses System nicht verbreitet ist und sich keine Grüppchen bilden, die ein Interesse daran haben, eine solche Tabelle zu erstellen.
    Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Jeder glaubt, er hätte genug davon.
    --------------------------------------------------(Rene Descartes)