MySQL-Benutzerkonten sind in der Tabelle user der Datenbank mysql aufgelistet. Jedem MySQL-Konto wird ein Passwort zugewiesen. Allerdings wird in der Spalte Password der Tabelle user nicht die unverschlüsselte Version des Passworts gespeichert, sondern ein auf dessen Basis berechneter Hash-Wert. Die Hash-Werte für Passwörter werden mit der Funktion PASSWORD() berechnet.

MySQL verwendet die Passwörter in zwei Phasen der Client/Server-Kommunikation:

Mit anderen Worten benutzt der Server die Hash-Werte während der Authentifizierung, wenn der Client erstmals eine Verbindung herzustellen versucht. Dagegen erzeugt der Server Hash-Werte, wenn ein verbundener Client die Funktion PASSWORD() aufruft oder eine GRANT- oder SET PASSWORD-Anweisung benutzt, um ein Passwort einzustellen oder zu ändern.

Die Methode für das Passwort-Hashing wurde in MySQL 4.1 geändert, um mehr Sicherheit zu bieten und das Risiko zu verringern, dass Passwörter abgefangen werden. Allerdings wird diese neue Methode nur von Servern und Clients unter MySQL 4.1 und höher verstanden, was Kompatibilitätsprobleme verursachen kann. Ein Client unter Version 4.1 oder höher kann mit einem Server unter einer Version vor 4.1 eine Verbindung herstellen, da der Client sowohl die alte als auch die neue Hashing-Methode versteht. Allerdings kann es zu Schwierigkeiten kommen, wenn ein Client unter einer alten Version mit einem Server unter Version 4.1 oder höher einen Verbindungsaufbau probiert. So kann eine Verbindung, die ein mysql-Client unter Version 3.23 mit einem Server unter 5.1 herzustellen versucht, mit der folgenden Fehlermeldung fehlschlagen:

shell> mysql -h localhost -u root
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

Ein anderes häufiges Beispiel für dieses Phänomen tritt auf, wenn nach einem Upgrade auf MySQL 4.1 versucht wird, die ältere PHP-mysql-Erweiterung zu verwenden. (Siehe auch Abschnitt 24.3.1, „Allgemeine Probleme mit MySQL und PHP“.)

Im Folgenden werden die Unterschiede zwischen der alten und der neuen Passwortmethode beschrieben. Ferner werden wir erläutern, was Sie tun müssen, wenn Sie Ihren Server unter Beibehaltung der Abwärtskompatibilität mit Clients unter Versionen vor 4.1 aktualisieren wollen. Zusätzliche Informationen finden Sie unter Abschnitt A.2.3, „Client does not support authentication protocol“. Diese Hinweise sind besonders wichtig für PHP-Programmierer, die ihre MySQL-Datenbanken von einer Version vor 4.1 auf Version 4.1 oder höher migrieren.

Hinweis: In der Beschreibung wird das Verhalten von Version 4.1 und höher dem Verhalten älterer Versionen gegenübergestellt. Tatsächlich aber wurde das hier beschriebene Verhalten erst mit Version 4.1.1 implementiert. MySQL 4.1.0 ist eine „merkwürdige“ Version, denn sie weist eine etwas andere Methode auf als die Versionen 4.1.1 und folgende. Die Unterschiede zwischen 4.1.0 und den neueren Versionen sind im MySQL 5.0 Reference Manual ausführlicher beschrieben.

In MySQL vor Version 4.1 sind die Passwort-Hashes, die mit der Funktion PASSWORD() berechnet werden, 16 Bytes lang. Solche Hashes sehen etwa so aus:

mysql> SELECT PASSWORD('mypass');
+--------------------+
| PASSWORD('mypass') |
+--------------------+
| 6f8c114b58f2ce9e   |
+--------------------+

Die Spalte Password in der Tabelle user (in der diese Hashes gespeichert werden) ist bei MySQL vor Version 4.1 ebenfalls 16 Bytes lang.

Seit MySQL 4.1 erzeugt die geänderte PASSWORD()-Funktion einen 41 Byte langen Hash-Wert:

mysql> SELECT PASSWORD('mypass');
+-------------------------------------------+
| PASSWORD('mypass')                        |
+-------------------------------------------+
| *6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |
+-------------------------------------------+

Entsprechend muss die Spalte Password in der Tabelle user ebenfalls 41 Byte lang sein, um diese Werte aufnehmen zu können:

Die verbreiterte Password-Spalte kann Passwort-Hashes im alten wie im neuen Format aufnehmen. Das Format eines gegebenen Hash-Wertes kann auf zweierlei Art und Weise bestimmt werden:

Das längere Format für Passwort-Hashes hat bessere kryptografische Eigenschaften, und die auf langen Hashes basierende Clientauthentifizierung ist sicherer als die alte, auf kurzen Hashes basierende Methode.

Die Unterschiede zwischen kurzen und langen Passwort-Hashes sind sowohl dafür, wie der Server Passwörter während der Authentifizierung verwendet, als auch dafür relevant, wie er Passwort-Hashes für verbundene Clients erzeugt, die Operationen zur Passwortänderung durchführen.

Die Breite der Password-Spalte wirkt sich auf die Art und Weise aus, wie der Server Passwort-Hashes während der Authentifizierung benutzt:

Auch bei Konten mit kurzen Hashes ist der Authentifizierungsvorgang eigentlich ein bisschen sicherer für Clients unter 4.1 und höher als bei älteren Clients. Aus sicherheitstechnischer Sicht sieht der Übergang von der geringsten zur höchsten Sicherheit wie folgt aus:

