Est-il préférable d'utiliser un algorithme de hachage inapproprié au lieu de n'en utiliser aucun?
Je dois stocker les mots de passe sur un système qui n'offre aucun des algorithmes recommandés pour le hachage des mots de passe (par exemple bcrypt, scrypt ou PBKDF2). Serait-il préférable d'utiliser un algorithme inapproprié (par exemple la famille SHA-1 ou SHA-2) avant d'en utiliser aucun?
Informations supplémentaires: Je serai le seul à stocker des mots de passe sur ce système, je peux donc 1) garantir qu'aucun des mots de passe ne sera utilisé deux fois et 2) garantir que les mots de passe auront une entropie très élevée .
La vraie réponse à votre question est simplement de ne pas y stocker les mots de passe si vous ne pouvez pas les protéger correctement.
"Le système ne prend pas en charge les algorithmes de hachage de mot de passe appropriés" n'est pas une excuse valable pour compromettre la sécurité de vos utilisateurs. Soit trouver un moyen de hacher correctement les mots de passe à l'aide d'un algorithme solide et correctement configuré, soit ne pas les stocker.
Mais pour répondre directement à votre question: oui, quelque chose vaut mieux que rien. SHA-1 ou SHA-2 est certainement une amélioration par rapport au texte en clair.
Pour répondre à la question "alors où doivent aller les mots de passe?" question - Sur la base de la formulation, je suppose qu'il existe une nouvelle fonctionnalité/demande pour le logiciel qui nécessite que le système stocke les mots de passe.
Si le système ne peut pas stocker correctement et en toute sécurité les mots de passe (selon les normes de sécurité modernes), je rejetterais (personnellement) la demande. Pratiquer intentionnellement une sécurité médiocre en raison des contraintes du système existant ou pour apaiser un cas d'utilisation commerciale est une mauvaise pratique de sécurité. Je voudrais informer quiconque a fait la demande que j'ai deux options viables:
Nous devons complètement remanier le système pour en prendre un qui prend en charge les pratiques de sécurité modernes (telles que le hachage de mot de passe cryptographique approprié).
Je ne peux tout simplement pas ajouter la nouvelle fonctionnalité/demande au système existant car cela compromettrait la sécurité.
Oui, un hachage cryptographique faible est préférable à aucun hachage.
Les raisons du hachage de vos mots de passe sont, en cas de vol de votre mot de passe db:
- Empêchez l'attaquant d'obtenir trivialement les mots de passe en texte brut.
- Empêchez l'attaquant de savoir quels utilisateurs ont le même mot de passe (cela se fait en donnant à chaque utilisateur un sel unique.
1 est une course aux armements: vous voulez utiliser une fonction de hachage plus grande et plus lente afin que cela coûte plus cher à l'attaquant en électricité pour effectuer le craquage de hachage par force brute. Une seule itération de SHA-1/2 vaut mieux que pas de hachage car l'attaquant doit faire certains craquer. Une seule itération de salée SHA-1/2 les forcera à faire quelques craquements sans pouvoir utiliser des tables Rainbow pré-calculées. Passer aux hachages de mots de passe plus sophistiqués (argon2, bcrypt ou scrypt plus ancien, pbkdf2) avec un facteur de travail plus élevé augmentera encore plus les coûts d'électricité de la fissure.
L'utilisation de tout hachage cryptographique salé (même ceux non recommandés pour les mots de passe, comme SHA-1, SHA-2) donnera les avantages de 2.
À sa base, PBKDF2 est simplement SHA-1/2 itéré et salé, donc je ferais une recherche sur Google pour les implémentations de PBKDF2, et construirais votre wrapper autour de SHA-1/2 qui l'émule (ou mieux, allez jusqu'au bout et implémentez réellement PBKDF2).
Comme d'autres l'ont dit, essayez si possible de trouver une implémentation autonome forte dans le langage de votre plateforme.
Mais si vous ne pouvez pas utiliser un hachage fort ... alors vous devriez certainement hacher toujours les mots de passe de vos utilisateurs, même avec un hachage faible - parce que même un hachage faible protégera un fort mot de passe.
Lorsque des outils comme hashcat peuvent deviner des milliards de mots de passe par seconde , les hachages faibles ne protègent pas les mots de passe faibles. Mais si l'un de vos utilisateurs soucieux de la sécurité sélectionne un mot de passe non craquable comme `` SDXBZsRVBKVnXznpLTBMIKhTX '' ou `` imitere-snowmelt-heirdom-leeching '' ... alors même un hachage faible comme SHA1 mettra toujours ce mot de passe hors de portée d'une bruteforce attaque.
En utilisant même un hachage faible, vous pouvez au moins permettre à vos utilisateurs avertis de se protéger même si votre système est faible . (Et si vous avez la possibilité d'étirer - d'utiliser le même algorithme des milliers de fois d'affilée - cela ralentira également l'attaquant).
Mais vos utilisateurs avertis ne réutiliseront pas les mots de passe, donc même cela a une valeur limitée (sauf pour les utilisateurs "semi-avertis" qui ont choisi des mots de passe assez forts pour résister à la force brute, mais peuvent réutiliser ce mot de passe ailleurs ou utiliser un analyseur humain) schéma de sélection de mot de passe ... donc l'utilisation même d'un hachage faible protégera également ces utilisateurs).
Votre meilleure option pour tous les utilisateurs est de trouver un moyen d'utiliser un hachage fort.
[Edit: l'OP a mis à jour la question pour indiquer que ils sont le seul utilisateur du système, et peuvent définir un mot de passe arbitrairement aléatoire (ce qui me semble assez étrange; je ne connais pas de système avec une combinaison si étrange de "Je suis le seul utilisateur", "Je ne peux choisir que parmi quelques algorithmes de hachage" et "Tous les algorithmes de hachage sont faibles"). Quoi qu'il en soit, cela rend ma préoccupation concernant la protection des mots de passe faibles des utilisateurs généraux non pertinente pour cette question spécifique. D'autres réponses devraient préciser au début de leurs réponses qu'elles donnent des conseils qui seraient normalement assez mauvais, et ne s'appliquent qu'à cette question très spécifique.]
[Edit 2: Notez que "hachage faible" n'est pas la même chose que "mauvais hachage". Un exemple de mauvais hachage serait le décryptage (car il tronque les mots de passe à 8 caractères). Donc, même si votre mot de passe est fort, un hachage de décryptage à 8 caractères peut être brutalisé en 10 jours ou moins sur un système de craquage de niveau prosommateur (6 GPU).]
SHA-2 dans ce cas particulier est tout aussi sécurisé que PBKDF/scrypt/bcrypt. Les itérations sont inutiles et inutiles. Générez des mots de passe à haute entropie (256 bits) et oubliez les KDF et même les sels.
En fait, il est plus logique d'utiliser SHA-2 que PBKDF car il n'y a pas d'implémentation de plateforme existante de l'algorithme et "rouler votre propre crypto" est un non-non.
C'est une déclaration assez forte. L'essence ici dans la question est que l'OP a le contrôle total des mots de passe qu'il stocke sur le système et sait qu'il sera le seul à stocker les mots de passe sur le système.
Signal utilise une construction appelée HKDF dans son algorithme à double cliquet, qui applique essentiellement l'algorithme de hachage pour une seule itération.
Pourquoi est-ce correct?
Les KDF de mot de passe existent précisément pour une raison: les mots de passe à faible entropie. La plupart des gens ne se souviendront pas d'une clé de 128 ou 256 bits générée à partir d'un CSRNG dans leur tête. J'oserais que la plupart des gens se souviennent au plus d'une chaîne aléatoire de 40 bits pendant une période suffisamment longue pour l'utiliser.
Presque toutes les fonctions de hachage (même MD4, MD5 et SHA-1, mais puisque vous avez dit que vous avez SHA-2 sur la plate-forme, soyons en sécurité ici) ont une fonctionnalité appelée résistance de pré-image , qui est assez bon pour votre application puisque vous contrôlez tous les mots de passe stockés sur votre système. Cela signifie qu'il est impossible sur le plan informatique, étant donné un hachage, de générer quelque chose qui hache le même hachage.
Pour simplifier un peu, la façon la plus pratique de générer une pré-image pour l'une de ces fonctions de hachage est de continuer à essayer les entrées. Il y a quelques exemples d'attaques qui font légèrement mieux que la force brute, mais elles sont totalement irréalisables. Maintenant, si le mot de passe/la clé que vous avez choisi de mettre dans la fonction de hachage n'a que 16 bits d'entropie, cette propriété de résistance ne vous fera pas grand-chose, car l'attaquant pourra essayer toutes les 65536 entrées différentes que vous auriez pu mettre.
Pourquoi le contrôle du mot de passe est important
Pensez moins aux choses que vous mettez en tant que "mots de passe", mais plutôt en tant que clés cryptographiques. Tant que vous hachez des clés dont l'entropie est supérieure ou égale au nombre de bits émis par votre choix de fonction de hachage (pour SHA-256, c'est 256 bits), alors vous êtes tout à fait bien en exécutant une seule itération du hachage dessus pour empêcher l'extraction des clés. La résistance à la pré-image du hachage combinée à l'entropie élevée de votre clé signifie qu'un attaquant ne peut tout simplement pas deviner la valeur que vous y mettez. -des patrons si réceptifs. La résistance FPGA/ASIC est un point discutable lorsque vous devez deviner une entrée 256 bits dans la fonction de hachage.
Recommandations
Générez vos "mots de passe" avec un RNG matériel ou un CSPRNG et détruisez rapidement tout matériel de départ qui pourrait être utilisé pour récupérer tout état interne et donc les mots de passe. Assurez-vous que ceux-ci ont une longueur de 256 bits. Si votre système ne prend pas en charge les mots de passe non alphanumériques ou non ASCII, alors après vous générez les 256 bits, codez-le en base-64 ou base-26 ou binaire si vous le souhaitez. (Cela signifie que les mots de passe réels que vous soumettez dépasseront 32 octets, mais cela n'aide pas beaucoup l'entropie.)
Traitez ces mots de passe comme des clés cryptographiques - idéalement, ils seraient stockés sur des jetons matériels. Un gestionnaire de mots de passe matériel fonctionne très bien à cet effet. Stockez les hachages SHA-256 dans votre système et vérifiez les mots de passe en hachant et en comparant. Vous devez rejeter tous les mots de passe tentés qui ne correspondent pas à votre critère de génération (un exemple serait un mot de passe sélectionné par l'utilisateur <256 bits), même si les hachages correspondent, et vous ne devez permettre à personne de définir un mot de passe qui ne provienne pas d'un CSRNG. Cela devrait être documenté. Encore mieux si vous ajoutez un octet de somme de contrôle obscur à la fin des mots de passe que vous générez qui est vérifié par la plate-forme avant de vous permettre de définir le mot de passe. Cela devrait dissuader tout le monde, sauf les personnes les plus hilarantes et incompétentes, de mettre autre chose qu'une clé cryptographique sur votre plate-forme.
Cryptographie à clé publique
Votre cas d'utilisation est un peu étrange. La plupart des endroits conservent des mots de passe, car la configuration d'une infrastructure à clé publique et le traitement des utilisateurs finaux sont très difficiles, en particulier avec des choses comme les clés publiques. Puisque vous semblez être le seul à entrer des mots de passe dans le système, il serait peut-être plus logique de stocker les clés publiques Ed25519 ou ECDSA sur le système et d'y écrire du code qui implémente un protocole de défi-réponse (un simple est de signer ce 256- valeur de bit - mais attention à ne pas réutiliser ces clés, car quelqu'un pourrait vous inciter à vous déconnecter de votre Bitcoin ou à un aveu criminel). Le périphérique qui interfacerait ici avec votre système et maintiendrait les clés privées a probablement une implémentation forte de la cryptographie à clé publique et n'aurait aucun problème à s'authentifier. Votre implémentation "roll my own" de la vérification de signature pourrait être la moins sécurisée au monde en termes d'attaques latérales (pensez à mettre tout son état sur un panneau d'affichage ou la blockchain), tant qu'elle donne la bonne réponse, et vous iriez parfaitement bien, car l'algorithme de vérification n'a tout simplement pas accès aux clés privées.
Je suis d'accord avec Mike et Royce dans leurs réponses, et je ne ressens pas le besoin de répéter ce qu'ils ont bien couvert. Cependant, je voulais répondre plus directement à votre commentaire:
Informations supplémentaires: Je serai le seul à stocker des mots de passe sur ce système, je peux donc 1) garantir qu'aucun des mots de passe ne sera utilisé deux fois et 2) garantir que les mots de passe auront une entropie très élevée.
Cette information est à la fois importante et non importante. Voici pourquoi:
Le cas du hachage de mot de passe
Il est toujours important de se rappeler pourquoi nous hachons les mots de passe, et tout se résume à la réutilisation des mots de passe. La raison pour laquelle le hachage de mot de passe est si important est que lorsque votre système est compromis et que les mots de passe sont volés, ce n'est pas seulement l'accès à votre site qui est compromis, mais l'accès à tous les sites où vos utilisateurs ont réutilisé le même e-mail/mot de passe combinaison qui (comme nous le savons) se produit beaucoup. Le hachage de mot de passe consiste à protéger les utilisateurs d'eux-mêmes. Si absolument tout le monde utilisait des mots de passe forts et uniques sur chaque site, le hachage de mot de passe serait beaucoup moins nécessaire. Il aurait toujours une certaine valeur car il existe des cas d'utilisation où un pirate pourrait avoir un accès en lecture seule à un vidage de la base de données, donc les mots de passe hachés peuvent fournir une certaine protection contre les attaquants obtenant un accès réel à votre système. des mots de passe partout, puis le hachage de mots de passe deviendrait plus une préoccupation secondaire au lieu de la nécessité absolument critique qu'elle est aujourd'hui.
Donc, si vous pouvez garantir que chaque utilisateur de votre système n'utilisera que des mots de passe forts et uniques (c'est-à-dire des mots de passe qui n'ont pas été utilisés sur d'autres sites), alors je pense que même quelque chose de simple comme SHA2 serait en fait un choix parfaitement raisonnable, indépendamment de la disponibilité ou non de meilleures fonctions.
MAIS: évolution des besoins de l'entreprise
Cependant, je vous encourage à vérifier vos hypothèses (que les mots de passe uniques forts seront les seuls jamais dans votre système). J'ai vu les besoins des entreprises changer trop souvent dans le passé pour s'appuyer sur des hypothèses comme celle-ci dans des domaines commerciaux critiques (ce qui peut ne pas être le cas - évidemment, je ne sais pas ce que cela fait). Le problème est que les entreprises doivent changer. Peut-être que c'est juste moi, mais d'après mon expérience, des choses qui étaient censées être temporaires ou limitées à quelques personnes se transforment inévitablement en applications commerciales critiques utilisées par tout le monde dans l'entreprise, et tout d'un coup, vous avez un système de mot de passe faible protégeant les affaires critiques Infrastructure. Cela n'arrivera pas toujours parce que les gens essayent de couper les coins ronds, mais parce que 12 mois plus tard, vous oubliez que vous n'avez pas utilisé un bon hachage de mot de passe, ou vous partez et le gars suivant ne le fait pas '' t y regarder, ou vous êtes sous pression pour respecter un délai et vous oubliez, ou, ou, ou ...
D'après mon expérience, les entreprises finissent par avoir des failles de sécurité non pas parce que la sécurité est difficile mais parce qu'elles ne comprennent pas la nécessité de passer du temps (alias de l'argent) sur les bonnes pratiques de sécurité et de couper les coins où elles ne devraient pas. Bien sûr, à droite maintenant un excellent schéma de hachage de mot de passe n'a pas d'importance, mais pouvez-vous vraiment garantir que cela ne changera pas à l'avenir? Si vous n'avez pas le temps de mettre en place le hachage de mot de passe approprié maintenant, pouvez-vous garantir que lorsque les besoins changeront et que cela importera soudainement, vous aurez le temps de le faire tout de suite?
Bien sûr, à la fin de la journée, chaque entreprise doit gagner de l'argent, et parfois "Gardons cela simple pour l'instant pour en sortir" est une réponse parfaitement raisonnable. Soyez prudent cependant, car prendre cette décision trop souvent est de savoir comment les entreprises se retrouvent avec des systèmes remplis de failles de sécurité. En tant qu'entreprise, vous devez trouver cet équilibre par vous-même. Le problème est que lorsque les entreprises lésent de manière chronique sur la sécurité, ce sont finalement leurs clients qui souffrent le plus.
Je dois stocker les mots de passe sur un système qui n'offre aucun des algorithmes recommandés pour le hachage des mots de passe (par exemple bcrypt, scrypt ou PBKDF2). Serait-il préférable d'utiliser un algorithme inapproprié (par exemple la famille SHA-1 ou SHA-2) avant d'en utiliser aucun?
La réponse stricte à votre question est oui. La raison en est que les hachages rapides ne protégeront pas les mots de passe faibles, mais ils protégeront les mots de passe très forts, ce qui est strictement meilleur que le texte en clair.
Cependant, si vous avez SHA-1 ou SHA-2, il y a très peu (voire pas du tout!) D'excuses pour ne pas utiliser PBKDF2. Oui, le conseil commun est "ne roulez pas votre propre crypto", mais si vous avez SHA-1 ou SHA-2 c'est déjà le bloc de construction clé pour PBKDF2, et pour le cas de hachage de mot de passe écrit votre propre implémentation de PBKDF2 peut difficilement être pire qu'improbable . Voici la RFC et la section pertinentes:
Quand ils disent "fonction pseudo-aléatoire", vous devez utiliser une variante HMAC (idéalement HMAC-SHA-512, mais n'importe laquelle fera l'affaire). Votre bibliothèque a probablement déjà des implémentations HMAC, mais si ce n'est pas le cas, le hachage de mot de passe est à nouveau un cas où l'implémentation de la vôtre ne peut pas être pire qu'improbable.
Pour répondre à votre question: oui, utilisez le meilleur algorithme auquel vous avez accès. Si vous en avez plusieurs, vous pouvez les combiner (remarque: la concaténation de mots de passe, par exemple sha1 (mot de passe) + md5sum (mot de passe), est plus vulnérable à la devinette, car un attaquant pourrait choisir le hachage qu'il veut deviner, mais les collisions sont beaucoup moins car les deux mots de passe doivent correspondre. Utilisez un sel différent et aléatoire pour chaque mot de passe.
Vous dites que votre système "n'offre aucun des algorithmes recommandés pour le hachage des mots de passe". Je vous encourage à réexaminer cette hypothèse.
Presque tous les langages de programmation modernes ont des implémentations de hachages sécurisés. Vous n'avez pas nécessairement besoin qu'il soit implémenté dans une bibliothèque pré-faite et pré-installée - par exemple, si votre programme est écrit en C, vous devriez pouvoir trouver des implémentations de n'importe quel hachage en C, en tant que fonction autonome. Même les petits processeurs comme Arduino ont bcrypt et PBKDF2, prêts à l'emploi. Le travail supplémentaire impliqué est minime. Vous pouvez même l'implémenter vous-même (mais soyez très prudent et testez très soigneusement!).
Je ne doute pas qu'il y ait des exceptions, mais il n'y en a pas beaucoup.
Pour accompagner les excellentes réponses ci-dessus, je veux donner une réponse complémentaire mais contraire:
Non. Utiliser un hachage faible est pire que de ne pas utiliser du tout de hachage.
Un hachage faible vous donne l'illusion de sécurité.
Bien que vous et vos gestionnaires puissiez comprendre actuellement que le hachage n'offre aucune réelle sécurité, un gestionnaire ou un développeur en aval peut penser que le hachage est sécurisé. Ces personnes peuvent décider de stocker des informations supplémentaires en utilisant le hachage en question.
Il y a aussi le risque que la direction ne comprenne pas simplement que le hachage n'est pas sûr au départ. Lorsqu'ils sont confrontés à une décision d'investir dans le développement de la sécurité, ils peuvent décider que "le système actuel est suffisamment bon" car il est déjà haché et le hachage est considéré comme la meilleure pratique.
OUI, même un hachage de faible qualité est bien meilleur que de stocker des mots de passe en texte clair
Si je comprends que vous mettez à jour, quelqu'un d'autre fera l'authentification (sans rapport avec vous et votre base de données), et vous utiliserez votre base de données de hachage de mot de passe uniquement pour la détection de mot de passe en double? L'obligation de déterminer l'entropie du mot de passe serait basée sur du texte en clair et n'est pas liée au stockage des hachages de mot de passe, non?
Ensuite, vous pouvez stocker dans votre base de données de hachage juste une petite partie de sha2 hachage de salt + plaintext (par exemple, ne stockant que 8 octets bas sur 32 octets renvoyés par sha256), ce qui sera suffisant pour détecter les doublons sans faux positifs dans la vie réelle, mais toujours pas assez pour permettre à l'attaquant d'utiliser les tables Rainbow pour deviner le mot de passe d'origine en cas de vol de votre base de données.
(Avertissement: si vous effectuez une authentification et pas seulement une détection de mot de passe en double, la suppression d'une partie du hachage serait évidemment une idée terrible!)
Oui, utiliser un hachage faible vaut mieux que rien.
Je pense que vous devriez également considérer la voie administrative. Si vous gérez la base de données (mais n'êtes pas autorisé à modifier la structure, qui sait pourquoi ...), vous ne devriez pas voir les mots de passe en texte brut, même si vous êtes la personne la plus entière et que vous ne ferez aucun mal avec ces informations. Tout comme le proverbe: l'opportunité fait le voleur.
Oui, il est certainement préférable d'utiliser un hachage simple que rien (bien que vu comment vous apparemment implémentez le système, je ne vois pas ce qui vous empêche de faire les choses correctement).
Cependant, compte tenu de votre modification "Informations supplémentaires", on pourrait être assez audacieux pour dire que vous n'avez même pas besoin de sel! Cela ne signifie pas que c'est un bon design et je ne le recommanderais pas, mais si vous êtes sérieux au sujet de vos garanties, un simple hachage sécurisé de taille raisonnable suffit, à proprement parler.
Pourquoi fait-on autant d'histoires sur le stockage des mots de passe? Habituellement, les mots de passe sont à faible entropie, et même lorsqu'ils sont hachés, il y a une bonne chance de deviner un mot de passe, même plus que les fonctions de hachage sont très rapide, trivialement parallélisables, et il existe des tables Rainbow qui fournissent un raccourci bon marché . Donc, même être illisible après avoir été haché, cela ne signifie pas nécessairement que les mots de passe sont irrécupérables.
En principe, étant donné un temps infini, vous pouvez récupérer chaque mot de passe sur chaque système (ou au moins un mot de passe qui fonctionnera). C'est juste une conséquence du fait qu'il existe un nombre fini de sorties pour une fonction de hachage. Ainsi, dans une recherche quasi-exhaustive, certains séquence d'entrée doit nécessairement produire une sortie qui fonctionne.
Heureusement, les attaquants n'ont pas de temps infini, donc notre travail consiste à nous assurer qu'ils n'ont pas une chance raisonnable de trouver une séquence d'entrée qui fonctionne dans un temps fini et avec un approvisionnement fini en énergie.
Maintenant ... vous dites que vous êtes le seul utilisateur et vous pouvez garantir que les mots de passe sont entropiques aléatoires et élevés. Cela exclut la plupart des préoccupations concernant les suppositions.
Étant donné une taille de résumé "raisonnable", cela signifie que les chances de trouver le hachage dans une table Rainbow sont minimes (zéro, plus ou moins), et les chances de le trouver par force brute sont également plus ou moins nulles. Il n'y a aucun moyen que quelqu'un brise la force brute du condensé SHA-256, et encore moins SHA-512. Cette idée n'est tout simplement pas compatible avec notre compréhension du fonctionnement de la physique.
.
Maintenant, bien sûr, normalement un système devrait fonctionner de manière fiable même si vous ne pouvez pas fournir cette garantie (ou n'importe quelle garantie d'ailleurs). Ce n'est donc pas le meilleur design.
Ouais, ça devrait aller. SHA1 et 2 sont encore assez solides pour stocker des hachages de mot de passe à entropie élevée et fourniront une protection adéquate contre le forçage brut. SHA2 offre une meilleure protection que SHA1.Les vulnérabilités de SHA2 ne sont pas pertinentes pour ce scénario car elles concernent la création de collisions où le texte en clair initial est déjà connu.