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 le la sécurité de vos utilisateurs. Soit trouver un moyen de hacher correctement les mots de passe en utilisant un algorithme fort et correctement configuré, soit ne pas les stocker.

Mais pour apporter une réponse directe à votre question: oui, quelque chose vaut mieux que rien. SHA-1 ou SHA-2 est définitivement une amélioration par rapport au texte en clair.

Pour répondre à la question "alors où devraient 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 oblige le système à stocker 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 mauvaise sécurité en raison des contraintes du système hérité ou pour apaiser un cas d'utilisation métier est une mauvaise pratique de sécurité. J'informerais quiconque a fait la demande que j'ai deux options viables:

1. Nous devons complètement réviser le système pour en faire un qui prend en charge les pratiques de sécurité modernes (comme le hachage de mot de passe cryptographique approprié).

2. Je ne peux tout simplement pas ajouter la nouvelle fonctionnalité / requête au système existant car cela compromettrait la sécurité.

Oui, un hachage cryptographique faible vaut mieux que pas de hachage.

Les raisons de hacher vos mots de passe sont, en cas de vol de votre mot de passe db:

1. Empêchez l'attaquant d'obtenir trivialement les mots de passe en clair.
2. Empêchez l'attaquant de savoir quels utilisateurs ont le même mot de passe (ceci est accompli 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 pour que l'attaquant coûte plus cher en électricité pour effectuer le hachage par force brute. Une seule itération de SHA-1/2 vaut mieux que pas de hachage car l'attaquant doit faire quelques cracking. Une seule itération de salted SHA-1/2 le forcera à faire un cracking sans pouvoir utiliser de pré-calcul tables arc-en-ciel . Passer aux hachages de mots de passe plus sophistiqués (argon2, bcrypt ou l'ancien scrypt, pbkdf2) avec un facteur de travail plus élevé augmentera encore plus les coûts d'électricité de la fissure.

Utilisation tout cryptog salé Le hachage raphique (même ceux qui ne sont pas recommandés pour les mots de passe, comme SHA-1, SHA-2) donnera les avantages de 2.

Au fond, PBKDF2 est juste itéré et salé SHA-1 / 2, donc je ferais quelques recherches sur Google pour les implémentations de PBKDF2, et construirais votre wrapper autour de SHA-1/2 qui l'émule (ou mieux, aller jusqu'au bout et implémenter réellement PBKDF2).

Comme d'autres l'ont dit, essayez de trouver une implémentation autonome solide dans le langage de votre plate-forme si possible.

Mais si vous ne pouvez pas utiliser un hachage fort ... alors vous devriez certainement toujours hacher les mots de passe de vos utilisateurs, même avec un hachage faible - car même un hachage faible protégera un mot de passe fort .

Quand des outils comme hashcat peuvent deviner milliards de mots de passe par seconde , les hachages faibles ne protégeront pas les mots de passe faibles. Mais si l'un de vos utilisateurs soucieux de la sécurité sélectionne un mot de passe incassable comme 'SDXBZsRVBKVnXznpLTBMIKhTX' ou 'afféremment-imitatee-snowmelt-heirdom-leeching' ... alors même un hachage faible comme SHA1 mettra toujours ce mot de passe hors de portée d'une force brute 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é de étirer - d'utiliser le même algorithme des milliers de fois de suite - cela ralentira également l'attaquant.

Mais vos utilisateurs avertis ne réutilisera 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 suffisamment forts pour résister à la force brute, mais peuvent réutiliser ce mot de passe ailleurs ou utiliser un schéma de sélection de mot de passe analysable par l'homme. .. donc utiliser même un hachage faible protégera également ces utilisateurs).

La meilleure option pour tous les utilisateurs est de trouver un moyen d'utiliser un hachage fort.

