Le cryptage des mots de passe est-il nécessaire pour un site Web HTTPS?
Je suis un peu confus car on nous a demandé de chiffrer les mots de passe AES avant de les envoyer au serveur. L'ensemble du site Web communique via HTTPS avec le serveur et utilise des cookies sécurisés.
AFAIK, HTTPS utilise un cryptage SSL 128 bits (pourrait être 256 bits, pas sûr) et cela se produit au niveau de la couche transport. Je suppose que tant que le client n'est pas compromis, une attaque sur la couche Présentation ou Application n'est pas possible. Ainsi, une fois SSL crypté, je pense que les informations parviendront au serveur en toute sécurité.
Est-il donc toujours nécessaire de crypter des informations précieuses telles que les mots de passe côté client avant de les envoyer au serveur?
Le cryptage du mot de passe avant de l'envoyer via HTTPS n'ajoute probablement pas plus de sécurité.
Considérez: comment le mot de passe est-il crypté par l'expéditeur et comment est-il décrypté par le destinataire?
Si vous utilisez un algorithme symétrique, comment ont-ils négocié la clé? Si la clé est intégrée au client, toute personne qui procède au reverse engineering du client y aura accès.
Si vous utilisez un algorithme asymétrique (c'est-à-dire à clé publique), soit pour crypter la clé, soit pour négocier une clé pour un algorithme symétrique ... vous faites simplement la même chose que SSL/TLS fait pour vous. .
Utilisez simplement la version la plus élevée disponible de TLS, avec la clé la plus longue dont votre serveur et vos clients disposent.
Juste pour être complet: HTTPS utilise SSL/TLS. Il était à l'origine synonyme de "HTTP sur SSL". De nos jours, SSL a été trouvé vulnérable, et vous devez utiliser son successeur TLS.
Sur le serveur, vous faites un hachage de (mot de passe + valeur salt). Il y a beaucoup d'informations sur la façon de faire une authentification Web sécurisée sur Stack Overflow's Definitive Guide to Form-Based Website Authentication .
En généralisant un peu la réponse de Frederics, il pourrait être nécessaire de chiffrer le mot de passe chez le client si la solution n'utilise pas HTTPS de bout en bout dans le flux de données d'informations d'identification.
Certaines raisons de ne pas utiliser HTTPS de bout en bout sont les suivantes:
- Le HTTPS se termine sur un serveur Edge tel qu'un équilibreur de charge ou un proxy inverse, avec un HTTP simple entre le serveur Edge et le serveur de destination finale (la situation de Frederics en serait un autre exemple).
- Les demandes sont maintenues au repos à un moment donné de leur flux, comme dans une file d'attente de messages pour le nivellement de la charge
Dans ce cas, il peut être judicieux d'utiliser le chiffrement au niveau des messages comme vous le décrivez.
J'ai vu de telles demandes de clients à qui l'on a vendu le concept de chiffrement de bout en bout pour les mots de passe.
La configuration est la suivante: il existe un serveur dédié qui valide les mots de passe et autres informations d'identification, et rien d'autre. Le serveur qui héberge l'application délègue l'authentification à ce serveur dédié, en transmettant les informations d'identification chiffrées.
Le chiffrement HTTPS s'arrête sur le serveur d'applications, mais les informations d'identification chiffrées sont toujours protégées jusqu'à ce qu'elles atteignent le serveur d'authentification.
Maintenant, je ne suis pas sûr que cela ait beaucoup de sens, mais comme je l'ai dit, j'ai rencontré des clients qui demandent une telle chose.
Habituellement, une architecture logicielle se compose d'un frontend, d'un middleware (pour la logique métier) et d'un backend (par exemple une base de données) et tous ces composants traitent le mot de passe. Un attaquant qui aurait compromis l'un de ces composants pourrait intercepter des mots de passe.
Une atténuation consiste à chiffrer les mots de passe. Avec le chiffrement à clé publique, le scénario suivant serait possible:
- le backend crée une clé publique et privée
- la clé publique sera incluse dans le formulaire où l'utilisateur entre son mot de passe
- lorsque l'utilisateur soumet le formulaire, un code JavaScript chiffre le mot de passe à l'aide de la clé publique
- le frontend reçoit le mot de passe crypté, l'envoie au middleware qui l'envoie au backend
- seul le backend peut le décrypter
Ainsi, un attaquant qui a compromis le frontend ou le middleware ne peut pas voir le mot de passe en clair.