J'ai une question simple qui s'est produite lorsque je voulais stocker le résultat d'un hachage SHA1 dans une base de données MySQL:
Combien de temps doit durer le champ VARCHAR dans lequel je stocke le résultat du hachage?
J'ai une question simple qui s'est produite lorsque je voulais stocker le résultat d'un hachage SHA1 dans une base de données MySQL:
Combien de temps doit durer le champ VARCHAR dans lequel je stocke le résultat du hachage?
Réponses:
J'utiliserais VARCHAR
pour des données de longueur variable, mais pas avec des données de longueur fixe. Comme une valeur SHA-1 est toujours longue de 160 bits, le VARCHAR
gaspillerait simplement un octet supplémentaire pour la longueur du champ de longueur fixe .
Et je ne conserverais pas non plus la valeur SHA1
renvoyée. Parce qu'il utilise seulement 4 bits par caractère et aurait donc besoin de 160/4 = 40 caractères. Mais si vous utilisez 8 bits par caractère, vous n'aurez besoin que d'un champ de 160/8 = 20 caractères.
Je vous recommande donc d'utiliser BINARY(20)
et la UNHEX
fonction pour convertir la SHA1
valeur en binaire.
J'ai comparé les besoins de stockage pour BINARY(20)
et CHAR(40)
.
CREATE TABLE `binary` (
`id` int unsigned auto_increment primary key,
`password` binary(20) not null
);
CREATE TABLE `char` (
`id` int unsigned auto_increment primary key,
`password` char(40) not null
);
Avec un million d'enregistrements binary(20)
prend 44,56 millions, tandis que char(40)
prend 64,57 millions.
InnoDB
moteur.
UNHEX()
manuellement le fichier sql.
Un hachage SHA1 fait 40 caractères!
Vous trouverez ci-dessous une liste d'algorithmes de hachage avec leur taille de bit requise:
Création d'un exemple de table avec require CHAR (n):
CREATE TABLE tbl_PasswordDataType
(
ID INTEGER
,MD5_128_bit CHAR(32)
,SHA_160_bit CHAR(40)
,SHA_224_bit CHAR(56)
,SHA_256_bit CHAR(64)
,SHA_384_bit CHAR(96)
,SHA_512_bit CHAR(128)
);
INSERT INTO tbl_PasswordDataType
VALUES
(
1
,MD5('SamplePass_WithAddedSalt')
,SHA1('SamplePass_WithAddedSalt')
,SHA2('SamplePass_WithAddedSalt',224)
,SHA2('SamplePass_WithAddedSalt',256)
,SHA2('SamplePass_WithAddedSalt',384)
,SHA2('SamplePass_WithAddedSalt',512)
);
La longueur est donc comprise entre 10 caractères 16 bits et 40 chiffres hexadécimaux.
Dans tous les cas, décidez du format que vous allez stocker et faites du champ une taille fixe basée sur ce format. De cette façon, vous n'aurez pas d'espace perdu.
Vous pouvez toujours utiliser VARCHAR dans les cas où vous ne stockez pas toujours un hachage pour l'utilisateur (c.-à-d. Authentification des comptes / URL de connexion oublié). Une fois qu'un utilisateur a authentifié / modifié ses informations de connexion, il ne devrait pas pouvoir utiliser le hachage et ne devrait avoir aucune raison de le faire. Vous pouvez créer une table séparée pour stocker le hachage temporaire -> les associations d'utilisateurs qui pourraient être supprimées mais je ne pense pas que la plupart des gens prennent la peine de le faire.
Si vous avez besoin d'un index sur la colonne sha1, je suggère CHAR (40) pour des raisons de performances. Dans mon cas, la colonne sha1 est un jeton de confirmation par e-mail, donc sur la page de destination, la requête entre uniquement avec le jeton. Dans ce cas, CHAR (40) avec INDEX, à mon avis, est le meilleur choix :)
Si vous souhaitez adopter cette méthode, n'oubliez pas de laisser $ raw_output = false.