Die Art und Weise, wie der Server Passwort-Hashes für verbundene Clients erzeugt, wird von der Breite der Spalte Password und von der Option --old-passwords beeinflusst. Ein Server unter 4.1 oder höher erzeugt lange Hashes nur, wenn bestimmte Bedingungen erfüllt werden: Die Spalte Password muss breit genug für lange Werte sein, und die Option --old-passwords darf nicht angegeben worden sein. Diese Bedingungen gelten wie folgt:

Der Zweck der Option --old-passwords besteht darin, Ihnen die Beibehaltung der Abwärtskompatibilität mit Clients unter Versionen vor 4.1 unter solchen Umständen zu ermöglichen, unter denen der Server andernfalls lange Passwort-Hashes erzeugen würde. Die Option beeinträchtigt die Authentifizierung nicht (denn Clients unter 4.1 und höher können weiterhin Konten mit langen Passwort-Hashes verwenden), verhindert aber die Erstellung eines langen Passwort-Hashes in der Tabelle user als Folge einer passwortändernden Operation. Andernfalls könnte das Konto nicht länger von Clients unter einer alten MySQL-Version verwendet werden. Ohne die Option --old-passwords wäre das folgende, nicht wünschenswerte Szenario möglich:

Dieses Szenario veranschaulicht, dass es, wenn Sie Clients unter Versionen vor 4.1 unterstützen müssen, gefährlich ist, einen Server unter 4.1 oder höher ohne die Option --old-passwords zu verwenden. Bei Ausführung des Servers mit der Option --old-passwords erzeugen passwortändernde Optionen keine langen Passwort-Hashes, d. h. Konten geraten für ältere Clients nicht außer Reichweite. (Diese Clients können sich nicht versehentlich selbst aussperren, indem sie ihr Passwort ändern und am Ende einen langen Passwort-Hash erhalten.)

Der Nachteil der Option --old-passwords besteht darin, dass alle von Ihnen erstellten oder geänderten Passwörter kurze Hashes verwenden – auch die Clients unter Version 4.1 und höher. Auf diese Weise verlieren Sie die zusätzliche Sicherheit, die lange Passwort-Hashes bieten. Wenn Sie ein Konto erstellen wollen, das einen langen Hash hat (etwa zur Verwendung durch Clients unter 4.1), dann müssen Sie dies tun, während der Server ohne die Option --old-passwords läuft.

Die folgenden Szenarios sind bei Ausführung eines Servers unter Version 4.1 möglich:

Szenario 1: Kurze Password-Spalte in der Tabelle user

Szenario 2: Lange Password-Spalte, Server wurde nicht mit der Option --old-passwords gestartet

Wie weiter oben beschrieben, besteht die Gefahr bei diesem Szenario darin, dass Konten, die einen kurzen Passwort-Hash aufweisen, für Clients unter einer Version vor 4.1 unzugänglich werden. Eine Änderung am Passwort eines solchen Kontos, die mithilfe von GRANT, PASSWORD() oder SET PASSWORD vorgenommen wird, führt dazu, dass das Konto einen langen Passwort-Hash erhält. Von diesem Punkt an kann ein Client unter einer Version vor 4.1 eine Authentifizierung über dieses Konto erst dann durchführen, wenn er seinerseits auf 4.1 oder höher aktualisiert wurde.

Um dieses Problem zu beseitigen, können Sie das Passwort auf eine spezielle Art und Weise ändern. So verwenden Sie etwa normalerweise SET PASSWORD wie folgt, um ein Kontopasswort zu ändern:

SET PASSWORD FOR 'some_user'@'some_host' = PASSWORD('mypass');

Um das Passwort zu ändern, aber einen kurzen Hash zu erstellen, verwenden Sie stattdessen die Funktion OLD_PASSWORD():

SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('mypass');

OLD_PASSWORD() ist in Situationen nützlich, in denen Sie ausdrücklich einen kurzen Hash erzeugen wollen.

Szenario 3: Lange Password-Spalte, Server unter Version 4.1 oder höher wurde mit der Option --old-passwords gestartet

In diesem Szenario können Sie keine Konten mit langen Passwort-Hashes erstellen, weil die Option --old-passwords deren Erzeugung verhindert. Ferner wird, wenn Sie ein Konto mit einem langem Hash vor Verwendung der Option --old-passwords erstellen, eine Änderung dieses Passworts bei aktivierter Option --old-passwords dazu führen, dass das Konto ein kurzes Passwort erhält, wodurch die sicherheitstechnischen Vorzüge eines langen Hashs verloren gehen.

Die Nachteile dieser Szenarien lassen sich wie folgt zusammenfassen:

In Szenario 1 müssen Sie auf die Vorteile langer Hashes verzichten, die eine sicherere Authentifizierung ermöglichen.

In Szenario 2 werden Konten mit kurzen Hashes für Clients unter einer Version vor 4.1 unzugänglich, wenn sie ihre Passwörter ändern, ohne die Option OLD_PASSWORD() ausdrücklich zu verwenden.

In Szenario 3 verhindert --old-passwords, dass Konten mit kurzen Hashes unzugänglich werden; passwortändernde Operationen setzen allerdings Konten mit langen Hashes auf kurze Hashes herunter, was Sie auch nicht ändern können, solange die Option --old-passwords gültig bleibt.