Quel type de données utiliser pour le champ de mot de passe haché et quelle longueur?
Je ne suis pas sûr de savoir comment fonctionne le hachage de mot de passe (il sera implémenté plus tard), mais il faut maintenant créer un schéma de base de données.
Je pense à limiter les mots de passe à 4 à 20 caractères, mais comme je le 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: le simple fait d'utiliser une fonction de hachage n'est pas assez puissant pour stocker les mots de passe. Vous devriez lire la réponse de Gilles sur ce sujet pour une explication plus détaillée.
Pour les mots de passe, utilisez un algorithme de hachage de renforcement de clé, tel que 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 varieront, car elle 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 ne code pas sous forme de chaîne de chiffres hexadécimaux, nous ne pouvons donc pas la récupérer aussi facilement en binaire.
D'autres fonctions de hachage ont encore des utilisations, mais pas pour stocker les 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 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, sous la forme d'une série de chiffres hexadécimaux. Ou vous pouvez utiliser la fonction UNHEX() pour réduire de moitié la 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)
À compter de 2015, NIST recommande d'utiliser SHA-256 ou une version supérieure pour toutes les applications de fonctions de hachage nécessitant une interopérabilité. Mais le NIST ne recommande pas d'utiliser ces simples fonctions de hachage pour stocker les mots de passe en toute sécurité.
Les algorithmes de hachage inférieurs ont leurs utilisations (comme internes à une application, pas pour l'échange), mais ils sont connus pour être craquables .
Vous pouvez réellement utiliser CHAR (longueur de hachage) pour définir votre type de données pour MySQL car chaque algorithme de hachage sera toujours évalué avec le même nombre de caractères. Par exemple, SHA1 renvoie toujours un nombre hexadécimal de 40 caractères.
Vous pourriez trouver cet article Wikipedia sur le salage tile . L'idée est d'ajouter un bit de données défini pour randomiser 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 mots de passe hachés.
En tant que chaîne de longueur fixe (VARCHAR (n) ou de quelque manière que MySQL l'appelle). Un hachage a toujours une longueur fixe, par exemple 12 caractères (en fonction de 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.
Utilisez toujours un algorithme de hachage de mot de passe: Argon2 , scrypt , bcrypt ou PBKDF2 .
Argon2 a remporté le concours de hachage de mots 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 qui restent fondamentalement valables. Si votre plate-forme ne prend pas en charge Argon2 Pourtant, il est correct d'utiliser un autre algorithme pour le moment.
Ne jamais stocker un mot de passe directement dans une base de données. Ne le chiffrez pas non plus: sinon, si votre site est violé, l'attaquant obtient la clé de déchiffrement et peut ainsi 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 le hachage 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 vous pouvez vous le permettre. La lenteur nuit beaucoup plus à l'attaquant que l'attaquant, qui doit essayer plusieurs mots de passe. Pour plus d'informations, voir Comment hacher des mots de passe en toute sécurité .
Un hachage de mot de passe code quatre informations:
- Un indicateur de l'algorithme utilisé. Ceci est nécessaire pour 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. Il doit s'agir d'une valeur de configuration constante ou globale dans la fonction de modification du mot de passe, mais elle devrait augmenter avec le temps à mesure que les ordinateurs accélèrent. Vous devez donc vous rappeler la valeur de chaque compte. Certains algorithmes ont une seule valeur numérique, d’autres ont davantage de paramètres (par exemple, pour régler l’utilisation de la CPU et la RAM utilisation séparément).
- Le sel. Comme 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 paire de fonctions qui empaquetent ces informations sous forme de chaîne unique: une chaîne prenant 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 un qui prend un mot de passe et la chaîne de hachage complète en 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ù algorithm est un nombre ou une courte chaîne alphanumérique codant le choix de l'algorithme, parameters est une chaîne imprimable et salt et output sont codés en Base64 sans mettre fin à =.
16 octets suffisent pour le sel et la sortie. (Voir, par exemple, recommandations pour Argon2 .) Encodé en Base64, cela fait 21 caractères chacun. Les deux autres parties dépendent de l'algorithme et des paramètres, mais 20 à 40 caractères sont typiques. C’est un total de environ 82 ASCII caractères (CHAR(82), et aucun besoin d’Unicode), auquel vous devriez ajoutez une marge de sécurité si vous pensez qu'il sera difficile d'agrandir le champ plus tard.
Si vous codez le hachage au format binaire, vous pouvez le réduire à 1 octet pour l’algorithme, 1 à 4 octets pour la dureté (si vous codez en dur certains paramètres) et 16 octets pour le sel et la sortie. , pour un total de 37 octets. Dites 40 octets (BINARY(40)) pour avoir au moins deux octets de réserve. Notez qu'il s'agit d'octets de 8 bits et non de caractères imprimables. En particulier, le champ peut inclure des octets nuls.
Notez que la longueur du hachage n'a aucun rapport avec la longueur du mot de passe.
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., en fonction de 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 devriez également saler les hashes. Les sels peuvent être du texte ou binaires, et vous aurez besoin d'une colonne correspondante.
Vous devez utiliser TEXT (stocker un nombre illimité de caractères) pour des raisons de compatibilité ascendante. Les algorithmes de hachage (doivent être) deviennent de plus en plus puissants au fil du temps et ce champ de base de données devra donc prendre en charge davantage de caractères au fil du temps. De plus, en fonction de votre stratégie de migration, vous devrez peut-être stocker les hachages nouveaux et anciens dans le même champ. Par conséquent, il n'est pas recommandé de fixer la longueur à un type de hachage.
J'ai toujours essayé de trouver la longueur de chaîne MAX d'une chaîne cryptée et de la définir comme longueur de caractères d'un type VARCHAR. En fonction du 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, mieux vaut utiliser varbinary.