Je ne sais pas comment fonctionne le hachage de mot de passe (l'implémentera plus tard), mais je dois créer un schéma de 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?

Mise à jour: La simple utilisation d'une fonction de hachage n'est pas assez puissante pour stocker des 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 de renforcement des clés comme Bcrypt ou Argon2i. Par exemple, en PHP, utilisez la 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 similaire à la suivante (mais les chiffres varient, car cela génère un sel unique).

$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

Utilisez le type de données SQL CHAR(60)pour stocker cet encodage d'un hachage 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écompresser aussi facilement pour la stocker en binaire.

D'autres fonctions de hachage ont encore des utilisations, mais pas pour stocker des mots de passe, donc je garderai 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 la même longueur, quelle que soit l'entrée. Il est typique de représenter le résultat de hachage binaire dans le texte, comme une série de chiffres hexadécimaux. Ou vous pouvez utiliser la UNHEX()fonction 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épendante de l'implémentation. Vous pourriez avoir besoin de CHAR (56), CHAR (60), CHAR (76), BINARY (56) ou BINARY (60)

Depuis 2015, le NIST recommande d'utiliser SHA-256 ou supérieur pour toutes les applications de fonctions de hachage nécessitant une interopérabilité. Mais le NIST ne recommande pas d'utiliser ces fonctions de hachage simples pour stocker les mots de passe en toute sécurité.

Les algorithmes de hachage moindres ont leurs utilisations (comme internes à une application, pas pour l'échange), mais ils sont connus pour être crackables .

Vous pouvez réellement utiliser CHAR(longueur de hachage) pour définir votre type de données pour MySQL car chaque algorithme de hachage évaluera toujours le même nombre de caractères. Par exemple, SHA1renvoie toujours un nombre hexadécimal de 40 caractères.

Utilisez toujours un algorithme de hachage de mot de passe: Argon2 , scrypt , bcrypt ou PBKDF2 .

Argon2 a remporté le concours de hachage de mot de passe 2015. Scrypt , bcrypt et PBKDF2 sont des algorithmes plus anciens qui sont considérés comme moins préférés maintenant, mais toujours fondamentalement solides, donc si votre plate-forme ne prend pas encore en charge Argon2, il est acceptable d'utiliser un autre algorithme pour l'instant.

Ne stockez jamais un mot de passe directement dans une base de données. Ne le cryptez pas non plus: sinon, si votre site est piraté, l'attaquant obtient la clé de décryptage et peut donc obtenir tous les mots de passe. Les mots de passe DOIVENT être hachés .

Un hachage de mot de passe a des propriétés différentes d'un hachage de table de hachage ou d'un hachage cryptographique. N'utilisez jamais un hachage cryptographique ordinaire tel que MD5, SHA-256 ou SHA-512 sur un mot de passe. Un algorithme de hachage de mot de passe utilise un sel , qui est unique (non utilisé pour un autre utilisateur ou dans la base de données de quelqu'un d'autre). Le sel est nécessaire pour que les attaquants ne puissent pas simplement pré-calculer les hachages des mots de passe courants: avec un sel, ils doivent recommencer le calcul pour chaque compte. Un algorithme de hachage de mot de passe est intrinsèquement lent - aussi lent que possible. La lenteur blesse beaucoup plus l'attaquant que vous car l'attaquant doit essayer de nombreux mots de passe différents. Pour plus d'informations, consultez Comment hacher en toute sécurité les mots de passe .

Un hachage de mot de passe code quatre informations:

• Un indicateur de l'algorithme utilisé. Cela est nécessaire pour l' agilité : les recommandations cryptographiques changent avec le temps. Vous devez pouvoir passer à un nouvel algorithme.
• Un indicateur de difficulté ou de dureté. Plus cette valeur est élevée, plus le calcul est nécessaire pour calculer le hachage. Cela devrait être une valeur de configuration constante ou globale dans la fonction de changement de mot de passe, mais elle devrait augmenter avec le temps à mesure que les ordinateurs s'accélèrent, vous devez donc vous souvenir de la valeur de chaque compte. Certains algorithmes ont une seule valeur numérique, d'autres y ont plus de paramètres (par exemple pour régler séparément l'utilisation du CPU et l'utilisation de la RAM).
• Le sel. Étant donné que le sel doit être unique au monde, il doit être stocké pour chaque compte. Le sel doit être généré de manière aléatoire à chaque changement de mot de passe.
• Le hachage proprement dit, c'est-à-dire la sortie du calcul mathématique dans l'algorithme de hachage.

De nombreuses bibliothèques incluent une fonction de paire qui regroupe commodément ces informations en une seule chaîne: une qui prend l'indicateur d'algorithme, l'indicateur de dureté et le mot de passe, génère un sel aléatoire et renvoie la chaîne de hachage complète; et celui qui prend un mot de passe et la chaîne de hachage complète comme entrée et renvoie un booléen indiquant si le mot de passe était correct. Il n'y a pas de norme universelle, mais un codage commun est

$ algorithme $ paramètres $ sel $ sortie

où algorithmest un nombre ou une chaîne alphanumérique courte codant le choix de l'algorithme, parametersest une chaîne imprimable et saltet outputsont codés en Base64 sans se terminer =.

16 octets suffisent pour le sel et la sortie. (Voir par exemple les recommandations pour Argon2 .) Encodé en Base64, c'est 21 caractères chacun. Les deux autres parties dépendent de l'algorithme et des paramètres, mais 20 à 40 caractères sont typiques. Cela représente un total d' environ 82 caractères ASCII ( CHAR(82), et pas besoin d'Unicode), auxquels vous devez ajouter une marge de sécurité si vous pensez qu'il sera difficile d'agrandir le champ plus tard.

Si vous codez le hachage dans un format binaire, vous pouvez le réduire à 1 octet pour l'algorithme, 1 à 4 octets pour la dureté (si vous codez en dur certains des paramètres) et 16 octets chacun pour le sel et la sortie , pour un total de 37 octets. Disons 40 octets ( BINARY(40)) pour avoir au moins deux octets de rechange. Notez qu'il s'agit d'octets 8 bits, pas de caractères imprimables, en particulier le champ peut inclure des octets nuls.

Notez que la longueur du hachage est complètement indépendante de la longueur du mot de passe.

Vous trouverez peut-être utile cet article Wikipedia sur le salage . L'idée est d'ajouter un ensemble de données pour randomiser votre valeur de hachage; cela protégera vos mots de passe des attaques par dictionnaire si quelqu'un obtient un accès non autorisé aux hachages de mot de passe.

En tant que chaîne de longueur fixe (VARCHAR (n) ou comme MySQL l'appelle). Un hachage a toujours une longueur fixe, par exemple de 12 caractères (selon l'algorithme de hachage que vous utilisez). Ainsi, un mot de passe de 20 caractères serait réduit à un hachage de 12 caractères, et un mot de passe de 4 caractères donnerait également un hachage de 12 caractères.

Vous devez utiliser TEXT(stocker un nombre illimité de caractères) pour des raisons de compatibilité ascendante. Les algorithmes de hachage (doivent) devenir plus forts au fil du temps et donc ce champ de base de données devra prendre en charge plus de caractères au fil du temps. De plus, selon votre stratégie de migration, vous devrez peut-être stocker des hachages nouveaux et anciens dans le même champ, il n'est donc pas recommandé de fixer la longueur à un type de hachage.

Cela dépend vraiment de l'algorithme de hachage que vous utilisez. La longueur du mot de passe a peu à voir avec la longueur du hachage, si je me souviens bien. Recherchez les spécifications de l'algorithme de hachage que vous utilisez, exécutez quelques tests et tronquez juste au-dessus.

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 SQL Server est binary(n)ou varbinary(n)). Vous devez également saler les hachis. Les sels peuvent être textuels ou binaires, et vous aurez besoin d'une colonne correspondante.

J'ai toujours testé pour trouver la longueur de chaîne MAX d'une chaîne chiffrée et la définir comme la longueur de caractère d'un type VARCHAR. Selon le nombre d'enregistrements que vous allez avoir, cela pourrait vraiment aider à la taille de la base de données.

pour md5 vARCHAR (32) est approprié. Pour ceux qui utilisent AES, il vaut mieux utiliser varbinary.