Chris9910: Sichere Passworte für MySQL

Hallo verehrtes Forum,

leider habe ich bei Google zu dem Thema nichts konkretes gefunden:

Welche Richtlinen für Kennwörter gelten für das Datenbank-System MySQL? (gerne auch als Link)
Welche Sonderzeichen darf ich in Passwörtern verwenden?
Wie lang dürfen Passwörter sein?
Benutzernamen dürfen bis zu 16 Zeichen lang sein, aber dürfen sie auch Sonderzeichen beinhalten, wie z.B. $'´`"?

Fragen über Fragen. ;)

Es wäre nett, wenn jemand dazu etwas sagen könnte, denn ich würde mich ungerne durch ein nicht geeignetes Passwort aus meiner Datenbank ausschließen.

Vielen Dank im Voraus.

MfG
Chris

  1. servus Chris9910,

    Welche Richtlinen für Kennwörter gelten für das Datenbank-System MySQL? (gerne auch als Link)

    Vielleicht solltest du dir erst darüber klar werden, dass man keine Passwörter im Klartext speichern sollte, sondern Hashes davon.

    Welche Sonderzeichen darf ich in Passwörtern verwenden?
    Wie lang dürfen Passwörter sein?
    Benutzernamen dürfen bis zu 16 Zeichen lang sein, aber dürfen sie auch Sonderzeichen beinhalten, wie z.B. $'´`"?

    Du darfst jedes erdenkliche Zeichen verwenden. Hauptsache, du sicherst Strings vor dem Speichern ab. Das nennt sich Escaping. In Verbindung mit PHP gibt es zum Beispiel so eine Funktion: [link:http://php.net/manual/de/function.mysql-real-escape-string.php@title=mysql_real_escape_string()]
    Denke aber daran: _Passwörter werden nicht im Klartext gespeichert!_

    Hier noch ein Artikel zum Nachtisch: Kontextwechsel

    henman

    --
    "Sir, we are surrounded!" - "Excellent, we can attack in any direction!"
  2. Tach!

    Welche Richtlinen für Kennwörter gelten für das Datenbank-System MySQL? (gerne auch als Link)
    Welche Sonderzeichen darf ich in Passwörtern verwenden?
    Wie lang dürfen Passwörter sein?

    Ich gehe mal davon aus, dass du MySQLs eigene Benutzerverwaltung meinst. Da die Funktion PASSWORD() einen Hashwert erzeugt, darf das Passwort also ausreichend lang werden. Hash-Funktionen interessieren sich üblicherweise nicht für Zeichen sondern für Bytes. Das merkt man hier deutlich, weil das Ergebnis unterschiedlich ausfällt, wenn man dieselbe Zeichenfolge in unterschiedlichen Kodierungen übergibt (natürlich mit korrektem *_set_charset() vorher).

    Benutzernamen dürfen bis zu 16 Zeichen lang sein, aber dürfen sie auch Sonderzeichen beinhalten, wie z.B. $'´`"?

    Wenn du die C-API verwendest, kannst du vor dem Connect die zu verwendende Zeichenkodierung setzen. PHP zum Beispiel scheint diesbezüglich nichts vorgesehen zu haben. mysqli_init() geht zwar, aber mysqli_option() kennt MYSQL_SET_CHARSET_NAME nicht. Damit schränkt PHP Nutzernamen und Passwörter praktisch auf ASCII ein, wenn man sich nicht auf Default-Konfigurationswerte des Servers verlassen möchte. (Nach einem Connect kann man aber sehr wohl die Zeichenkodierung einstellen - mit mysqli_set_charset() - aber das ist für Nutzername und Passwort zu spät.)

    Es wäre nett, wenn jemand dazu etwas sagen könnte, denn ich würde mich ungerne durch ein nicht geeignetes Passwort aus meiner Datenbank ausschließen.

    Dann teste das doch erstmal mit einer beliebigen Kennung und allen relevanten Kodierungen, beispielsweise an einem Testsystem.

    dedlfix.

    1. Hallo Dedlfix,

      Ich gehe mal davon aus, dass du MySQLs eigene Benutzerverwaltung meinst. Da die Funktion PASSWORD() einen Hashwert erzeugt, darf das Passwort also ausreichend lang werden.

      Ausreichend lang wären dann wohl i.d.R. 32 Zeichen oder?!

      Aber zurück zur PASSWORD()-Funktion:
      Diese zu verwenden liegt wohl am Programmierer der entsprechenden "API", die Einträge in die Tabelle User der Datenbank schreibt. Zum Verständnis für mich: Es kann ja durchaus sein, dass eine Anwendung Passwörter im Klartext speichert(e), wie z.B. Plesk (inzwischen ja nicht mehr) - dort wären Sonderzeichen möglicherweise schädlich oder nicht?!

      Daraus würde sich die Frage ergeben, wie ist man auf der sicheren Seite, wenn man NICHT weiß, ob die Anwendung hashed:
      1. grundsätzlich keine Sonderzeichen vergeben (wäre mir gar nicht so lieb)
      2. Sonderzeichen escapen (zu aufwändig bei Passwortgeneratoren (KeePass))
      3. ? ;)

      Gruß
      Chris

      1. Tach!

        Ich gehe mal davon aus, dass du MySQLs eigene Benutzerverwaltung meinst. Da die Funktion PASSWORD() einen Hashwert erzeugt, darf das Passwort also ausreichend lang werden.
        Ausreichend lang wären dann wohl i.d.R. 32 Zeichen oder?!

        Weitaus länger, so lang wie ein String werden darf, nehme ich an.

        Aber zurück zur PASSWORD()-Funktion:
        Diese zu verwenden liegt wohl am Programmierer der entsprechenden "API", die Einträge in die Tabelle User der Datenbank schreibt.

        Nö, sie ist im Prinzip eine Pflichtveranstaltung, wenn du einen MySQL-Nutzer anlegen willst. (OLD_PASSWORD() und selber hashen außen vor gelassen.)

        Zum Verständnis für mich: Es kann ja durchaus sein, dass eine Anwendung Passwörter im Klartext speichert(e), wie z.B. Plesk (inzwischen ja nicht mehr) - dort wären Sonderzeichen möglicherweise schädlich oder nicht?!

        Wovon reden wir jetzt? Von der MySQL-Benutzerverwaltung oder von einer beliebigen Benutzerverwaltung, die ihre Daten in einer beliebigen MySQL-Tabelle ablegt?

        Daraus würde sich die Frage ergeben, wie ist man auf der sicheren Seite, wenn man NICHT weiß, ob die Anwendung hashed:

        Sicherheit ist keine absolute Veransteltung. Wenn es dir um eine Anwendung geht, musst du deren Regel kennen, ansonsten ist die Frage nach den verwendbaren Zeichen nicht zu beantworten. Selbst mit Vermutungen à la "kleine lateinische Buchstaben sind problemlos verwendbar" kann man daneben liegen. Manche Systeme wollen schließlich nur Zahlen (PINs).

        1. grundsätzlich keine Sonderzeichen vergeben (wäre mir gar nicht so lieb)

        Grundsätzlich möglichst viele der vom jeweiligen System zugelassenen Zeichen verwenden. Die meisten werden sich auf ASCII beschränken, wenn sie Komplikationen mit Zeichenkodierungen vermeiden wollen - sprich, wenn sie ihr System nicht richtig im Griff haben oder sie davon ausgehen müssen, dass deren Kunden ihre Systeme verkorkst konfiguriert haben.

        1. Sonderzeichen escapen (zu aufwändig bei Passwortgeneratoren (KeePass))

        Escapen brauch einen Kontext, für den escapt werden soll.

        1. ? ;)

        Schön lang, schön unregelmäßig.

        dedlfix.

        1. Hi Dedlfix,

          Weitaus länger, so lang wie ein String werden darf, nehme ich an.

          Diese Annahme hatte ich auch einmal. Kurz geschildert: Passwort vergeben, 32 Zeichen lang. War auch möglich, weil es das input-Feld zuließ (keine max-length). Allerdings hatte der "Programmierer" in der Datenbank das Passwortfeld begrenzt auf VARCHAR(8) - Das Ende vom Lied kannst du dir sicher denken. ;)

          Wovon reden wir jetzt? Von der MySQL-Benutzerverwaltung oder von einer beliebigen Benutzerverwaltung, die ihre Daten in einer beliebigen MySQL-Tabelle ablegt?

          Über die MySQL-Benutzerverwaltung, in die z.B. durch die Webserver-Adminoberfläche Plesk Benutzer samt Passwort eingetragen werden. Dieses passiert, wenn ich einen Kunden-Account in Plesk verwalte und dem Kunden eine Datenbank einrichte. Ganz lange Zeit wurden die Passwörter hierfür von Plesk als Klartext eingetragen, seit Bekanntwerden einer Sicherheitslücke (durch eine sql-Injection konnten sämtliche Passwörter ausgelesen werden) nicht mehr.

          Grundsätzlich möglichst viele der vom jeweiligen System zugelassenen Zeichen verwenden.

          Genau - hier wären wir dann wieder bei meiner Ausgangsfrage ... ;)

          Danke für Deine Ideen.

          MfG
          Chris

          1. Tach!

            Wovon reden wir jetzt? Von der MySQL-Benutzerverwaltung oder von einer beliebigen Benutzerverwaltung, die ihre Daten in einer beliebigen MySQL-Tabelle ablegt?
            Über die MySQL-Benutzerverwaltung, in die z.B. durch die Webserver-Adminoberfläche Plesk Benutzer samt Passwort eingetragen werden. Dieses passiert, wenn ich einen Kunden-Account in Plesk verwalte und dem Kunden eine Datenbank einrichte. Ganz lange Zeit wurden die Passwörter hierfür von Plesk als Klartext eingetragen, seit Bekanntwerden einer Sicherheitslücke (durch eine sql-Injection konnten sämtliche Passwörter ausgelesen werden) nicht mehr.

            Hier passt was nicht zusammen. Es kann ja durchaus sein, dass Plesk für seine eigenen Zwecke Klartextpasswörter speichert, aber ein richtiger MySQL-Nutzer hat kein Klartextpasswort. Mit Plesk kann man natürlich nicht nur allein MySQL betrachten, denn Plesk hat da potentiell noch eigene Einschränkungen in seiner Oberfläche eingebaut. Ich sehe auch heute noch Klartextpasswörter in Plesk (11). Vermutlich muss dazu erst der "erweiterte Sicherheitsmodus" eingeschaltet werden, um diese loszuwerden.

            dedlfix.

            1. Hi,

              Hier passt was nicht zusammen. Es kann ja durchaus sein, dass Plesk für seine eigenen Zwecke Klartextpasswörter speichert, aber ein richtiger MySQL-Nutzer hat kein Klartextpasswort.

              Klar, Du hast natürlich recht! Habe ich verwechselt mit der Tabelle "psa".

              Mit Plesk kann man natürlich nicht nur allein MySQL betrachten, denn Plesk hat da potentiell noch eigene Einschränkungen in seiner Oberfläche eingebaut. Ich sehe auch heute noch Klartextpasswörter in Plesk (11).

              Mail-Passwörter werden inzwischen gehashed. :)

              MfG
              Chris