hash côté client / salage via HTTPS

Question

Je me demande quels sont les problèmes graves sont avec la configuration suivante:

Nom d'utilisateur / mot de passe système de connexion Javascript / ajax demande la valeur de sel du serveur (nous avons établi dans le sel des questions précédentes ne sont pas une valeur secrète) Javascript préformes SHA1 (ou non) du mot de passe et le sel. Javascript / ajax retourner le hachage au serveur Le serveur applique un autre sel / hachage sur-dessus du celui envoyé via Ajax.

Les transactions sont sur HTTPS.

Je suis préoccupé par les problèmes qui peuvent exister, mais ne peut me convaincre que cela est si mal d'une configuration. On suppose que tous les utilisateurs doit accepter le Javascript comme jQuery est largement utilisé sur le site. Il est tentant essentiellement d'ajouter une couche de sécurité supplémentaire au texte brut d'un mot de passe.

Answer 1

Tous ces efforts de sels et passer hash entre le client et le serveur est déjà intégré dans le protocole HTTPS / SSL sous-jacent. Je serais très surpris si une couche de sécurité en javascript va aider beaucoup. Je recommande le garder simple et l'utilisation plaintext sur SSL sur le côté client. Inquiétude au sujet de chiffrement sur le côté serveur.

Answer 2

Comme toujours:. Faire très attention à la conception de protocoles cryptographiques vous

Mais cela étant dit, je peux voir l'avantage dans le système. Il protection contre le mot de passe étant révélé par un homme-in-the-middle-attaque et assurez-vous que le serveur ne voit jamais le mot de passe réel, empêchant ainsi certains à l'intérieur attaques. D'autre part, il ne protège pas contre l'homme-in-the-browser, pêche etc.

Vous pouvez lire RFC 2617 sur l'authentification d'accès HTTP Digest. Ce régime est semblable à ce que vous proposez.

Answer 3

Cela n'ajoute pas de sécurité supplémentaire. Le code JavaScript est présent dans le client, de sorte que l'algorithme de hachage est connu. Vous ne gagnez rien de faire un hachage côté client dans ce cas.

En outre, il n'y a aucune raison pour laquelle le client doit savoir sur le sel de hachage. Il en fait devrait une valeur secrète, surtout si vous utilisez un sel partagé.

Answer 4

Vous n'êtes pas quoi que ce soit gagnant. Il n'y a aucun point à un sel si Joe Public peut le voir en cliquant sur Affichage> Source et la vieille maxime de ne jamais faire confiance à l'entrée client va doubler pour le hachage de mot de passe.

Si vous voulez vraiment augmenter la sécurité, utilisez un hachage à base de SHA-2 (SHA-224/256 / 384/512), SHA-1 a des vulnérabilités potentielles. NIST ne recommande plus SHA-1 pour les applications qui sont vulnérables aux attaques de collision (comme les mots de passe).

Answer 5

Je 100% en désaccord avec la réponse acceptée et dire que, dans aucun cas, un mot de passe original jamais jamais jamais quitter le client. Il doit toujours être salée et hachée. Toujours, sans exception.

Deux raisons ... . Le client ne doit pas se fiera que tous les composants du serveur et les réseaux internes sont TSL. Il est assez courant pour le point final de TSL d'être un équilibrage de charge proxy inverse, qui communique avec les serveurs d'applications à l'aide parce que DevOps plaintext ne peuvent pas être pris la peine de générer serveur certs pour tous leurs serveurs internes.

. De nombreux utilisateurs sont pathologiquement enclins à utiliser un mot de passe commun pour tous leurs services. Le fait qu'un serveur a des mots de passe en clair, même si seulement en mémoire, en fait une cible attrayante pour les agressions extérieures.