Hé, tout d'abord, permettez-moi de dire, je ne vous parle pas des choses comme md5 (md5 (..., il y a déjà des sujets à ce sujet.
Ma question est la suivante:
Nous permettons à nos clients de stocker leurs mots de passe localement. Bien sûr, nous ne voulons pas les stockés dans le texte du plan, afin que nous les HMAC localement, avant de les stocker et / ou l'envoi. Maintenant, cela est très bien, mais si cela est tout ce que nous avons fait, le serveur aurait le HMAC stocké, et puisque le client n'a besoin que d'envoyer le HMAC, pas le mot de passe de texte brut, un attaquant pourrait utiliser les hash stockées sur le serveur Pour accéder au compte de quiconque (dans le scénario catastrophique où quelqu'un recevrait un tel accès à la base de données, bien sûr).
Donc, notre idée était d'encoder le mot de passe sur le client une fois via HMAC, envoyez-le sur le serveur, et il y a une seconde fois via HMAC et le correspond à un mot de passe STORED, deux fois Hmac'ed. Cela garantirait que:
Naturellement, toutes les autres choses (mots de passe forts, double sel, etc.) s'appliquent également, mais ne sont pas vraiment pertinents pour la question.
La question réelle est la suivante: cela sonne-t-il comme une conception de sécurité solide? Avons-nous négligé des défauts avec des choses de cette façon? Y a-t-il peut-être un modèle de sécurité pour quelque chose comme ça?
Addendadum: la raison pour laquelle nous ne voulons pas stocker localement le mot de passe en texte brut sur le client est dû au fait que, de nombreuses personnes utilisent toujours le même mot de passe pour plusieurs services, de sorte que le mot de passe "réel" Soyez une violation de sécurité plus importante pour l'utilisateur que de faire voler son hachage.
7 Réponses :
CAVEAT: Je ne suis pas un expert en sécurité. Je vais ping WinDart pour voir s'il s'agit de joints dans.
Si le client ne fait que stocker le hachage et transmettant efficacement quelque chose juste basé sur le hachage, alors ils sont efficacement stockez-le en texte brut. Le seul avantage que le premier hachage fournit est que s'ils utilisaient le même mot de passe sur un système différent, cet autre système ne sera pas compromis si le hachage est révélé.
Pour le mettre un autre moyen: si quelqu'un peut obtenir la maintien du hachage qui est stocké sur le serveur, c'est tout ce dont ils ont besoin de se connecter au système ... comme le stockage en texte brut.
bon point. Tout le hachage et le double hachage me sont confondus pour une seconde en pensant que c'est assez sécurisé! :)
Je ne sais pas comment cela fonctionnerait. Disons que vous avez le hasch qui est stocké sur le serveur - comment utiliseriez-vous cela pour vous connecter?
@J. Stoever: Eh bien, j'étais plus significatif que le hash stocké sur le client ... mais s'ils sont la même chose, peu importe. Fondamentalement à ce stade, vous avez tout ce que le client utiliserait pour vous connecter ... Peu importe que vous n'aviez pas le mot de passe original en clair.
Je ne suis pas tout à fait sûr de ce que cela vous achète sur la base du mot de passe localement en clair.
Le but du cryptage local est d'empêcher un pirate informatique de pouvoir envoyer le mot de passe à votre serveur. Cependant, si vous allez envoyer la forme cryptée sur ... Eh bien, vous n'avez rien acheté.
Au lieu de cela, la machine locale doit stocker le mot de passe dans un format crypté à deux voies. Ce qui signifie qu'il peut être déchiffré. Que vous faites avant la transmission. Le DB peut stocker un format crypté à sens unique (même à l'aide d'un mécanisme de cryptage séparé). Avant la comparaison, vous chiffrez ce que vous avez reçu, puis vérifiez.
Une fonction Message Digest n'est pas une méthode de cryptage.
Quel est le hachage initial du mot de passe destiné à atteindre? Il va protéger contre la découverte de la version en texte brut du mot de passe. Il n'empêchera pas l'utilisation de cette valeur de hachage pour calculer la valeur doublement hachée.
Non, ce n'est pas sûr. La valeur hachée est effectivement le mot de passe. Le fait que le mot de passe a été dérivé de quelque chose d'autre que l'utilisateur pense que le mot de passe n'a pas d'importance. C'est une valeur secrète qui authentifie un utilisateur, non? Cela ressemble à un mot de passe pour moi.
Je pense qu'il dépend de la déclaration ", nous ne voulons naturellement que ceux-ci stockés dans le texte du plan, nous les hmacs localement, avant de stocker et / ou d'envoyer." Si le système est modifié de manière à ce que le mot de passe de hachage ait maintenant le même pouvoir que le mot de passe avait une fois, le même niveau de prudence doit être utilisé avec le mot de passe haché.
+1 Bien que tout le monde a abattu ce protocole, c'est bien mis, je pense que l'Op comprendra.
Comme d'autres l'ont dit, en prenant le client et votre système en vase clos, cela ne pas vraiment acheter quoi que ce soit -. Le premier hachage devient simplement le mot de passe
La valeur vient si (comme est probablement) le client utilise le même mot de passe sur d'autres systèmes. Dans ce cas, si la machine client doit être compromise puis au moins votre copie locale de leur mot de passe hachée ne permet pas l'accès à d'autres systèmes d'attaquant. Évidemment, l'attaquant du client sera pour accéder à votre serveur - ils ont, après tout, ont reçu le mot de passe.
Un attaquant ayant accès à la valeur de la double hachée sur le serveur ne les achètera rien, puisqu'ils ne peuvent pas inverser cela pour obtenir le hasch unique (c'est-à-dire le "mot de passe"). Bien sûr, si l'attaquant est en mesure de lire votre base de données de sécurité, je soupçonne qu'ils disposent d'autres vecteurs d'attaque disponibles :)
En outre, comme une autre affiche indiquée, assurez-vous d'utiliser un sel sur les deux hachages. Sans cela, inversant les hachages peut en réalité être assez simple si les mots de passe ne sont pas forts.
Edit - En fait, en y réfléchissant, puisque vous utilisez un hachage comme mot de passe, vous n'avez pas vraiment besoin d'utiliser un sel sur le serveur. Néanmoins, quiconque va être capable de créer une table arc-en-ciel efficace :) en a encore besoin d'un sur le client.
Cela décrit à peu près ce que je pensais, à court de ne pas avoir besoin d'un sel sur le serveur, mais je suppose qu'il n'y a pas vraiment un inconvénient d'utiliser une personne de toute façon. Bien sûr, il n'ya aucun moyen de garantir que le client ne puisse pas être compromis s'il stocke le mot de passe, je ne cherchais pas cela.
Je manquez de la porte, mais le skeet pingé et vous ne plaisantez pas avec le skeet.
Ce que vous faites, c'est remplacer un mot de passe avec une autre valeur constante. Vous ne gagnerez rien ici, la seule sécurité que vous avez est que le mot de passe de texte brut ne peut être découvert sur la machine client.
Ce que vous semblez faire, c'est traiter le HMAC (êtes-vous sûr que vous voulez dire HMAC? Si oui, où est la clé de la clé et stockée?) du mot de passe comme mot de passe lui-même - vous l'envoyez du client à le serveur où il est utilisé pour s'authentifier. Le deuxième HMAC ou le hachage n'a pas de sens - vous comparez contre la valeur envoyée - c'est un mot de passe par un autre nom. Ainsi, comme un attaquant, au lieu de voler le mot de passe, j'ai juste besoin de voler le HMAC stocké sur la machine client. Rien n'est gagné du tout ici.
Je préférerais beaucoup que certains attaquants aléatoires connaissent mon hachage que mon mot de passe réel que je réside probablement dans divers endroits
Je n'ai pas cette réponse. Le mot de passe stocké au côté du client n'est pas en clair, c'est bon. Et l'accès à la table des mots de passe à double hachée sur le serveur ne permet pas à un attaquant de se connecter, c'est aussi bon. Certes, l'accès à la hausse stockée sur le client permet toujours de se connecter et l'accès à la table du serveur signifie gros problème, mais je crois toujours que la sécurité globale est améliorée par l'idée proposée?
Comment? Tout ce que vous faites consiste à remplacer un mot de passe de texte brut avec une version hachée de celui-ci. La version hachée est maintenant le mot de passe, vous avez simplement remplacé un mot de passe texte avec un binaire. Ce binaire est toujours stocké clairement et peut être découvert et utilisé. Le seul avantage consiste à cacher le mot de passe d'origine, ce qui n'est qu'un avantage si l'utilisateur l'utilise ailleurs.
La réutilisation du mot de passe est assez courante et non quelque chose que nous pouvons empêcher les utilisateurs de faire. Compte tenu de ces faits, ce régime diminue les risques de compromettre d'autres systèmes et est définitivement une valeur dans ce sens. En regardant cette autre solution: si tous les autres sites Web ont mis en œuvre un schéma dans lequel leurs serveurs n'ont jamais eu de mots de passe en clair des utilisateurs en mémoire, il augmenterait la sécurité de votre propre système. Si vous pouviez faire signe une baguette magique et faire tout autre site web, le feriez-vous?
WinDart frappe le clou sur la tête - vous changez simplement le secet pour voler, ne pas sécuriser quoi que ce soit. Ce que vous êtes essayer à reproduire est un ancien protocole d'authentification que je ne peux pas pour la vie de moi, souvenez-vous du nom de. Voici comment ça marche:
Lors de l'initialisation, le serveur reçoit votre mot de passe, hashé de manière itérative N Times, représentés par F N (PASS). Le client a le mot de passe et le nombre n.
Vous allez vous authentifier et envoyez le serveur F N-1 (PASS) - c'est-à-dire le mot de passe haché n-1 fois. Le serveur hachait une fois de plus, le compare à F n (passe) et s'ils correspondent à l'accès. Le serveur remplace ensuite F n (passe) avec f n-1 (passe) et vous décrémenter n.
La prochaine fois que vous allez vous authentifier, envoyez F N-2 (PASS) et le processus se répète.
Examinons la sécurité:
C'est ce que vous essayez d'accomplir. Cependant, il y a une raison pour laquelle ce protocole n'est pas utilisé - c'est une chienne géante à synchroniser. Si le client et le serveur sortent de la synchronisation en raison d'une étape semi-complétée, vous êtes verrouillé. Toute résilience que vous avez construite pour éviter cela réduirait probablement la sécurité de rejouer ou d'écouter.
Il s'agit d'un système de mot de passe ponctuel, des exemples incluant RSA Securid et S / Key. Voir ietf.org/rfc/rfc2289.txt et EN.Wikipedia.org/wiki/one-time_password
MD5 () n'est pas sûr. En outre, ce n'est pas un protocole sécurisé.