308 votes

Quel type de données utiliser pour le champ du mot de passe haché et quelle longueur ?

Je ne suis pas sûr du fonctionnement du hachage de mot de passe (je l'implémenterai plus tard), mais je dois créer le schéma de la base de données maintenant.

Je pense limiter les mots de passe à 4-20 caractères, mais si je comprends bien, après le cryptage, la chaîne de hachage sera de longueur différente.

Alors, comment stocker ces mots de passe dans la base de données ?

0 votes

Voir également la page de l'Openwall Cadre de hachage de mots de passe en PHP (PHPass). Il est portable et renforcé contre un certain nombre d'attaques courantes sur les mots de passe des utilisateurs. L'auteur du framework (SolarDesigner) est le même qui a écrit John The Ripper et siège en tant que juge dans le Concours de hachage de mots de passe . Donc il connaît une chose ou deux sur les attaques sur les mots de passe.

3 votes

Ne fixez pas de limite supérieure pour vos mots de passe. Vous les hachurez, il n'y a aucune raison de stockage pour une limite supérieure. Si vous vous inquiétez des attaques DoS utilisant le hachage du mot de passe, 1000 ou 1024 est une limite supérieure raisonnable.

0 votes

Pourquoi limiter la longueur du mot de passe ? Laissez au moins un utilisateur créer un mot de passe de 100 caractères :)

481voto

Bill Karwin Points 204877

Mise à jour : La simple utilisation d'une fonction de hachage n'est pas assez forte pour stocker les mots de passe. Vous devriez lire la réponse de Gilles sur ce fil pour une explication plus détaillée.

Pour les mots de passe, utilisez un algorithme de hachage renforçant les clés comme Bcrypt ou Argon2i. Par exemple, en PHP, utilisez la méthode Fonction password_hash() qui utilise Bcrypt par défaut.

$hash = password_hash("rasmuslerdorf", PASSWORD_DEFAULT);

Le résultat est une chaîne de 60 caractères semblable à la suivante (mais les chiffres varieront, car elle génère un sel unique).

$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

Utiliser le type de données SQL CHAR(60) pour stocker cet encodage d'un hash Bcrypt. Notez que cette fonction n'est pas codée comme une chaîne de chiffres hexadécimaux, nous ne pouvons donc pas la décomposer aussi facilement pour la stocker en binaire.

Les autres fonctions de hachage ont toujours leur utilité, mais pas pour le stockage des mots de passe. Je vais donc conserver la réponse originale ci-dessous, écrite en 2008.


Cela dépend de l'algorithme de hachage que vous utilisez. Le hachage produit toujours un résultat de même longueur, quelle que soit l'entrée. Il est courant de représenter le résultat du hachage binaire en texte, sous la forme d'une série de chiffres hexadécimaux. Vous pouvez également utiliser la fonction UNHEX() pour réduire de moitié une chaîne de chiffres hexadécimaux.

  • MD5 génère une valeur de hachage de 128 bits. Vous pouvez utiliser CHAR(32) ou BINARY(16).
  • SHA-1 génère une valeur de hachage de 160 bits. Vous pouvez utiliser CHAR(40) ou BINARY(20).
  • SHA-224 génère une valeur de hachage de 224 bits. Vous pouvez utiliser CHAR(56) ou BINARY(28).
  • SHA-256 génère une valeur de hachage de 256 bits. Vous pouvez utiliser CHAR(64) ou BINARY(32).
  • SHA-384 génère une valeur de hachage de 384 bits. Vous pouvez utiliser CHAR(96) ou BINARY(48).
  • SHA-512 génère une valeur de hachage de 512 bits. Vous pouvez utiliser CHAR(128) ou BINARY(64).
  • BCrypt génère une valeur de hachage de 448 bits dépendant de l'implémentation. Vous pouvez avoir besoin de CHAR(56), CHAR(60), CHAR(76), BINARY(56) ou BINARY(60).

En 2015, le NIST recommande d'utiliser SHA-256 ou plus pour toutes les applications de fonctions de hachage nécessitant une interopérabilité. Mais le NIST ne recommande pas l'utilisation de ces fonctions de hachage simples pour le stockage sécurisé des mots de passe.

