Mots de passe de l'application Web: bcrypt et SHA256 (et scrypt)
avec toutes les discussions récentes (par exemple LinkedIn) sur les mots de passe, je cherche des implémentations de hachage de mots de passe. Après deux tasses de café et une lecture matinale, Je ne suis plus cryptographe. Et je ne veux vraiment pas prétendre que je le suis.
Questions Spécifiques
l'utilisation d'un identifiant d'utilisateur unique entier échoue-t-elle comme un sel efficace? (crypt () utilise seulement 16 bits?)
Si je exécuter sha256 () sur un hachage encore et encore jusqu'à ce qu'une seconde est épuisée est-ce que cela bat les attaques de la force brute?
si je dois poser ces questions, devrais-je utiliser bcrypt?
Discussion / Explication:
le but est simplement si les mots de passe hashés de mon utilisateur ont été divulgués ils:
- ne serait pas "facile" à craquer,
- le craquage d'un mot de passe n'exposerait pas les autres utilisateurs utiliser le même mot de passe).
ce que j'ai lu pour #1 est que le calcul du hachage doit être coûteux -- prendre, disons, une seconde ou deux pour calculer et peut-être un peu ou de la mémoire (pour contrecarrer le déchiffrement du matériel).
bcrypt a ceci intégré, et scrypt, si je comprends bien, est plus à l'épreuve du futur et inclut une exigence minimale d'utilisation de la mémoire.
mais, est-ce une approche tout aussi efficace de manger du temps en "ressassant" le résultat de sha256() comme plusieurs fois si nécessaire pour utiliser quelques secondes puis stocker le décompte final de boucle avec le hachage pour vérifier plus tard un mot de passe fourni?
pour #2, Utiliser un sel unique pour chaque mot de passe est important. Ce qui n'est pas clair, c'est à quel point le sel doit être aléatoire (ou grand). Si le but est d'éviter que tous ceux qui utilisent "mypassword" comme mot de passe n'aient le même hachage, n'est-ce pas suffisant?:
hash = sha256_hex( unique_user_id + user_supplied_password );
ou même ça, même si Je ne suis pas sûr que ça m'achète n'importe quoi:
hash = sha256_hex( sha256( unique_user_id ) + user_supplied_password );
le seul avantage que je peux voir en utilisant L'ID de l'utilisateur, en plus je sais qu'il est unique, est d'éviter d'avoir à sauver le sel avec le hash. Pas vraiment un avantage. Y a-t-il un vrai problème à utiliser L'identifiant d'un utilisateur comme sel? N'accomplit-il pas le N ° 2?
je suppose que si quelqu'un peut voler les mots de passe hachés de mon utilisateur alors je dois supposer qu'ils peuvent obtenir ce qu'ils veulent -- y compris le code source qui génère le hachage. Donc, est-il un avantage à ajouter une chaîne de caractères aléatoire supplémentaire (la même chaîne) au mot de passe avant le hachage? Qui est:
# app_wide_string = one-time generated, random 64 7-bit *character* string.
hash = sha256_hex( unique_user_id + app_wide_string + user_supplied_password );
j'ai vu que suggéré, mais je ne comprends pas ce que je gagne de cela sur le sel par utilisateur. Si quelqu'un voulait forcer l'attaque, il saurait que "app_wide_string" et l'utiliserait pour lancer son attaque au dictionnaire, n'est-ce pas?
y a-t-il une bonne raison d'utiliser bcrypt pour rouler les miennes comme décrit ci-dessus? Peut-être le fait que je demande ces les questions sont une raison suffisante?
BTW, j'chronométré existant fonction de hachage j'ai et sur mon portable et je peux générer environ 7000 hache une seconde. Pas tout à fait les une ou deux secondes qui sont souvent suggérées.
Quelques liens:
utilisant sha256 comme hashing et salting avec l'ID de l'utilisateur
SHA512 vs. Blowfish and Bcrypt
Quelle est la longueur optimale pour l'utilisateur mot de passe le sel?
2 réponses
Bcrypt est génial parce que vous pouvez ajuster le facteur de travail de 4 à 31, chaque incrément crée un temps requis exponentiel, Je l'ai en fait graphique, à un facteur de travail de 14 Il prend déjà plus d'une seconde, de sorte que les ordinateurs deviennent de plus en plus rapides, vous avez seulement besoin de changer un paramètre, et bien sûr mettre à jour votre mot de passe hash ...
ma principale préoccupation avec bcrypt est que si le facteur de travail est réglé à haut, alors il peut surcharger votre système que les utilisateurs multiples essaient de se connecter donc, vous devez les régler, en fonction du nombre de connexions simultanées et les ressources de votre système ...
les sels sont toujours nécessaires, leur but principal est de décourager les attaques hors ligne, si l'espace salin est trop grand, alors l'adversaire ne sera pas en mesure de générer la table de recherche, le sel 64 bits semble un peu faible, bcrypt a 128 bits de sels couplés avec le facteur de travail rend tout à fait un défi pour les attaques hors ligne ... et oui le sel doit être aléatoire pour chaque mot de passe, générer un pour vous, si vous utilisez le même sel pour chaque mot de passe, alors vous avez rendu plus facile pour l'adversaire de comprimer tous les mots de passe en utilisant une attaque en ligne.
Bcrypt brille vraiment pour les attaques en ligne, si vous avez mis le facteur de travail correctement, parce que même si je reçois le hachage, destiné à dire si l '"adversaire" obtient le hachage, le facteur de travail rend vraiment douloureux de passer par un dictionnaire entier, prenant plusieurs jours et si le mot de passe n'est pas dans le dictionnaire, alors Je suis vraiment en difficulté car une attaque de force brute sera épique, l'espace de bits de mot de passe pour bcrypt est assez grand bien que limité :)
Sha256 peut prendre un peu de temps maintenant, mais éventuellement les ordinateurs vont devenir de plus en plus rapides et ce sera assez facile pour les attaques, les gars d'unix pensaient crypt était si lent qu'il n'aurait jamais être un problème, et aujourd'hui, j'ai fait une attaque en ligne en quelques secondes, une attaque hors ligne en quelques jours, une attaque de force brute (en passant par l'espace de bits de mot de passe entier) dans semaine. ..
- vous voulez que le sel soit aussi grand et aléatoire que possible en utilisant seulement des nombres, il est plus facile pour moi d'itérer sur tous les ids possibles.
- plusieurs sha256 peuvent prendre une seconde maintenant, mais plus tard, il ne sera pas efficace plus, les ordinateurs puissance de traitement augmente exponentiellement et donc vous voulez un algorithme qui peut être configuré comme tel.
- vous faites la bonne chose en posant des questions et faire vos devoirs si plus de gens faisaient cela, nous n'aurions pas autant de brèches
l'utilisation d'un identifiant d'utilisateur unique entier échoue-t-elle comme un sel efficace? (crypt () utilise seulement 16 bits?)
vous utilisez normalement un sel généré au hasard et stockez ensuite ce hachage avec le mot de passe crypté. Peu importe que l'attaquant ait également accès au sel - son but est d'empêcher l'utilisation d'une table de recherche, forçant ainsi l'attaquant à forcer chaque hachage individuellement.
crypt magasins le sel et le hachage dans un chaîne unique, avec l'algorithme à utiliser.