Côté Client MD5 Hash avec sel de temps
je veux saler un nom d'utilisateur et un mot de passe hashés (soumis par http POST) dans JS côté client avec une valeur de temps d'ordre plus élevé (résolution< 1 minute) pour éviter d'envoyer le nom d'utilisateur et le hachage de mot de passe comme une valeur constante qui pourrait être utilisée pour une tentative de connexion via POST fabrication par un utilisateur non autorisé (c.-à-d. un renifleur).
cela imposera une courte échéance à l'utilité du hachage passé.
s'ils inspectent le JS et voient que il utilise cette fois-ci du sel, à quel point sera-t-il plus facile de briser le MD5 s'ils savent ce qu'est le sel?
Stephen
4 réponses
Le le sel n'a pas besoin d'être secret . Dans ce sens, votre solution est correcte.
MD5 est cassé dans certaines applications; celui-ci pourrait être correct, mais pourquoi ne pas utiliser un hachage de la SHA-2 famille ? D'ailleurs, pourquoi ne pas utiliser SSL pour fournir un canal confidentiel, et une meilleure sécurité?
le sel à base de temps ne rendra pas MD5 plus facile à briser. Vous comptez toujours sur 1) l'utilisateur ayant un bon mot de passe pour vaincre les calculs de force brute, et 2) MD5 étant un hachage décent. C'est la réponse de base à votre question. Toutefois, cela peut ne pas être une bonne idée de toute façon. Quelques commentaires--
sauf si vous pouvez vous assurer que l'heure du client ou du serveur est synchronisée (ou si vous utilisez Javascript pour simuler une synchronisation), le client devrait envoyer l'heure qu'il utilise comme sel. Le serveur devra décider si le temps était assez près de l'heure du serveur.
même si vous êtes synchronisé, vous devrez probablement accepter des hachures plus ou moins une minute ou plus à cause de la latence sur Internet. Un autre problème est que si je renifle je pourrais immédiatement réutiliser ce hash tant que je suis toujours dans cette fenêtre de temps.
en raison des problèmes ci-dessus, une meilleure idée est d'utiliser un serveur unique sel assigné avec le hachage on dirait que tu ne veux pas utiliser SSL. En d'autres termes, chaque fois qu'un formulaire de connexion est envoyé au client, le serveur génère une chaîne de sel aléatoire et unique, l'envoie au client et garde trace qu'il s'agit d'un sel acceptable. Puis le client l'utilise comme sel avec le mot de passe. Après cela est soumis une fois, le serveur le rejette comme une chaîne de sel acceptable. Il ne devrait jamais y avoir deux coups de fouet identiques. L'inconvénient de cette est que vous devez garder une trace de ces acceptables sel cordes.
leur travail deviendra infaisable, puisque vous ne pouvez pas utiliser une table arc-en-ciel du tout si le hash est salé correctement, et vous ne pouvez pas briser MD5 en moins d'une minute, à ce moment-là le hash est invalidé de toute façon.
vous pourriez utiliser le code obfuscation pour rendre le sel plus difficile à trouver