Les algorithmes de hachage de moindre importance ont leur utilité (par exemple en interne dans une application, pas pour l'échange), mais ils sont les suivants connu pour être craquable .

0 votes

Le salage peut être effectué en préfixant une valeur unique (par exemple, le nom d'utilisateur) à chaque mot de passe. Voici un article qui explique pourquoi cela est nécessaire : codinghorror.com/blog/2007/09/rainbow-hash-cracking.html . En bref, il permet de prévenir les tentatives de craquage de mots de passe qui utilisent la méthode d'attaque de l'arc-en-ciel.

57 votes

@Hippo : S'il vous plaît, n'utilisez pas le nom d'utilisateur comme sel. Générez un sel aléatoire par utilisateur.

3 votes

Le sel généré aléatoirement est-il également stocké dans la même ligne de la table ?

15voto

Noah Goodrich Points 12645

Vous pouvez en fait utiliser CHAR (longueur du hachage) pour définir votre type de données pour MySQL, car chaque algorithme de hachage donnera toujours le même nombre de caractères. Par exemple, SHA1 renvoie toujours un nombre hexadécimal de 40 caractères.

1 votes

SHA-1 n'est pas adapté au hachage des mots de passe.

13voto

Dana the Sane Points 7976

Vous trouverez peut-être cet article de Wikipedia sur le salage digne d'intérêt . L'idée est d'ajouter un ensemble de données pour rendre aléatoire votre valeur de hachage ; cela protégera vos mots de passe contre les attaques par dictionnaire si quelqu'un obtient un accès non autorisé aux hachages de mots de passe.

2 votes

C'est effectivement très intéressant (+1), mais cela ne répond pas à la question ! (-1)

5 votes

Oui, mais certainement pertinent dans ce contexte (+1)

10voto

Treb Points 11153

En tant que chaîne de longueur fixe (VARCHAR(n) ou toute autre appellation de MySQL). Un hachage a toujours une longueur fixe de 12 caractères par exemple (selon l'algorithme de hachage utilisé). Ainsi, un mot de passe de 20 caractères sera réduit à un hachage de 12 caractères, et un mot de passe de 4 caractères donnera également un hachage de 12 caractères.

3 votes

Ou quel que soit le nom que lui donne MySQL - MYSQL l'appelle CHAR. Ce type est destiné aux valeurs de longueur fixe. Je pense donc que CHAR est un meilleur type que VARCHAR.

5voto

yfeldblum Points 42613

Les hachages sont une séquence de bits (128 bits, 160 bits, 256 bits, etc., selon l'algorithme). Votre colonne doit être de type binaire, et non de type texte/caractère, si MySQL le permet (le type de données de SQL Server est binary(n) ou varbinary(n) ). Vous devez également saler les hachages. Les sels peuvent être textuels ou binaires, et vous aurez besoin d'une colonne correspondante.

0 votes

Justice a tout à fait raison ici - MySQL stockera ces données sous forme de valeurs numériques et rendra la recherche sur cette colonne beaucoup plus efficace qu'une correspondance de chaîne de caractères. Cependant, les sels ne devraient pas être stockés dans la base de données à côté des données salées - cela élimine la sécurité que les sels fournissent.

6 votes

Les sels sont no secret. Le site sólo secret est le mot de passe. Veillez simplement à ce que chaque nouveau mot de passe reçoive un nouveau sel. Chaque fois que l'utilisateur change son mot de passe, le système doit générer un nouveau sel pour ce mot de passe. Les sels doivent être longs et aléatoires, par exemple 16 octets générés par un PRNG à sécurité cryptographique.

1 votes

@TonyMaro Pas sûr qu'une correspondance de la chaîne de mots de passe au niveau SQL soit une bonne stratégie. En d'autres termes, vous ne devriez pas rechercher un mot de passe dans votre base de données, mais plutôt récupérer l'utilisateur en fonction de son nom d'utilisateur et comparer les mots de passe dans le code, plutôt qu'en SQL.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X