Quel type de hachage utiliser pour stocker REST jetons d'API dans la base de données?
Nous avons une REST qui communique avec un frontal mobile. Après avoir soumis un mot de passe unique, le backend émettra un jeton (chaîne UUID v4 aléatoire) pour l'application mobile à utiliser comme authentification sur les demandes suivantes. Le serveur stockera une version hachée de ce jeton dans la base de données avec l'utilisateur.
Nous voulons nous assurer que l'authentification du jeton prend le moins de temps possible.
QUESTION
Quel type de hachage/chiffrement est suffisant pour stocker les jetons dans la base de données? Un hachage rapide tel que SHA256 est-il suffisant, ou devrions-nous utiliser un hachage lent tel que bcrypt? Si vous utilisez SHA256, devons-nous inclure un sel, car le jeton non haché d'origine n'est qu'un UUID aléatoire de 16 octets?
TLDR; SHA256 est assez bon
Pour répondre à cela, nous devons examiner pourquoi nous salons, hachons et utilisons plusieurs itérations du hachage, en premier lieu;
Pourquoi salons-nous? Pour protéger les utilisateurs qui ont une entropie de mot de passe faible de voir leur mot de passe craqué (par exemple, les tables Rainbow ou deux utilisateurs avec le même mot de passe). Ce n'est pas un problème car UUID4 aura 122 bits d'entropie1.
Si nous voulions créer une table Rainbow de toutes les valeurs UUIDv4 qui ont été hachées SHA256 et nous pourrions faire 1 billion de hachages par seconde2. Il faudrait 168,6 quadrillions d'années pour créer la table Rainbow. Nous n'avons donc pas à nous en préoccuper.
Pourquoi hachons-nous? Pour empêcher le stockage de copies en texte clair du mot de passe. Cela semble être une bonne idée. Vous ne voulez pas que quelqu'un puisse lire votre base de données3 pour pouvoir se faire passer pour des utilisateurs.
Pourquoi utilisons-nous plusieurs itérations? Pour ralentir les attaques par force brute. Comme mentionné précédemment, UUID4 aura 122 bits d'entropie. Le craquage de ces hachages est irréalisable même à grande vitesse.
[1] 128 bits - 6 bits qui sont prédéterminés
[2] Les taux de hachage les plus rapides actuels se enchaînent tout le temps, donc je ne prendrai pas la peine d'essayer de trouver la vitesse la plus actuelle, elle sera obsolète dans quelques mois.
[3] Cela pourrait être une injection SQL, ou une copie divulguée d'une sauvegarde, ou d'un initié, ou autre.