Définir un hachage, vous connecter avec un mot de passe?
Je viens de rencontrer un schéma de hachage/réinitialisation de mot de passe que je n'ai jamais vu auparavant. Je suis sceptique, mais je ne vois pas de raison concrète pour laquelle cela est mauvais.
Le schéma de création d'un compte/réinitialisation du mot de passe se présente comme suit:
1) L'utilisateur tape le mot de passe
"FuzzyCat"Dans une application côté client.2) L'application côté client hache le mot de passe
hash("FuzzyCat") -> "99476bb..."(peut-être après avoir demandé la politique de hachage - sel, fonction de hachage, etc. - au serveur) et transmet le hachage au serveur.3) Le serveur stocke
"99476bb..."Dans la base de données comme hachage de mot de passe pour cet utilisateur.4) Lorsque l'utilisateur vient de se connecter ensuite, il entre
"FuzzyCat", Le serveur le hache et le compare à"99476bb..."Dans la base de données.
Le cas d'utilisation où j'ai vu cela est que les comptes sont initialement créés par un script d'automatisation dans le cadre d'un processus en bloc de plusieurs heures, et nous préférerions ne pas que les mots de passe en clair flottent dans la mémoire/sur le disque pendant ce temps. Toutes les connexions ultérieures par l'utilisateur seront directement au service via un canal sécurisé (note: pas https, je veux dire "signez le journal pour avoir un accès physique à la salle" type de canal sécurisé).
Pour répondre aux commentaires, la raison pour laquelle nous ne faisons pas confiance au script d'automatisation est qu'il est écrit dans un langage avec des chaînes immuables et un ramasse-miettes, de sorte que toute mémoire contenant des mots de passe sera retournée au système d'exploitation non mis à zéro - ce qui ne correspond pas à notre interne politiques de gestion des mots de passe. Alors oui, la principale préoccupation est un MitM passif.
Question: Quelles vulnérabilités/problèmes pourraient y avoir avec ce schéma?
La seule chose à laquelle je peux penser est que le serveur doit compter sur le client pour être honnête et suivre la politique de hachage, permettant potentiellement aux utilisateurs de mettre des hachages faibles dans la base de données. Ce n'est pas un gros problème car lors de la connexion, le serveur hachera leur mot de passe avec la véritable politique de hachage et les hachages ne correspondront pas, ergo pas de connexion, pas de violation.
Autant que je sache, il n'y a aucun risque qu'un attaquant obtienne le hachage car cela ne les aide pas à se connecter. Suis-je en train de manquer quelque chose?
Je suis d'accord avec @Xiong Chiamiov, il n'y a rien de fondamentalement mauvais avec cette approche.
En revanche, cela n'apporte pas beaucoup d'avantages à l'approche standard (tout le hachage est effectué côté serveur), et il y a certainement un risque à divulguer le hachage à des entités non fiables.
Si le client d'origine n'est pas approuvé, cela ne fait évidemment rien, car le client pourrait simplement enregistrer le mot de passe entré.
Si la connexion d'origine entre le client et le serveur n'est pas approuvée, cela n'aide que légèrement. Un homme passif au milieu a encore gagné le hachage et peut essayer de le casser. Un homme actif au milieu pourrait changer le hachage pour y accéder, ou pourrait changer la réponse à la politique de hachage pour forcer un hachage faible à obtenir le mot de passe (ou forcer aucun hachage du tout; ou simplement injecter Javascript ou similaire pour lire le mot de passe saisi).
Ainsi, le seul cas d'utilisation raisonnable est l'atténuation limitée contre un homme passif au milieu lors de l'inscription initiale. Si je rencontrais cela, je vérifierais à quel point l'inscription initiale n'est pas vraiment fiable et s'il n'y a pas une approche plus sensée que de divulguer le hachage.
Le problème qui se pose généralement en parlant de hachage côté client est qu'un attaquant qui a violé la base de données peut simplement transmettre les hachages au serveur pour s'authentifier. Cependant, ce schéma ne permet pas d'utiliser le hachage pour l'authentification, juste la création initiale du compte, donc il ne tombe pas dans ce piège.
J'ai vu ce genre de chose utilisé dans le contexte des fichiers Apache htpasswd; les utilisateurs génèrent un résumé et l'envoient sur un canal relativement peu sûr (par exemple, un courrier électronique) à l'administrateur système, qui l'ajoute ensuite à la configuration du serveur. Bien qu'un système impliquant une authentification de base ou un résumé ne soit pas le summum de la sécurité informatique, cela montre que ce n'est pas une approche entièrement nouvelle et a au moins suscité une certaine attention.
Étant donné la description telle que vous l'avez formulée, je ne vois aucun problème évident. Il peut bien sûr y avoir des problèmes d'implémentation, comme un bug qui permet d'alimenter le hachage au lieu du mot de passe pour l'authentification. Et comme la connexion initiale n'est pas approuvée, il est probablement un peu plus facile pour un attaquant d'obtenir un hachage de mot de passe (pour lequel il peut ensuite essayer de se fissurer ou de générer une collision). Mais ce ne sont pas des problèmes avec le système lui-même, ni des problèmes majeurs.
Deux lentes
éventuellement après avoir demandé la politique de hachage - sel, fonction de hachage, etc. - au serveur
Je ne sais pas si ce mécanisme utilise un sel par utilisateur ou un sel global. S'il utilise un sel global, il est vulnérable à une attaque Rainbow.
Le serveur stocke "99476bb ..." dans la base de données comme hachage de mot de passe pour cet utilisateur.
Étant donné que le hachage a été généré en dehors du serveur, il n'y a aucun moyen pour le serveur d'appliquer des règles de complexité ou de longueur de mot de passe. Ils devraient être appliqués par l'application. En outre, il n'existe aucun moyen de vérifier la réutilisation du mot de passe.
Je ne pense pas que le programme proposé ajoute un risque supplémentaire, mais je ne suis pas sûr qu'il en réduise non plus. Il semble qu'il manque un élément d'information crucial. Dans le cadre de ce schéma, comment vérifiez-vous initialement le client pour savoir qu'il est qui vous pensez qu'il est avant de lui permettre de définir le hachage? C'est le véritable défi - il existe un certain nombre de façons différentes de communiquer un mot de passe défini/modifié sur le câble pour empêcher les attaques MitM, mais lorsque vous souhaitez autoriser la configuration à distance de toute forme de processus d'authentification, le problème est de vérifier le utilisateur distant.
Je ne suis pas non plus convaincu que la politique qui vous oblige à considérer cette alternative présente un réel avantage, sauf pour que les auditeurs se sentent mieux. Avouons-le, si votre risque est de récolter des informations de mot de passe à partir de la mémoire du système d'exploitation, le vrai problème est un contrôle adéquat de l'accès au système d'exploitation et à cette mémoire, et non à ce qui se trouve dans la mémoire. Si quelqu'un a ce niveau d'accès, il peut de toute façon compromettre votre processus d'authentification de base. Tout ce que fait la politique, c'est ajouter de la complexité, ce qui créera probablement d'autres problèmes.