Challenge stimulant: Hashing de mot de passe client et vérification du mot de passe côté serveur
Nous avons un site Web où les utilisateurs doivent se connecter pour accéder à des informations privilégiées. Évidemment, nous utilisons SSL, mais je souhaite également éviter les mots de passe en clair à partir de manière accidentelle dans des journaux de serveur ou des yeux errants d'administrateurs. Par conséquent, je souhaite mettre en œuvre le hachage côté client à l'aide de JavaScript.
De plus, je souhaite éviter de révéler des paires d'utilisateurs avec des mots de passe identiques, utilisez ainsi un sel spécifique à l'utilisateur. Enfin, j'aimerais ajouter un défi aléatoire (AKA SANSCE) dans le mélange pour assurer un écouteur * ne peut pas utiliser le hachage final comme nouveau "mot de passe". Je ferai un aller-retour supplémentaire sur le serveur Web pour obtenir le sel et le défi avant de commencer le hachage de mot de passe. *) Oui, nous utilisons SSL, mais comme une défense en profondeur, je voudrais rendre la mise en œuvre aussi solide que possible.
Surtout le défi est difficile. La seule mise en œuvre réalisable que je connaisse, est d'abord calculer le hachage de mot de passe final (en utilisant BCRYPT, SCRYPT ou PBKDF2), puis effectuez une partie supplémentaire SHA256_HMAC en utilisant le défi. Sur le côté serveur, nous récupérons le HASH de mot de passe de la base de données et effectuez le même SHA256_HMAC supplémentaire et comparez le résultat.
Cependant, ce qui précède impliquerait que le calcul du mot de passe plein doit être effectué côté client dans JavaScript, car le hachage dans le défi devrait toujours être la dernière étape. Sur un héritage (?) IPhone 3G, seuls 6 rounds BCRYPT, ou 5 000 rounds PBKDF2-SHA256 peuvent être effectués dans les 2 secondes, ce qui correspond au retard maximum que nous pouvons tolérer.
Question n ° 1: Est-ce que je corrige que de nos jours, BCRYPT devrait être d'au moins 12 tours et PBKDF2-SHA256 au moins 5000 tours? Donc, je devrais choisir les 5000 tours de PBKDF2-SHA256?
Question n ° 2: Existe-t-il des mécanismes de défi-réponse pouvant fonctionner plus tôt dans le processus (par exemple sur un mot de passe autrefois haché), afin que je puisse laisser le durcissement BCRYPT/PBKDF2 sur le serveur WebServer?
Question n ° 3: En supposant qu'aucun mécanisme de défi de défi de ce type n'existe, est-il préférable d'abandonner mes exigences relatives à la réponse au défi et n'appliquez que un côté clientèle spécifique à l'utilisateur et faire du côté du serveur de durcissement complet? Cela résulterait-il d'un système global plus fort que d'utiliser un mécanisme de défi-réponse et moins de tours?
EDIT: Pour résumer le long sentier des commentaires ci-dessous sur la sécurité du hachage de la clientèle en général: l'avis général semble être que la complexité accrue ne vaut pas la peine et il est préférable de mettre l'effort d'audit le code côté serveur. et limiter l'accès côté serveur pour le personnel non approuvé.
Je pense que vous gaspillez votre temps et vous ajoutez une complexité inutile. Je ne pense pas que les raisons que vous donnez sont suffisantes pour garantir ce type de mécanisme de hachage de mot de passe côté client.
Au lieu de cela, je suggère de garder cela simple. Envoyez le mot de passe sur un lien SSL-crypté. En matière de sécurité, Simple est bon. La complexité inutile est l'ennemi de la sécurité, car il introduit la possibilité de bugs et d'erreurs.
Enregistrez votre énergie pour d'autres tâches de sécurité qui aborderont des menaces plus réalistes. Il y a une limite de temps et d'énergie et de budget que vous pouvez dépenser pour améliorer la sécurité; Il est préférable de le dépenser sur les endroits qui donneront le plus grand coup pour l'argent (la plus grande amélioration de la sécurité, compte tenu de l'investissement). Je pense que vous trouverez que vous pourrez trouver d'autres moyens de dépenser votre système de durcissement qui améliorera plus la sécurité.
Si vous êtes inquiet de savoir si le code côté serveur gère le mot de passe de manière appropriée, examinez attentivement ce code: il doit être contenu dans un très petit morceau de code. Cela devrait s'occuper des risques tels que, par exemple, les mots de passe ClearText ClearText: vous viennent de lire toutes les lignes de code impliquées dans la vérification du mot de passe ou qui lit le mot de passe, assurez-vous que la première chose à laquelle il fait est de haquer le mot de passe de manière appropriée et de faire Assurez-vous que tout ce qu'il fait, c'est vérifier le mot de passe de validité et retourne vrai ou faux. Si votre système est bien conçu, cela devrait être assez simple de vérifier via un examen du code. Si le code n'est pas bien conçu, vous seriez peut-être un bon moment pour résoudre ce problème.
Si vous ne l'avez pas déjà fait, vous voudrez peut-être examiner SRP. Cela devrait répondre à toutes vos exigences, si vous souhaitez un système de défi/type de réponse.
http://fr.wikipedia.org/wiki/secure_remote_password_protocol
Je me méfierais de tout protocole préparé à la maison. Je me méfierais également de tout protocole d'authentification basé sur le hachage client. Votre meilleur pari est d'étudier authentification NTLM et le grand nombre d'attaques contre ce protocole. Tels que le NTLM faible nonce vulnérabilité .
(SRP n'est pas mauvais, SRP-TLS a l'air assez cool.)
Non, vous êtes encore trop petite. Mot de passe OWASP Feuille de stockage Cheat recommande 64.000 itérations PBKDF2 en 2012 et les doubler tous les 2 ans (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet).
Voir les autres réponses ci-dessus.
Vous avez la possibilité de faire un peu de côté client hash (disons, 2.000 tours PBKDF2_SHA-1), puis une fois le résultat de qui obtient au serveur, exécutez-le par un autre grand ensemble de hachage (par exemple, 300.000 tours de PBKDF2_SHA- 512), et comparer cette valeur finale.
Votre base de données stocke uniquement la valeur double PBKDF2 finale.
Vos fichiers journaux Web et/ou éventuellement faibles sessions SSL utilisent la valeur unique PBKDF2 intermédiaire. Bien que cette valeur intermédiaire est certainement beaucoup, beaucoup plus faible que la valeur finale, il est encore beaucoup plus fort que clair.
Notez que vous devez également vérifier les mots de passe des utilisateurs proposent lors d'un changement de mot de passe/sélectionner un nouveau mot de passe contre un dictionnaire fissuration normale avec certaines règles (en minuscules à la fois pour éliminer les jeux de cas, ajouter des numéros de 1 à 1000 après la Parole, ajouter des dates après un mot , les traductions de 1337 Speak de base, etc.) pour empêcher la " forte " mot de passe " P @ $$ w0rd " (majuscules, minuscules, symboles et des chiffres - 8 caractères, il doit être très fort) d'apparaître.