[Modifier: l'OP a mis à jour la question pour indiquer qu'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 le fais pas Je connais un système avec une combinaison aussi é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 sans pertinence pour cette question spécifique. Les 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 "faible hachage" n'est pas la même chose que "bad hash". Un exemple d'un mauvais hachage serait descrypt (car il tronque les mots de passe à 8 caractères). Ainsi, même si votre mot de passe est fort, un hachage de 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 plate-forme 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 pour une raison précise: 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'ose croire que la plupart des gens peuvent se souvenir 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) ayez une fonctionnalité appelée résistance à la pré-image, ce qui est assez bon pour votre application puisque vous contrôlez tous les mots de passe qui sont 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 se hache sur le même hachage.

En simplifiant un peu, le moyen le plus pratique de générer une pré-image pour l'une de ces fonctions de hachage est de conserver essayer les entrées. Il existe 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 / 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 les 65536 entrées différentes que vous auriez pu insérer.

Pourquoi le contrôle du mot de passe est important

Pensez moins aux choses que vous mettez en tant que "mots de passe" mais plus en tant que clés cryptographiques. Tant que vous utilisez des clés de hachage qui ont une entropie supérieure ou égale au nombre de bits émis par votre choix de fonction de hachage (pour SHA-256, c'est 256 bits), alors tout va bien en exécutant simplement une itération du hachage dessus pour empêcher l'extraction de clé. 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 mettez. Il n'est pas nécessaire d'avoir des milliers d'itérations ou d'argumenter avec le côté commercial ou de raisonner sur une attaque abstraite pour ne pas -des patrons très réceptifs. La résistance FPGA / ASIC est un point discutable lorsque vous devez deviner une entrée de 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 qu'ils 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, encodez-les en base-64 ou base-26 ou binaire si vous le souhaitez. (Cela signifie que les mots de passe que vous soumettez seront plus longs que 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 du matériel jetons. 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 par hachage et comparaison. Vous devez rejeter toutes les tentatives de mots de passe 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 autoriser personne à définir un mot de passe qui ne provient pas d'un CSRNG. Ce 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 toutes les personnes incompétentes sauf les plus hilarantes de mettre autre chose qu'une clé cryptographique sur votre plate-forme.

Cryptographie à clé publique

Votre cas d'utilisation est un peu bizarre. La plupart des endroits conservent les mots de passe car la configuration d'une PKI et le traitement des utilisateurs finaux sont très difficiles, en particulier avec des éléments tels que les clés publiques. Puisque vous semblez être le seul à entrer des mots de passe dans le système, il serait peut-être plus judicieux de stocker des 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- Bitcoin - mais veillez à ne pas réutiliser ces clés, car quelqu'un pourrait vous inciter à signer votre Bitcoin ou une confession criminelle). L'appareil qui interagirait avec votre système ici et maintiendrait les clés privées a probablement une forte implémentation 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 side-channel (pensez à mettre tout son état sur un panneau d'affichage ou la blockchain), à condition qu'elle donne la bonne réponse, et tout irait 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 aborder plus directement votre commentaire:

Informations supplémentaires: je serai le seul à stocker les mots de passe sur ce système, donc je peux 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 des mots de passe

Il est toujours important de se rappeler pourquoi nous hachons les mots de passe, et tout bout jusqu'à la réutilisation du mot 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 à chaque site où vos utilisateurs ont réutilisé le même e-mail / mot de passe. combinaison qui (comme nous le savons) arrive souvent. 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. Cela aurait encore une certaine valeur car il existe des cas d'utilisation dans lesquels un pirate informatique peut obtenir un accès en lecture seule à un vidage de base de données, de sorte que les mots de passe hachés peuvent fournir une certaine protection contre les attaquants qui obtiennent un accès réel à votre système. mots de passe partout, alors le hachage des mots de passe deviendrait plus une préoccupation secondaire au lieu de la nécessité absolument critique qu'il est aujourd'hui.

Donc, si vous pouvez garantir que chaque utilisateur de votre système n'utilisera jamais 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, que de meilleures fonctions soient disponibles ou non.

MAIS: l'évolution des besoins de l'entreprise

Cependant, je vous encourage à revérifier vos hypothèses (que les mots de passe uniques et forts seront les seuls dans votre système). J'ai vu les besoins des entreprises changer souvent dans le passé pour s'appuyer sur des hypothèses comme celles-ci dans des domaines d'activité critiques (ce qui n'est peut-être pas 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, les 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 schéma de mot de passe faible protégeant les activités critiques. Infrastructure. Cela n'arrivera pas toujours parce que les gens essaient 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 prochain ne le fait pas. t examinez-le, ou vous êtes sous pression pour respecter une date limite 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'ils ne comprennent pas la nécessité de consacrer du temps (c'est-à-dire de l'argent) à de bonnes pratiques de sécurité et de réduire les coûts là où ils ne devraient pas. Bien sûr, maintenant un bon 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 un hachage de mot de passe correct maintenant, pouvez-vous garantir que lorsque les besoins changent et que cela compte soudainement, vous aurez le temps de le faire correctement?

Bien sûr, à la fin de la journée, chaque entreprise a besoin de gagner de l'argent, et parfois "Gardons cela simple pour le moment pour faire sortir cela" est une réponse parfaitement raisonnable. Attention cependant, car prendre cette décision trop souvent est la façon dont 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ésinent de façon chronique sur la sécurité, ce sont finalement leurs clients qui font le plus mal.

Je dois stocker des 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, et c'est strictement mieux que le texte brut.

Cependant, si vous avez SHA-1 ou SHA-2, il y en a sont très peu (voire aucune!) excuses pour ne pas utiliser PBKDF2. Oui, le conseil commun est "ne lancez 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 du hachage de mot de passe, l'écriture de votre propre implémentation de PBKDF2 peut difficilement être pire que pas . Voici la RFC et la section pertinentes:

• https://tools.ietf.org/html/rfc2898#section-5.2

Quand ils disent "fonction pseudo-aléatoire", vous devriez utiliser une variante HMAC (idéalement HMAC-SHA-512, mais n'importe laquelle d'entre elles 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 que non.

Pour répondre à votre question: oui, utilisez le meilleur algorithme auquel vous avez accès. Si vous en avez plusieurs, vous pouvez les combiner (note: 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 quel hachage il veut deviner, mais les collisions le sont beaucoup moins. probablement, car les deux mots de passe doivent correspondre. Utilisez un sel aléatoire et différent 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 le ferais vous encourageons à 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 de les implémenter dans une bibliothèque prédéfinie et préinstallée - par exemple, si votre programme est écrit en C, vous devriez être en mesure de 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, disponibles dans le commerce. Le travail supplémentaire impliqué est minime. Vous pourrait 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.

OUI, même un hachage de faible qualité est bien meilleur que le stockage des mots de passe en texte clair

Si je comprends bien que vous mettez à jour, quelqu'un d'autre effectuera 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 brut, et n'a aucun rapport avec le stockage des hachages de mot de passe, n'est-ce pas?

Ensuite, vous pouvez stocker dans votre base de données de hachage une petite partie du calculé sha2 hash of salt + clairxt (par exemple, ne stockant que 8 octets bas de 32 octets retournés par sha256), ce qui sera suffisant pour détecter les doublons avec pas de faux positifs dans la vraie vie, mais toujours pas assez pour permettre à l'attaquant d'utiliser des tables arc-en-ciel pour deviner le mot de passe d'origine au cas où votre base de données serait volée.

(Clause de non-responsabilité: si vous faites une authentification et non seulement une détection de mot de passe en double, laisser tomber une partie du hachage serait évidemment une mauvaise idée!)

Oui , il vaut mieux utiliser un hachage faible que rien.

Je pense que vous devriez également envisager la méthode administrative. Si vous maintenez la base de données (mais n'êtes pas autorisé à changer 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 ne nuiriez pas à ces informations. Tout comme le proverbe: l'opportunité fait le voleur.

Oui, il est définitivement préférable d'utiliser un simple hachage que rien (bien que voyant comment vous implémentez apparemment le système, je ne vois pas ce qui vous empêche de faire les choses correctement).

Cependant, compte tenu de votre édition "Informations complémentaires", on pourrait être assez audacieux pour dire que vous n'avez même pas besoin de sel! Cela ne veut pas dire 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 une telle histoire sur le stockage des mots de passe en premier lieu? Habituellement, les mots de passe ont une faible entropie, et même lorsqu'ils sont hachés, il y a de bonnes chances de deviner un mot de passe, même plus car les fonctions de hachage sont très rapides , trivialement parallélisables, et il existe des tables arc-en-ciel 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 vers une fonction de hachage. Ainsi, dans une recherche quasi-exhaustive, certaines séquences d’entrées doivent nécessairement produire une sortie qui fonctionne.
Heureusement, les attaquants n’ont pas un temps infini, donc notre travail est de s’assurer qu’ils une chance raisonnable de trouver une séquence d'entrée qui fonctionne dans un temps fini, et avec un approvisionnement limité en énergie.

Maintenant ... vous dites que vous êtes le seul utilisateur et vous pouvez garantir que les mots de passe sont aléatoires et à haute entropie. Cela élimine la plupart des problèmes de devinettes.

Étant donné une taille de résumé "raisonnable", cela signifie que la chance de trouver le hachage dans une table arc-en-ciel est minime (zéro, plus ou moins), et la chance de le trouver par force brute est également plus ou moins nulle. Il n'y a aucun moyen que quelqu'un brise la force brute de digestion 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.
Si le résumé est suffisamment volumineux et que les mots de passe sont garantis (comme vous le dites) pour être uniques, aléatoires, à forte entropie ... alors vous êtes en fait juste bien pour utiliser le hachage une fois.

Maintenant bien sûr, normalement un système devrait fonctionner de manière fiable même si vous ne pouvez fournir cette garantie (ou aucune garantie d'ailleurs). Ce n'est donc pas le meilleur design.

Ouais, ça devrait aller. SHA1 et 2 sont toujours assez puissants pour stocker des hachages de mots de passe à entropie élevée et fourniront une protection adéquate contre le forçage brutal. 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 brut initial est déjà connu.

Pour aller avec 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 de hachage du tout.

Un hachage faible vous donne l'illusion de la sécurité.

Pendant que vous et vos gestionnaires peut comprendre actuellement que le hachage n'offre aucune sécurité réelle, 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écurisé au départ. Lorsqu'ils sont confrontés à la décision d'investir dans le développement de la sécurité, ils peuvent décider que "le système actuel est assez bon" car il est déjà haché et le hachage est considéré comme la meilleure pratique.