Que transférer? Mot de passe ou son hachage?
Disons que dans ma base de données, je stocke les mots de passe hachés avec du sel avec un hachage assez cher (scrypt, 1000 tours de SHA2, peu importe).
Lors de la connexion, que dois-je transférer sur le réseau et pourquoi? Mot de passe ou son hachage?
Est-il possible de protéger une telle connexion sur un canal non crypté comme HTTP?
Si vous transférez le hachage du client, cela n'offre aucun avantage en matière de sécurité et rend le hachage inutile:
Si un utilisateur peut se connecter en envoyant le hachage au serveur, alors hachage est effectivement le mot de passe.
Si votre protocole d'authentification consiste à envoyer au serveur un mot de passe, ou un hachage du mot de passe, avec HTTP simple, cela est intrinsèquement très faible, pour deux raisons:
Quelqu'un espionnant la ligne pourrait enregistrer ce que le client envoie. Si le simple envoi de ces octets accorde l'accès, l'attaquant pourrait simplement les renvoyer. C'est une attaque de reje . C'est ce à quoi @AviD fait allusion dans sa réponse. Aucune quantité de hachage ne résoudra cela. Certains protocoles tentent de corriger ce problème en incluant un "défi" du serveur (une valeur aléatoire, créée à nouveau pour chaque connexion), à hacher avec le mot de passe sur le client; c'est de cela qu'il s'agit authentification HTTP Digest .
Même si l'authentification a fonctionné, il s'agit toujours de HTTP simple, donc toutes les données qui seront envoyées après seront vulnérables aux écoutes et aux modifications par les attaquants. Si le support de transport n'est pas protégé, l'authentification ne dissuadera que les attaquants les moins avertis. C'est là que HTTP Digest échoue.
Par conséquent, vous avez vraiment besoin de SSL (alias HTTPS), non seulement pour transmettre le mot de passe ou son hachage, mais aussi le reste de la conversation entre le client et le serveur .
Je suppose ci-après que le protocole est exécuté dans un tunnel SSL. Vous avez raison de vouloir utiliser un hachage lent comme bcrypt ou PBKDF2; notez qu'un sel est également nécessaire pour empêcher le partage des coûts (par exemple les tables précalculées). Le hachage lent et salé est utilisé pour faire face à la faiblesse intrinsèque des mots de passe. Maintenant, vous voudrez peut-être décharger une partie de l'effort de hachage sur le client. Cela mai fonctionne, mais cela soulève quelques problèmes pratiques:
Étant donné que le traitement du mot de passe doit inclure un sel, un nouveau pour chaque instance de mot de passe, le sel doit être transmis au client, afin que le client puisse l'inclure dans le hachage qu'il effectue. Cela augmente la complexité du protocole: le client doit d'abord envoyer le nom d'utilisateur au serveur, puis le serveur doit renvoyer le sel et (seulement alors) le client peut commencer à hacher le mot de passe. Il s'agit d'un aller-retour réseau de plus qu'avec le message habituel "envoyer le nom d'utilisateur et le mot de passe comme une seule POST").
Le hachage lent consiste à accepter de dépenser beaucoup de CPU sur chaque mot de passe, afin que l'attaquant aussi doive dépenser beaucoup de CPU sur chaque mot de passe. Mais si le CPU dépensé est sur le client, nous ne pouvons pas l'augmenter autant que nous le voudrions, car: 1) il y a des clients qui ont très peu de CPU (disons quelques smartphones ou tablettes bon marché), et 2) le contexte Web implique en utilisant Javascript, et les performances Javascript sont vraiment mauvaises quand il s'agit de hachage (disons au moins 20 fois plus lentement que le code C).
Par conséquent la sagesse habituelle est que faire une partie du hachage de mot de passe sur le client ne vaut pas la peine.
Les deux options ne sont pas sécurisées.
Le transfert du mot de passe rendra votre protocole en texte brut. Le transfert du hachage vous rendra vulnérable aux attaques de rejeu.
APOP est une implémentation de connexion pour le protocole POP. Cela permet au protocole de garder le mot de passe privé de tous les écouteurs du réseau. Un inconvénient est que le client et le serveur doivent connaître le mot de passe en texte brut, car il s'agit du secret partagé. Avant celui du protocole, le client et le serveur ont <mot de passe> La communication du protocole est fondamentalement comme ceci:
- Le client se connecte au serveur et envoie un jeton aléatoire (T1)
- Le serveur envoie un jeton aléatoire (T2)
- Le client envoie M = sha (T1 + T2 + <mot de passe: copie du client>) au serveur
- Le serveur vérifie si sha (T1 + T2 + <mot de passe: copie du serveur>) correspond à M (le hachage vient d'être reçu).
Ici, le serveur connaît à la fois la magie et le mot de passe et peut déterminer si l'utilisateur connaît le mot de passe correct sans l'exposer à aucun écouteur.
La meilleure pratique serait de stocker en toute sécurité les hachages dans la base de données et de s'appuyer sur des canaux cryptés.