Stockage et transfert sécurisés des mots de passe

Je suis en train de développer un nouveau magasin pour mon organisation et je m'occupe maintenant du stockage des mots de passe. Les concepts de salage, HMAC etc sont bien avec moi - et veulent stocker les mots de passe des utilisateurs soit salés et hachés, HMAC haché, ou HMAC salé et haché - pas sûr de la meilleure façon, mais en théorie, il a gagné » Peu importe, car il sera en mesure de changer au fil du temps si nécessaire.Stockage et transfert sécurisés des mots de passe

Je souhaite avoir un service JSON XML & pouvant servir de service de jetons de sécurité pour les applications côté client. J'ai déjà développé un pour un autre système, ce qui nécessite que le client double-crypte un mot de passe en clair en utilisant SHA1 d'abord, puis HMACSHA1 en utilisant une clé unique (ou non) fournie par le serveur pour cette session seulement . Je voudrais répéter cette technique pour le nouveau système - la mise à niveau de l'algo vers SHA256 (choisi puisque les implémentations sont facilement disponibles pour toutes les plates-formes susmentionnées - et c'est beaucoup plus fort que SHA1) - mais il y a un problème.

Si je stocke le mot de passe comme un hachage salé dans le magasin d'utilisateurs, le client devra être envoyé ce sel afin de construire le hachage correct avant d'être HMACd avec la clé de session unique. Cela irait complètement à l'encontre de l'utilisation d'un sel en premier lieu. De même, si je n'utilise pas de sel pour le stockage de mot de passe, mais que j'utilise plutôt HMAC, c'est toujours le même problème.

Pour l'instant, la seule solution que je peux voir est d'utiliser le hachage SHA256 nu pour le mot de passe dans le magasin de l'utilisateur, afin que je puisse l'utiliser comme point de départ sur le serveur et le client. transfert de mot de passe salé/hmacd pour le service Web. Cela laisse toujours le magasin de l'utilisateur vulnérable à une attaque de dictionnaire où il aurait jamais été accédé; et aussi improbable que cela puisse être - en supposant que cela n'arrivera jamais, cela ne va pas avec moi.

Appréciez grandement n'importe quelle entrée.

Source

2010-03-30 Andras Zoltan

"en théorie, cela n'aura aucune importance, car il sera possible de changer au fil du temps si nécessaire." - non; Une fois que vous avez correctement haché les mots de passe **, vous ne pouvez pas les reconstruire **. Par conséquent, vous ne pouvez pas les re-masquer sous un algorithme différent. Vous devez décider maintenant. –

Je voulais dire au niveau de la programmation; Ce n'est pas grave si maintenant je repense à une façon de le faire et ensuite passer à une autre manière avant de finalement libérer le système. Une fois qu'il est déployé et en cours d'exécution, bien sûr, je sais que je ne peux pas le changer! –

HTTPS est la meilleure solution pour ce problème.

Vous lancez beaucoup de primitives crypto à ce problème dans l'espoir qu'il disparaîtra. En général, le protocole que vous proposez semble gaspiller des ressources, je recommande de faire des recherches sur d'autres protocoles d'authentification et de réfléchir à des moyens de simplifier votre protocole. Practical Cryptography est un excellent livre.

Le plus gros problème est de voir dans le transfert de secrets entre le client et le serveur. Pour l'implémenter correctement, vous devez utiliser un échange de clé Diffie-Hellman.Heureusement, il a déjà été écrit en javascript:
http://enanocms.org/News:Article/2008/02/20/Diffie_Hellman_key_exchange_implemented

Un autre problème est que je ne vois pas comment le client peut déterminer que son parler au bon serveur. SSL utilise une cryptographie asymétrique, soutenue par une PKI, que vous ne pourrez pas implémenter en JavaScript. Un résumé de message n'est pas un algorithme de cryptage. Il n'est jamais correct de renverser un hash de mot de passe, où le texte chiffré est destiné à protéger contre une écoute indiscrète. La diffusion d'un mot de passe à un attaquant rendra vos mots de passe moins sécurisés. Si l'attaquant a un sel, ils peuvent utiliser un dictionnaire pour attaquer le mot de passe, sans le sel qu'ils auront à deviner au hasard, ce qui rendra le système de stockage de mot de passe beaucoup plus robuste.

Source

2010-03-30 23:29:35 rook

Je vois ce que vous voulez dire; le salage pourrait le rendre plus difficile - mais pas impossible. J'ai commencé à envisager la mise en œuvre de SRP parce que le recours au Https entraîne des complications: problèmes de coût associés à l'achat de lots de certificats ssl pour potentiellement beaucoup de noms de domaine différents; et aussi parce que cela complique l'utilisation du STS via javascript à partir d'une page web qui n'est pas elle même Https. Cependant, je pense que Https est probablement le meilleur moyen d'y aller pour le moment - mais je voudrais vraiment cracker SRP (c'est juste de trouver des implémentations pour chacune de mes plates-formes clientes!) –

@Andras Je pense que c'est une mauvaise raison utilisant ssl. La sécurité est très chère, sauf ssl est bon marché, 30 $ pour un cert est un prix fantastique et c'est la seule façon d'arrêter MITM. Même si vous allez avec l'échange de clé DH, vous ne pouvez pas être entièrement protégé. Il n'y a pas d'alternative à ssl. À la fin de la journée, votre serveur devra crypter et décrypter le trafic et cela va manger des ressources. – rook

Fair point - pourquoi rouler le vôtre quand il y a déjà quelque chose qui fait parfaitement l'affaire! Il est temps de les laisser savoir à l'étage que nous devons augmenter les estimations de coûts :) –

Un sel n'a pas besoin d'être secret - il doit être unique. un sel est conçu pour atténuer la menace de deux utilisateurs ayant le même mot de passe et donc le même hachage. Ainsi, vous pouvez utiliser le nom de l'utilisateur comme sel si vous le souhaitez. un salt rend beaucoup plus difficile une attaque de dictionnaire car l'attaquant doit calculer chaque résultat pour chaque mot du dictionnaire et chaque sel possible. À mon avis, j'utiliserais une fonction de dérivation de clé basée sur un mot de passe (PBKDF) avec un nombre élevé d'itérations et un sel.

http://www.bing.com/search?q=pbkdf2

est ici un exemple de code en C#, mais il est vain dans la plupart de tout cadre populaire aujourd'hui http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

Source

2010-03-30 13:48:07

Je viens de lire autour et ce penny particulier est tombé autour de la même heure que vous avez fait cette réponse! Je vois la logique de PBKDF - il ne semble pas y avoir une implémentation en Objective-C qui pourrait être utilisée sur l'iPhone - argh. –

Comme une question rapide - il semble que le but principal de PBKDF est de ralentir les attaques de dictionnaire, car il prend simplement si longtemps. Pensez-vous qu'une alternative acceptable consiste à répéter explicitement un cryptage HMAC SHA 256? –

En fait, il est important de garder le secret secret car cela empêche les attaques par dictionnaire. john l'éventreur est un outil de craquage automatisé qui accepte un sel comme paramètre, si l'attaquant n'a pas le sel, alors il doit deviner au hasard. – rook

Stockage et transfert sécurisés des mots de passe

Répondre

Questions connexes