Quel type de colonne/longueur dois-je utiliser pour stocker un mot de passe haché par Bcrypt dans une base de données ?

Question

Je veux stocker un mot de passe haché (en utilisant BCrypt) dans une base de données. Quel serait un bon type pour cela, et quelle serait la longueur correcte ? Les mots de passe hachés avec BCrypt ont-ils toujours la même longueur ?

EDITAR

Exemple de hachage :

$2a$10$KssILxWNR6k62B7yiX0GAe2Q7wwHlrzhF3LqtVvpyvHZf0MwvNfVu

Après avoir haché quelques mots de passe, il semble que BCrypt génère toujours des hachages de 60 caractères.

EDIT 2

Désolé de ne pas avoir mentionné l'implémentation. J'utilise jBCrypt .

Answer 1

Le format de cryptage modulaire pour bcrypt se compose de

• $2$ , $2a$ o $2y$ identifier les algorithme de hachage et format
• une valeur à deux chiffres indiquant le paramètre de coût, suivie de $
• une valeur codée en base-64 de 53 caractères (l'alphabet utilisé est le suivant . , / , 0 - 9 , A - Z , a - z qui est différente de la codage standard en base 64 alphabet) composé de :
  • 22 caractères de sel (en fait seulement 128 bits sur les 132 bits décodés)
  • 31 caractères de sortie cryptée (en fait seulement 184 bits sur les 186 bits décodés)

La longueur totale est donc de 59 ou 60 octets respectivement.

Comme vous utilisez le format 2a, vous aurez besoin de 60 octets. Et donc pour MySQL je vous recommande d'utiliser le format CHAR(60) BINARY ou BINARY(60) (voir El _bin y binaire Collations pour des informations sur la différence).

CHAR n'est pas binairement sûr et l'égalité ne dépend pas uniquement de la valeur de l'octet mais de la collation réelle ; dans le pire des cas, l'option A est considéré comme égal à a . Voir El _bin y binary Collations pour plus d'informations.

Answer 2

Un hachage Bcrypt peut être stocké dans un fichier BINARY(40) colonne.

BINARY(60) Comme les autres réponses le suggèrent, c'est le choix le plus simple et le plus naturel, mais si vous voulez maximiser l'efficacité du stockage, vous pouvez économiser 20 octets en déconstruisant sans perte le hachage. Je l'ai documenté plus en détail sur GitHub : https://github.com/ademarre/binary-mcf

Les hachages de Bcrypt suivent une structure appelée "modular crypt format" (MCF). Binaire MCF (BMCF) décode ces représentations de hachage textuelles en une structure binaire plus compacte. Dans le cas de Bcrypt, le hachage binaire résultant est de 40 octets.

Gumbo a fait un bon travail d'explication des quatre composants d'un hachage MCF de Bcrypt :

$<id>$<cost>$<salt><digest>

Le décodage en BMCF se fait comme suit :

1. $<id>$ peut être représenté sur 3 bits.
2. <cost>$ 04-31, peut être représenté sur 5 bits. Rassemblez-les pour obtenir un octet.
3. Le sel à 22 caractères est une représentation (non standard) en base 64 de 128 bits. Le décodage en base-64 donne 16 octets.
4. Le condensé de hachage de 31 caractères peut être décodé en base 64 en 23 octets.
5. Mettez tout ça ensemble pour 40 octets : 1 + 16 + 23

Vous pouvez en lire plus au lien ci-dessus, ou examiner mon implémentation PHP également sur GitHub.

Answer 3

Si vous utilisez la fonction password_hash() avec le PASSWORD_DEFAULT pour générer le hachage bcrypt (ce qui, je suppose, représente un grand pourcentage des personnes lisant cette question), assurez-vous de garder à l'esprit qu'à l'avenir password_hash() pourrait utiliser un algorithme différent de celui utilisé par défaut, ce qui pourrait donc affecter la longueur du hachage (mais il ne sera pas nécessairement plus long).

De la page du manuel :

Notez que cette constante est conçue pour changer avec le temps, au fur et à mesure que de nouveaux et algorithmes plus puissants sont ajoutés à PHP. Pour cette raison, la longueur du résultat de l'utilisation de cet identifiant peut changer dans le temps. Par conséquent, il est recommandé de stocker le résultat dans une colonne de la base de données qui peut s'étendre au-delà de 60 caractères (255 caractères seraient un bon choix).

En utilisant bcrypt, même si vous avez 1 milliard d'utilisateurs (c'est-à-dire que vous êtes actuellement en concurrence avec facebook) pour stocker des hachages de mots de passe de 255 octets, cela ne représenterait que ~255 Go de données, soit environ la taille d'un disque dur SSD de petite taille. Il est extrêmement peu probable que le stockage du hachage du mot de passe soit le goulot d'étranglement de votre application. Cependant, dans le cas où l'espace de stockage es un problème pour une raison quelconque, vous pouvez utiliser PASSWORD_BCRYPT pour forcer password_hash() pour utiliser bcrypt, même si ce n'est pas la valeur par défaut. Assurez-vous de rester informé des vulnérabilités trouvées dans bcrypt et consultez les notes de mise à jour à chaque fois qu'une nouvelle version de PHP est publiée. Si l'algorithme par défaut est modifié, il serait bon de revoir les notes de mise à jour. pourquoi et prendre une décision éclairée quant à l'utilisation ou non du nouvel algorithme.

Answer 4

Je ne pense pas qu'il y ait de trucs astucieux à faire pour stocker cela, comme on peut le faire par exemple avec un hachage MD5.

Je pense que votre meilleure chance est de le stocker en tant que CHAR(60) car il est toujours de 60 caractères