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

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

Cela dépend de l’algorithme de hachage que vous utilisez. Le hachage produit toujours un résultat de même longueur, indépendamment de l’entrée. Il est typique de représenter le résultat de hachage binary dans le texte, sous la forme d’une série de chiffres hexadécimaux. Ou vous pouvez utiliser la fonction UNHEX() pour réduire une chaîne de chiffres hexadécimaux de moitié.

  • 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 pourriez avoir besoin de CHAR (56), CHAR (60), CHAR (76), BINARY (56) ou BINARY (60)

NIST recommande d’utiliser SHA-256 ou supérieur pour les mots de passe. Les algorithmes de hachage inférieurs ont leur utilité , mais ils sont connus pour être craquables .

Vous devez saler vos mots de passe avant d’appliquer la fonction de hachage. Saluer un mot de passe n’affecte pas la longueur du résultat de hachage.

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, SHA1 renvoie toujours un nombre hexadécimal de 40 caractères.

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

Vous pourriez trouver cet article Wikipedia sur le salage intéressant . L’idée est d’append un bit de données défini pour randomiser votre valeur de hachage; Cela protégera vos mots de passe des attaques de dictionnaires si quelqu’un obtient un access non autorisé aux hachages de mots de passe.

Les hachages sont une suite de bits (128 bits, 160 bits, 256 bits, etc., en fonction de l’algorithme). Votre colonne doit être de type binary, pas de type text / caractère, si MySQL le permet (le type de données SQL Server est binary(n) ou varbinary(n) ). Vous devriez également saler les hashes. Les sels peuvent être du texte ou du binary et vous aurez besoin d’une colonne correspondante.

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.

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

J’ai toujours testé pour trouver la longueur de chaîne MAX d’une chaîne cryptée et définissez-la 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 firebase database.

Vous devez utiliser TEXT (stocker un nombre illimité de caractères) dans un souci de compatibilité. Les algorithmes de hachage (nécessaires) deviennent plus forts au fil du temps et ce champ de firebase database devra donc prendre en charge davantage de caractères au fil du temps. En outre, en fonction de votre stratégie de migration, vous devrez peut-être stocker les anciens et les nouveaux hachages dans le même champ. Il est donc déconseillé de fixer la longueur à un type de hachage.