Stockage des valeurs de hachage SHA1 dans MySQL

Question

J'ai une question simple qui s'est posée quand j'ai voulu stocker le résultat d'un hachage SHA1 dans une base de données MySQL:

Combien de temps le champ VARCHAR doit-il contenir le résultat du hachage?

Answer 1

Je voudrais utiliser VARCHAR pour les données de longueur variable, mais pas de longueur fixe des données. Parce que SHA-1 valeur est toujours de 160 bits de long, l' VARCHAR serait juste une perte supplémentaire de l'octet pour la longueur de la zone de longueur fixe.

Et j'ai aussi ne pas stocker la valeur de l' SHA1 est de retour. Parce qu'il utilise seulement 4 bits par caractère, et, donc, besoin 160/4 = 40 caractères. Mais si vous utilisez de 8 bits par caractère, vous n'aurez besoin que d'un 160/8 = 20 caractères de long champ.

Donc, je vous recommande d'utiliser BINARY(20) et de la UNHEX de la fonction de convertir l' SHA1 de la 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 plus d'un million d'enregistrements binary(20) prend 44.56 M, char(40) prend 64.57 M. InnoDB moteur.

Answer 2

Un hash SHA1 fait 40 caractères de long!

Answer 3

La taille de sortie de sha1 est de 160 bits. Ce qui est 160/8 == 20 caractères (si vous utilisez des caractères de 8 bits) ou 160/16 = 10 (si vous utilisez des caractères de 16 bits).

Answer 4

La longueur est donc comprise entre 10 caractères de 16 bits et 40 chiffres hexadécimaux.

Dans tous les cas, décidez du format que vous allez stocker et définissez le champ sur une taille fixe basée sur ce format. De cette façon, vous n'aurez aucun espace perdu.

Answer 5

Vous pouvez toujours vouloir utiliser VARCHAR dans les cas où vous ne stockez pas toujours un hachage pour l'utilisateur (c.-à-d. Authentifier les comptes / oublié l'URL de connexion). Une fois qu'un utilisateur a authentifié / modifié ses informations de connexion, il ne devrait plus pouvoir utiliser le hachage et ne devrait pas avoir de raison de le faire. Vous pouvez créer une table distincte pour stocker les associations de hachage temporaires -> utilisateur qui pourraient être supprimées, mais je ne pense pas que la plupart des gens prennent la peine de le faire.