2010-05-20 8 views
6

Im la recherche de la façon la plus sûre (mais faisable) de gestion de mot de passe dans une application web.Gestion de mot de passe WebApp - Hashing, salage, etc

En ce moment, je garde le mot de passe comme hash. Le compte DB de l'application est limité à l'exécution des procédures stockées et j'authentifie les utilisateurs en donnant le nom d'utilisateur et le mot de passe haché à une procédure stockée qui renvoie 1 (vrai) ou 0 (faux).

Il n'y a donc aucune chance d'obtenir le mot de passe du serveur, même si vous avez le compte DB de l'application. C'est ce que j'aime dans cette solution. Mais pour l'utiliser, le client doit soumettre son mot de passe sur le web, ou au moins un hash statique qui pourrait être intercepté.

alors je suis venu idée d'utiliser une poignée de main comme ceci:

  • client demande au serveur pour le sel.
  • Le sel aléatoire est donné au client et stocké sur le serveur pour ce client unique.
  • client fait Hash (sel + mot de passe) et retourne ce hachage au serveur
  • serveur fait Hash (sel + mot de passe) et vérifie si le même alors du client

En utilisant cette poignée de main permet de vérifier le mot de passe sans s'envoyer ou un hachage statique de celui-ci. Juste un hachage salé dynamique, qui est différent chaque fois que l'utilisateur se connecte => Hautement sécurisé.

Mais pour cette poignée de main, j'ai besoin du mot de passe ou au moins du mot de passe haché de la base de données. Mais cela permet à quelqu'un d'obtenir au moins le mot de passe haché et de le forcer à l'extérieur de l'application.

Que préférez-vous? Garder le mot de passe à l'intérieur de la base de données et y faire quelque chose (serveur sécurisé), ou le sortir de la base de données et le faire à l'extérieur (transmission sécurisée)?

Merci à l'avance, Marques

Répondre

3

Votre solution proposée ne résout pas vraiment le problème. Le serveur doit néanmoins connaître le mot de passe, il doit donc être transféré à un moment donné, ce que vous voulez éviter en premier lieu. De cette façon, vous évitez seulement d'envoyer à nouveau le mot de passe à chaque fois, mais si quelqu'un l'a attrapé la première fois, il a été transféré?

Je pense que vous ne devriez pas réinventer la roue :-) Utilisez SSL pour toutes les connexions et vos premières solutions fonctionnent bien. Vous pouvez même effectuer le hachage côté client, de sorte que seul le hachage est envoyé sur le canal sécurisé. Votre serveur ne connaîtra jamais le mot de passe, et ce n'est pas obligatoire.

+1

D'accord, le protocole SSL devrait être suffisamment sécurisé. Définit sans aucun doute les mots de passe dans la base de données, bien que MD5 soit suspect ces jours-ci afin que je puisse utiliser un algorithme de hachage plus sécurisé pour le faire. Votre poignée de main proposée est similaire à MS-CHAP qui est également suspect. –

+0

Vous avez raison, mais je pense qu'il est moins probable que le mot de passe soit reniflé cette fois-ci, que l'un des centaines ou milliers de fois suivants l'utilisateur se connecte. Ma connexion est SSL moins, je voulais juste une sécurité supplémentaire . En ce moment j'utilise FormsAuthentications construit dans le hachage SHA1, mais j'ai besoin de SHA-256 à un autre endroit, donc je pense que je vais passer à cela. Vous pensez que la procédure stockée GetUser doit renvoyer un mot de passe haché? Ou juste retourner null à la place? – Marks

+1

Lorsque vous parlez de «sécurité», vous supposez toujours le pire scénario. Vous supposez que l'attaquant est toujours présent et exploite toutes les faiblesses de votre système avec une efficacité maximale.En ce sens, peu importe s'il peut lire votre mot de passe une fois ou une centaine de fois, en fait il peut le lire. Vos clients ne veulent pas vous entendre dire "il est peu probable qu'un attaquant puisse lire votre mot de passe" :-) Que votre procédure stockée renvoie le hash ou 'null' est à vous, le serveur doit être protégé par d'autres moyens pour empêcher l'accès à distance de toute façon (pare-feu, correctifs de sécurité, ...) –