Pourquoi presque pas de mots de passe de hachage de pages Web dans le client avant de les soumettre (et de les hacher à nouveau sur le serveur), afin de "protéger" contre la réutilisation des mots de passe?
Il existe de nombreux sites sur Internet qui nécessitent des informations de connexion, et la seule façon de se protéger contre la réutilisation des mots de passe est la "promesse" que les mots de passe sont hachés sur le serveur, ce qui n'est pas toujours vrai.
Je me demande donc, à quel point est difficile de créer une page Web qui hache les mots de passe sur l'ordinateur client (avec Javascript), avant de les envoyer au serveur, où ils seraient ré-hachés? En théorie, cela ne donne aucune sécurité supplémentaire, mais en pratique, cela peut être utilisé pour se protéger contre les "sites voyous" qui ne hachent pas votre mot de passe sur le serveur.
Pourquoi n'est-il pas utilisé? Parce que c'est beaucoup de travail supplémentaire pour un gain nul. Un tel système ne serait pas plus sûr. Il peut même être moins sécurisé car il donne la fausse impression d'être plus sécurisé, ce qui conduit les utilisateurs à adopter des pratiques moins sécurisées (comme la réutilisation des mots de passe, les mots de passe des dictionnaires, etc.).
En théorie, cela ne donne aucune sécurité supplémentaire, mais en pratique, cela peut être utilisé pour se protéger contre les "sites voyous" qui ne hachent pas votre mot de passe sur le serveur.
Comment cela vous protège-t-il exactement? Il semble que tout ce que vous voulez faire soit hacher le mot de passe haché qui est en quelque sorte inutile. Parce que le mot de passe haché deviendrait alors le mot de passe.
Il existe de nombreux sites sur Internet qui nécessitent des informations de connexion, et la seule façon de se protéger contre la réutilisation des mots de passe est la "promesse" que les mots de passe sont hachés sur le serveur, ce qui n'est pas toujours vrai.
Que diriez-vous de ne pas utiliser le même mot de passe pour plus d'un site. La raison pour laquelle les sites Web hachent le mot de passe en théorie est d'empêcher l'accès à votre compte s'ils sont compromis. Utiliser le même mot de passe pour plusieurs sites Web est tout simplement stupide.
Si vous avez utilisé javascript, tout ce que le "hacker" devrait faire est d'utiliser la même méthode sur les mots de passe hachés-hachés. Une fois que vous avez les informations hachées, il suffit de calculer le mot de passe -> même hachage dans la base de données, ce qui est un facteur empêchant l'accès à un compte.
Parce que cela ajouterait peu ou pas de valeur. La raison du hachage est que si votre base de données est piratée, le pirate n'aura pas de liste de mots de passe valides, juste des hachages. Par conséquent, ils ne pouvaient pas emprunter l'identité d'un utilisateur. Votre système n'a aucune connaissance du mot de passe.
La sécurité provient des certificats SSL et d'une certaine forme d'authentification. Je veux que mes utilisateurs fournissent un mot de passe afin que je puisse en calculer le hachage.
De plus, l'algorithme de hachage serait sur le serveur dans une zone plus sécurisée. En le mettant sur le client, il est assez facile d'obtenir le code source de Javascript, même si ses fichiers de scripts référencés sont cachés.
La solution est plus simple que cela. Certificats clients. Je crée un certificat client sur ma machine. Lorsque je m'inscris sur un site Web, nous faisons une poignée de main en utilisant mon certificat client et le certificat du serveur.
Aucun mot de passe n'est échangé et même si quelqu'un pirate la base de données, il n'aura que la clé publique de mon certificat client (qui devrait être salée et chiffrée par le serveur pour un niveau de sécurité supplémentaire).
Le certificat client peut être stocké sur une carte à puce (et téléchargé sur un coffre-fort en ligne sécurisé à l'aide d'un mot de passe principal).
La beauté de tout cela est qu'il supprime le concept de phishing loin ... vous n'entrez jamais un mot de passe dans un site Web, vous êtes juste une poignée de main avec ce site Web. Tout ce qu'ils obtiennent, c'est votre clé publique qui est inutile sans clé privée. La seule vulnérabilité est de trouver une collision lors d'une poignée de main et cela ne fonctionnerait qu'une seule fois sur un seul site Web.
Microsoft a essayé de fournir quelque chose comme ça dans Windows avec Cardspace et l'a ensuite soumis comme standard ouvert. OAuth est quelque peu similaire mais il s'appuie sur une "partie émettrice" intermédiée. D'un autre côté, les InfoCards pourraient être auto-émises. C'est la vraie solution au problème des mots de passe ... supprimer complètement les mots de passe.
OAuth est cependant un pas dans la bonne direction.
la plupart des réponses semblent manquer complètement le but du hachage de mot de passe côté client.
le point est pas pour sécuriser l'accès au serveur auquel vous vous connectez, car l'interception d'un hachage n'est pas plus sécurisée que l'interception d'un mot de passe en texte brut.
le but est vraiment de sécuriser le mot de passe de l'utilisateur, ce qui est généralement beaucoup plus précieux que l'accès à la connexion à un site individuel car la plupart des utilisateurs réutilisent leur mot de passe pour plusieurs sites (ils ne devraient pas, mais la réalité est qu'ils le font il ne doit donc pas être agité).
ssl est idéal pour se protéger contre les attaques mitm, mais si une application de connexion est compromise sur le serveur, ssl ne protégera pas vos utilisateurs. si quelqu'un a malicieusement accédé à un serveur Web, il pourra probablement intercepter les mots de passe en texte brut car dans la plupart des cas, les mots de passe ne sont hachés que par un script sur le serveur. l'attaquant peut alors essayer ces mots de passe sur d'autres sites (généralement plus précieux) en utilisant des noms d'utilisateur similaires.
la sécurité est une défense en profondeur, et le hachage côté client ajoute simplement une autre couche. rappelez-vous que bien que la protection de l'accès à votre propre site soit importante, la protection du secret des mots de passe de vos utilisateurs est beaucoup plus importante en raison de la réutilisation des mots de passe sur d'autres sites.
C'est certainement possible, et en fait, vous n'avez pas besoin d'attendre un site Web.
Jetez un oeil à SuperGenPass . Il s'agit d'un bookmarklet.
Il reconnaît simplement les champs des mots de passe, concatène ce que vous tapez avec le domaine du site Web, le hache, le modifie quelque peu de manière à obtenir uniquement des caractères "admis" dans le mot de passe, et ce n'est qu'alors que votre mot de passe haché est envoyé sur le fil.
En utilisant le domaine du site dans le processus, vous obtenez ainsi un mot de passe unique par site, même si vous réutilisez toujours le même mot de passe.
Il n'est pas extrêmement sécurisé (base64-MD5), mais vous distribuez parfaitement une implémentation basée sur sha-2 si vous le souhaitez.
Le seul inconvénient est que le domaine change, auquel cas vous devrez demander au site Web de réinitialiser votre mot de passe car vous ne pourrez pas le récupérer par vous-même ... cela ne se produit pas souvent, donc je considère que c'est un compromis acceptable.
J'aime la réponse de X4u, mais à mon avis, quelque chose comme ça devrait être intégré dans le navigateur/la spécification html - car pour le moment ce n'est que la moitié de la réponse.
Voici un problème que j'ai en tant qu'utilisateur - je n'ai aucune idée si mon mot de passe va être haché à l'autre extrémité lorsqu'il sera stocké dans la base de données. Les lignes entre moi et le serveur peuvent bien être cryptées mais je n'ai aucune idée de ce qui arrive à mon mot de passe une fois qu'il a atteint la destination - il peut être stocké en texte brut. L'administrateur de la base de données peut vendre la base de données et avant que vous ne le sachiez, le monde entier connaît votre mot de passe.
La plupart des utilisateurs réutilisent les mots de passe. Des gens non techniques car ils ne connaissent pas mieux. Les techniciens parce qu'une fois que vous avez atteint le 15e mot de passe, la plupart des gens n'ont aucune chance de s'en souvenir à moins de les écrire (ce que nous savons tous est également une mauvaise idée).
Si Chrome ou IE ou quoi que ce soit que j'utilise) pourrait me dire qu'une boîte de mot de passe va instantanément être hachée côté client en utilisant un sel généré par le serveur et mettre en sandbox le mot de passe lui-même - alors je saurais qu'en tant qu'utilisateur je pourrais réutiliser un mot de passe avec moins de risques.
L'utilisateur doit savoir que son mot de passe n'est même pas disponible pour être envoyé au serveur - seulement le hachage. À l'heure actuelle, même en utilisant la solution de X4U, ils n'ont aucun moyen de savoir que c'est le cas, car vous ne savez pas si cette technologie est utilisée.