Pourquoi utiliser un jeton d'authentification au lieu du nom d'utilisateur / mot de passe par demande?
L'auteur de https://stackoverflow.com/a/477578/14731 recommande:
NE PAS STOCKER LE COOKIE DE CONNEXION PERSISTANT (JETON) DANS VOTRE BASE DE DONNÉES, SEULEMENT UN HASH OF IT! [...] utilisez un hachage fortement salé (bcrypt/phpass) lors du stockage de jetons de connexion persistants.
J'avais l'impression que les cookies de connexion avaient deux objectifs:
- Avantage UX: ne demandez pas à l'utilisateur de se connecter une fois par demande
- Gain de performances: pas besoin d'exécuter un algorithme lent (comme bcrypt) par requête
Il semble que l'auteur invalide le deuxième point, ce qui me fait me demander: pourquoi s'embêter avec les jetons d'authentification? Au lieu de mapper le nom d'utilisateur/mot de passe à un jeton d'authentification choisi au hasard, pourquoi ne pas simplement transmettre le nom d'utilisateur/mot de passe par demande à l'aide d'un cookie httpOnly, secure?
En supposant que nous acceptons la recommandation de l'auteur et utilisons bcrypt par demande, quel est l'avantage d'utiliser un jeton d'authentification à la place d'un nom d'utilisateur/mot de passe?
Lorsque vous utilisez un "jeton d'authentification", la simple présentation de ce jeton par le client accorde l'accès (tant que le jeton est jugé valide par le serveur). Si vous stockez les jetons "tels quels" dans la base de données de votre serveur, un attaquant qui pourrait avoir un aperçu de votre base de données apprendra immédiatement tous les jetons, lui permettant d'envoyer des demandes au nom de tous les utilisateurs pour lesquels un jeton valide existe toujours. dans la base de données. C'est mauvais. D'où la recommandation de ne stocker qu'un hachage du jeton d'authentification.
Les conseils sur bcrypt pour les jetons d'authentification sont erronés. Bcrypt, comme toutes les fonctions dédiées à hachage de mot de passe , est destiné à être utilisé pour les mots de passe . Les mots de passe sont faibles; ils sont vulnérables aux attaques par dictionnaire. Pour faire face à leur faiblesse inhérente, la fonction de hachage de mot de passe doit être salée (pour empêcher les attaques parallèles et les tables précalculées) et doit également être extrêmement lente (à travers un nombre énorme si les itérations internes). Cela rend les fonctions de hachage de mot de passe coûteuses . Donc, vous ne voulez pas utiliser une fonction de hachage de mot de passe à moins que vous n'en ayez besoin, par ex. pour hacher un mot de passe.
Un jeton d'authentification n'est pas un mot de passe; c'est une valeur aléatoire qui a été générée et mémorisée par un ordinateur, sans aucun cerveau humain impliqué dans le processus. En tant que tel, si vous avez généré le jeton correctement (au moins 128 bits, obtenu à partir d'un PRNG cryptographiquement sécurisé ), il n'y a pas besoin de sels ou d'itérations; utilisez simplement une fonction de hachage simple (même MD5 serait bien là). Ce sera plus efficace.
Quant à l'utilisation d'un jeton d'authentification aléatoire au lieu de login + mot de passe pour chaque demande, il y a deux raisons principales à cela:
Performances: comme expliqué ci-dessus, un jeton d'authentification peut être vérifié en toute sécurité avec un hachage simple, qui sera beaucoup plus efficace qu'un appel bcrypt lourd. Vous souhaitez conserver vos précieux cycles de processeur lorsqu'ils sont vraiment utiles, en particulier lorsque vous appliquez bcrypt à un véritable mot de passe géré par l'homme.
Stockage côté client: le jeton d'authentification sera stocké sur le client en tant que valeur de cookie. Si l'identifiant et le mot de passe sont renvoyés à chaque demande, ils sont stockés sous forme de cookie sur le client. Les gens deviennent nerveux lorsque leurs mots de passe sont écrits dans des fichiers - et un tel stockage n'est pas équivalent (d'un point de vue de la sécurité) au stockage d'un jeton d'authentification, car l'utilisateur humain a la (mauvaise) habitude de réutiliser ses mots de passe pour plusieurs systèmes, alors que les jetons d'authentification sont intrinsèquement spécifiques au serveur.