Ce schéma de connexion est-il sécurisé?

Question

Voici ce que j'ai obtenu pour un schéma de connexion webapp. Présenter dans la base de données serait deux sels et hmac (hmac (mot de passe, salt1), sel2).

Lorsque l'utilisateur va sur la page de connexion, il obtient salt1. Si javascript est activé, au lieu d'envoyer le mot de passe en clair, il enverra hmac (mot de passe, salt1). S'il n'a pas javascript, le mot de passe en clair est envoyé. Donc, sur le côté serveur, lorsque nous recevons une requête de connexion, nous vérifions d'abord ce qui est envoyé (passwordSent) par rapport à hmac (passwordSent, salt2). Si cela ne fonctionne pas, nous allons essayer hmac (hmac (passwordSent, salt1), salt2). Quelqu'un qui accède à la base de données ne devrait pas pouvoir se connecter avec les hachages de mot de passe et je ne pense pas (mais je peux me tromper) que plusieurs hmacs diminuent la résistance de hachage. Est-ce qu'un bon expert crypto voit une erreur évidente que j'ai pu faire?

Answer 1

Cela ressemble un peu à la sécurité par l'obscurité, à quoi cela sert-il d'utiliser javascript pour hacher le mot de passe côté client si vous acceptez encore le mot de passe en texte brut du client?

Vous n'avez pas mentionné si c'était plus de https, si vous n'utilisez pas https alors vous pourriez aussi bien n'avoir aucun mot de passe. Si vous n'utilisez pas https, n'importe quel MITM peut voir le sel que vous envoyez ainsi que le javascript utilisé pour hacher le mot de passe d'origine afin que vous n'ayez rien gagné. En ce qui concerne votre inquiétude quant à la possibilité de collisions hmac entre deux sels, c'est probablement très improbable (en fonction de votre algorithme de hachage) et à quel point vous gardez vos valeurs de sel. Même avec MD5 qui a eu des attaques de collision découvertes et a un ensemble de tables arc-en-ciel, vous serez bien si vous gardez votre sel très très sûr.

S'il vous plaît, tout le monde, s'il vous plaît arrêter d'essayer de mettre en œuvre des systèmes crypto personnalisés sauf si vous avez un arrière-plan dans cryptographie. Vous allez bousiller. --Aaronaught

Bien dit!

Answer 2

Probablement évident pour vous, mais vous laissez effectivement les gens se connecter avec deux mots de passe différents dans cette configuration.

Si vous voulez donner aux gens l'option d'envoyer leurs mots de passe avec le cryptage, je ne lierais pas cela à quelque chose strictement du côté client, et je forcerais juste HTTPS, comme Harley l'a déjà laissé entendre.

Answer 3

Vous voudrez peut-être regarder HTTP Digest authentication. C'est un protocole standardisé qui évite en tout cas le mot de passe en clair.

Answer 4

Cela me semble assez farfelu. Si l'objectif est d'empêcher une attaque «man-in-the-middle» en raison de l'envoi du mot de passe en clair par HTTP, alors utilise SSL.

Le hachage du côté client n'aboutit à rien; sauf si le sel est en réalité un nonce/OTP, et pas stocké dans la base de données, alors un homme au milieu peut simplement regarder le hachage envoyé par le client d'origine et le transmettre au serveur. Le serveur ne connaîtra pas la différence.

Si cela est censé le rendre plus difficile à se fissurer si quelqu'un se saisit de la base de données, il ne sera pas. Si la fonction de hachage est bon marché, comme MD5, ce ne sera pas plus difficile à casser qu'un sel et un hachage (en fait c'est plus faible, puisque le hachage est une fonction avec perte). Et si vous utilisez une fonction de hachage fort comme bcrypt, c'est déjà assez bon.

S'il vous plaît, tout le monde, s'il vous plaît cesser d'essayer d'implémenter des systèmes de chiffrement personnalisés, sauf si vous avez un arrière-plan en cryptographie. Vous va le visser.