5.4.9 Hashage de mots de passe en MySQL 4.1

Les comptes utilisateurs de MySQL sont stockés dans la table user de la base mysql . Chaque compte MySQL a un mot de passe, même si ce qui est stocké dans la colonne Password de la table user n'est pas la version texte du mot de passe, mais un hash calculé à partir du mot de passe. La transformation est faîte avec la fonction PASSWORD() .

• Premièrement, lorsqu'un client tente de se connecter au serveur, il y a une identification initial au cours de laquelle le client doit présenter un mot de passe dont la valeur hashée est la même que celle qui est présente dans la table d'utilisateur, pour le compte que le client veut utiliser.
• Ensuite, après la connexion du client, il peut modifier ou changer le mot de passe pour les utilisateurs du serveur (s'il a les droits nécessaires pour cela). Le client peut faire cela avec la fonction PASSWORD() , pour générer un autre mot de passe, ou en utilisant les commandes GRANT ou SET PASSWORD .

Le mécanisme de modifications des mots de passe a été modifié en MySQL 4.1, pour apporter une sécurité accrue et réduire le risque de vol de mots de passe. Cependant, ce nouveau mécanisme ne peut être compris que de la version 4.1, et des clients MySQL 4.1, ce qui pose des problèmes de compatibilité. Un client 4.1 peut se connecter sur un serveur pre-4.1, car le client comprend les deux méthodes de hashage, ancienne et nouvelle. Cependant, un client pre-4.1 qui tente se de connecter à un serveur 4.1 aura des problèmes. Par exemple, si un client mysql 4.0 essaie de se connecter au serveur 4.1, il va recevoir l'erreur suivante :

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

Note : Cette discussion compare les comportements des versions 4.1 avec les versions d'avant (dites pre-4.1), mais le comportement 4.1 ne commence en réalité qu'avec la version 4.1.1. MySQL 4.1.0 est une version ``marginale'' car elle a un mécanisme légèrement différent de celui qui est implémenté en versions 4.1.1 et plus récent. Les différences entre les versions 4.1.0 et les versions plus récentes sont décrites ultérieurement.

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

mysql> SELECT PASSWORD('mypass');
+-----------------------------------------------+
| PASSWORD('mypass')                            |
+-----------------------------------------------+
| *43c8aa34cdc98eddd3de1fe9a9c2c2a9f92bb2098d75 |
+-----------------------------------------------+

• Si vous faites une nouvelle installation de MySQL 4.1, la colonne Password fera automatiquement 41 octets.
• Si vous mettez à jour une ancienne installation, il est recommandé d'utiliser le script mysql_fix_privilege_tables pour mettre à jour la taille de la colonne Password , de 16 à 41 octets. Le script ne modifie pas les valeurs elles-mêmes, qui restent à 16 octets de long.

Une colonne Password élargie peut stocker les mots de passe dans les deux formats, ancien et nouveau. Le format d'un hash de mot de passe peut être déterminer de deux manières :

• La différence principale et évidente est la taille : 16 octets et 41 octets.
• La seconde différence est que les hashs au nouveau format commencent par le caractère '*' , alors que l'ancien format ne le fait pas.

Plus le hash du mot de passe est long, meilleure sont ses caractéristiques de chiffrement, et l'identification des client, basée sur des hash longs, est plus sécuritaire que l'ancienne méthode, dont les hashs sont plus courts.

La façon de traiter le hash de mot de passe durant la phase d'identification diffère, en fonction de la taille de la colonne Password :

• Si la colonne est étroite, l'identification par hash court sera utilisée.
• Si la colonne est large, elle peut contenir des hashs longs ou courts, et le serveur peut utiliser l'un ou l'autre des formats :
  • Les clients pre-4.1 peuvent se connecter, car ils connaissent l'ancien mécanisme de hashing, et ils peuvent s'identifier pour les comptes qui ont des mots de passe court.
  • Les clients 4.1 peuvent s'identifier pour les comptes qui ont des hash longs ou courts.

Pour les comptes à hash court, l'identification est un peut plus sécuritaire pour les clients 4.1 que pour les anciens clients. En terme de sécurité, le gradient de sécurité du plus faible au meilleur est :

• Les clients pre-4.1 s'identifiant avec un hash court
• Les clients 4.1 s'identifiant avec un hash court
• Les clients 4.1 s'identifiant avec un hash long

• La colonne Password doit être assez grande pour acceuillir des hashs de mot de passe longs (41 octets). Si la colonne n'a pas été mise à jour, et qu'elle a toujours la taille de 16 octets, le serveur le remarque, et générera des hashs de mots de passe courts lorsque le client va modifier son mot de passe avec PASSWORD() , GRANT ou SET PASSWORD . Ce comportement survient si vous avez mis à jour le serveur en version 4.1, mais omis d'utiliser le script mysql_fix_privilege_tables pour élargir la colonne Password .
• Si la colonne Password est suffisamment grande, elle peut stocker un mot de passe long ou court. Dans ce cas, PASSWORD() , GRANT et SET PASSWORD vont générer des hashs longs, à moins que le serveur n'ait été lancé avec l'option --old-passwords . Cette option force le serveur à utiliser les hashs courts.

• Un ancient client se connecter sur un compte, avec un hash court.
• Le client change le mot de passe. Sans l'option --old-passwords , cela conduit à la création d'un hash long.
• Lors de la prochaine connexion, le client pre-4.1 ne peut plus se connecter, car le compte requiert désormais le nouveau mécanisme d'identification. Une fois que le hash long est dans la table user , seuls les clients 4.1 peuvent l'utiliser, car les clients pre-4.1 ne le comprennent pas.

Ce scénario montre combien il est dangeureux d'utiliser un serveur 4.1 sans l'option --old-passwords si vous devez supporter des clients pre-4.1. En utilisant l'option --old-passwords sur le serveur, les opérations de modification de mots de passe ne génèrent pas de hashs longs, et les utilisateurs ne se barreront pas l'accès par inadvertence.

Les scénarios suivants sont possibles avec un serveur 4.1 :

• Seuls, les hashs courts peuvent être stockés dans la colonne Password .
• Le serveur utilise uniquement les hashs courts pour les identifications.
• Pour les clients connectés, la génération de mot de passe avec PASSWORD() , GRANT ou SET PASSWORD utilise les mots de passe courts uniquement. Toute modification de compte entraine la création d'un hash court.
• L'option --old-passwords peut être utilisée, mais est superflue, car la colonne Password courte impose la manipulation de hashs courts de toutes manières.

• les hashs courts et longs peuvent être stockés dans la colonne Password .
• Les clients 4.1 peuvent s'identifier sur leur compte avec des hashs courts ou longs.
• Les clients pre-4.1 peuvent s'identifier sur leur compte avec des hashs courts.
• Pour les clients connectés, la génération de mot de passe avec PASSWORD() , GRANT ou SET PASSWORD utilise les mots de passe longs uniquement. Toute modification de compte entraine la création d'un hash long.

Pour régler ce problème, vous pouvez modifier le mot de passe d'une manière spéciale. Par exemple, normalement, vous pouvez utiliser la commande SET PASSWORD comme ceci pour modifier un mot de passe :

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

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

• les hashs courts et longs peuvent être stockés dans la colonne Password .
• Les clients 4.1 peuvent s'identifier sur leur compte avec des hashs courts ou longs. Notez qu'il n'est alors possible de créer des hashs longs si le serveur utilise --old-passwords ).
• Les clients pre-4.1 peuvent s'identifier sur leur compte avec des hashs courts.
• Pour les clients connectés, la génération de mot de passe avec PASSWORD() , GRANT ou SET PASSWORD utilise les mots de passe courts uniquement. Toute modification de compte entraine la création d'un hash long.

Les inconvénients de ces scénario sont les suivants :

Scenario 2) Les comptes avec des mots de passe courts sont inaccessibles aux clients pre-4.1 si vous modifiez leur mot de passe sans utiliser la fonction OLD_PASSWORD() .

Sommaire :

• Implications des modifications de mot de passe pour les applications
• Gestion des mots de passe en MySQL 4.1.0