Question:
Combien de tours de hachage suffisent pour un gestionnaire de mots de passe?
CertifcateJunky
2018-06-28 18:39:02 UTC
view on stackexchange narkive permalink

J'écris actuellement mon propre petit gestionnaire de mots de passe qui stocke la clé dans un hachage SHA256 , avec du sel. Je crée le hachage en procédant comme suit:

  def sha256_rounds (raw, rounds = 100001): obj = hashlib.sha256 () for _ in xrange (rounds): obj.update (raw) raw = obj.digest () return obj.digest ()  

Après sa création, il est stocké avec ce qui suit:

  key = base64.urlsafe_b64encode (clé_fournie) length = len (clé) avec open (key_file, "a +") as key_: front_salt, back_salt = os.urandom (16), os.urandom (16) key_.write ("{} {} {}: {} ". format (front_salt, key, back_salt, length))  

Les questions / préoccupations que j'ai sont les suivantes:

  • Est-ce une manière acceptable de stocker une clé hachée?
  • Dois-je utiliser plus d'itérations?
  • Ma technique de salage est-elle suffisante? Ou devrais-je utiliser une technique de salage différente?

Si ce n'est pas une solution acceptable pour stocker un mot de passe / clé haché, quelles autres mesures puis-je prendre pour le rendre plus sécurisé?


MISE À JOUR:

J'ai suivi beaucoup de conseils de votre gars, et si vous souhaitez voir le résultat, jusqu'à présent , de mon petit gestionnaire de mots de passe vous pouvez le trouver ici. Les conseils de tous sont très appréciés et je continuerai de m'efforcer de rendre cela aussi excellent que possible. (si ce lien ne fonctionne pas, utilisez celui-ci https://github.com/Ekultek/letmein)

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (https://chat.stackexchange.com/rooms/79597/discussion-on-question-by-certifcatejunky-how-many-rounds-of-hashing-is-enough-f).
Cinq réponses:
AndrolGenhald
2018-06-28 19:38:34 UTC
view on stackexchange narkive permalink

J'écris actuellement mon propre petit gestionnaire de mots de passe

C'est votre première erreur. Quelque chose de ce complexe comporte de nombreux pièges subtils dans lesquels même les experts tombent parfois, sans beaucoup d'expérience dans ce domaine, vous n'avez aucune chance de faire quelque chose de même proche de la sécurité.

stocke la clé dans un SHA256 hash

Oh oh ...

Cela n'indique pas nécessairement que vous faites quelque chose de mal, mais j'ai de sérieux doutes que vous allez le faire correctement. Je suppose que vous parlez d'un mot de passe principal haché ici? Le mot de passe principal doit être transformé en une clé à l'aide d'un KDF comme PBKDF2, bcrypt ou Argon2, alors cette clé est utilisée pour crypter les mots de passe stockés.

Si vous voulez avoir un moyen de vérifier que le mot de passe est correct, stocker un hachage de la clé devrait convenir, mais vous NE DEVEZ PAS stocker la clé elle-même ... si vous stockez la clé toute personne ayant accès à votre stockage a tout ce dont ils ont besoin pour déchiffrer tous les mots de passe!

Si vous ne parlez pas de hachage d'un mot de passe principal et que vous parlez d'une clé réellement générée aléatoirement, je n'ai aucune idée de ce que vous essayez d'accomplir ici , mais vous ne devriez pas utiliser un KDF lent avec un grand nombre d'itérations.

Sinon, vous pouvez hacher le mot de passe principal deux fois, une fois pour le stocker sous forme de hachage pour vérifier plus tard que le mot de passe saisi par l'utilisateur est correct, et encore une fois à utiliser comme clé pour le cryptage. Selon la façon dont cela est fait, cela peut aller d'un défaut de conception à la divulgation complète de la clé.

Modifier: Après avoir vu le code complet, cela semble être une quatrième option: vous stockez un hachage du mot de passe pour vérifiez plus tard si le mot de passe entré est correct, puis vous hachez ce hachage pour l'utiliser comme clé, ce qui est presque aussi mauvais que de simplement stocker la clé elle-même.

I créez le hachage en procédant comme suit:

  def sha256_rounds (raw, rounds = 100001): obj = hashlib.sha256 () for _ in xrange (rounds):
obj.update (raw) raw = obj.digest () return obj.digest ()  

Ce n'est pas vraiment clair ce que raw est ici, mais je suppose que c'est le mot de passe. Ce que vous faites est un hachage non salé utilisant SHA256. N'essayez pas de créer votre propre KDF!

Après sa création, il est stocké avec ce qui suit:

  key = base64.urlsafe_b64encode (provided_key) length = len (key) avec open (key_file, "a +") as key_: front_salt, back_salt = os.urandom (16), os.urandom (16) key_.write ("{} {} {}: {}". format (front_salt, key, back_salt, length))  

Donc, vous créez la clé en hachant le mot de passe, puis en ajoutant un sel à l'avant et à l'arrière? Non seulement la concaténation de 2 sels différents à l'avant et à l'arrière n'est pas standard, mais cela n'accomplit rien ici car c'est fait après que le KDF a déjà terminé! Vous ajoutez simplement des valeurs aléatoires pour les avoir là-bas.


Pour montrer à quel point c'est mauvais (à partir du commit 609fdb5ce976c7e5aa1832670505da60012b73bc), il suffit de vider tous les mots de passe stockés em> sans exiger aucun mot de passe principal est la suivante:

  de encryption.aes_encryption import AESCipherfrom lib.settings import store_key, MAIN_DIR, DATABASE_FILE, display_formatted_list_outputfrom sql.sql import create_connection, select_all_dataconn, curseur = create_connection (DATABASE_FILE) display_formatted_list_output (select_all_data (curseur, "encrypted_data"), store_key (MAIN_DIR))  

Même si cela peut être une bonne expérience d'apprentissage d'essayer de créer un gestionnaire de mots de passe, s'il vous plaît please Contents ne l'utilisez jamais pour quelque chose d'important à distance. Comme le suggère @Xenos, il ne semble pas que vous ayez suffisamment d'expérience pour que la création de votre propre gestionnaire de mots de passe soit vraiment bénéfique de toute façon, ce serait probablement une meilleure opportunité d'apprentissage de jeter un œil à un gestionnaire de mots de passe open source existant.

Je ne suis même pas sûr que «créer votre propre gestionnaire de mots de passe» soit une bonne expérience.Je pense que plonger dans un existant et regarder comment ils fonctionnent et comment ils sont codés est une expérience beaucoup plus intéressante et efficace, car vous ne ferez pas d'erreurs (en essayant de faire votre propre PM, vous ferez des erreurs et à moins quequelqu'un relit votre code, vous continuerez à faire et à croire en ces erreurs)
Il ne sera pas utilisé pour quelque chose d'important, je le crée simplement pour apprendre, je ne stocke que la valeur de hachage des mots de passe principaux, pas le mot de passe lui-même
Par rapport aux gestionnaires de mots de passe tiers à source fermée, la création de votre propre gestionnaire de mots de passe, tant que vous utilisez les fonctions de cryptage de mot de passe d'autres personnes pour le mot de passe stocké et la fonction de hachage pour le mot de passe principal, est, à mon avis, beaucoup plus sécurisé et paranoïaqueoption que de croire aveuglément que quelqu'un d'autre sera en sécurité, ne disposera pas de backends du gouvernement et ne vendra pas les mots de passe sur le marché noir.De toute évidence, cette logique ne vaut pas pour les logiciels tiers open source.
@kloddant donc la sécurité par l'obscurité?Premièrement, les gestionnaires de mots de passe hors ligne n'ont guère de «backends gouvernementaux» ou vendent vos mots de passe sur le marché noir.Si vous êtes infecté par n'importe quel type de malware, il peut être en mesure de faire la distinction entre un gestionnaire de mots de passe connu et sécurisé (et de lever la main) et une version DIY, qui peut être plus facilement attaquée.De plus, le gestionnaire de mots de passe d'OP est maintenant open source (et le supprimer maintenant n'aide pas) et probablement moins sécurisé que la plupart des gestionnaires de mots de passe open source.
@kloddant Bien que je sympathise avec l'idée d'utiliser un logiciel FOSS, être FOSS ne le rend pas en soi plus sûr.Je ne recommanderais pas de créer le vôtre à moins que vous ne soyez un expert en sécurité (et peut-être même pas dans ce cas).Il y a un avantage à avoir un audit professionnel;pas simplement plus d'yeux sur le code, mais surtout des yeux plus expérimentés sur le code.
@CertifcateJunky: Pour ce que ça vaut, se tromper de crypto n'est un problème que si vous définissez votre propre format de fichier.Il est un peu difficile de gâcher la crypto (KDF, etc.) si vous travaillez sur des formats de base de données de mots de passe existants (comme le KDBX de KeePass) ... il ne faut pas un spécialiste des fusées (cryptographe?) Pour comparer le XML d'origine et votrenouveau XML et vérifiez que votre code n'ajoute / ne supprime pas les informations superflues.Donc, si vous essayez simplement d'améliorer l'interface utilisateur et d'apprendre comment cela fonctionne, cela peut valoir la peine de vous en tenir à un format de fichier existant.En prime, vous bénéficiez également de l'interopérabilité.
@Mehrdad Ce n'est pas vrai à 100%, car vous pourriez toujours utiliser un mauvais PRNG au lieu d'un bon CSPRNG pour la génération salt ou iv, permettre l'échange de secrets en mémoire, etc.Un bon point néanmoins.
@AndrolGenhald: Je suppose ... mais si vous en savez suffisamment pour utiliser une fonction de hachage sécurisée, il est difficile de ne pas en savoir assez pour utiliser un RNG sécurisé.Bien que je convienne que des choses comme la prévention des attaques par canal secondaire et le renforcement contre diverses attaques d'autres programmes (y compris JS) sont * beaucoup * plus difficiles, donc je ne recommanderais pas de diffuser le gestionnaire de mots de passe à d'autres à moins que vous ne sachiez vraiment ce que vous êtesfaire (au cas où quelqu'un trouverait un trou) ... mais oui pour un usage personnel, je lui donnerais un laissez-passer.(Ouais, je suppose que c'est la sécurité par l'obscurité. Désolé ...)
Je ne plaidais pas pour la sécurité par l'obscurité;Je disais qu'écrire votre propre logiciel de gestion de mots de passe, pas les fonctions cryptographiques elles-mêmes, juste le logiciel qui les utilise, est mieux que de faire confiance au logiciel de quelqu'un d'autre.
@kloddant Le problème est que vous pouvez toujours faire beaucoup de choses mal en utilisant de bonnes implémentations de fonctions cryptographiques (comme le montre la question).
@AndrolGenhald Je ne pense pas que kloddant le nie.Il dit que le risque particulier doit être équilibré par le risque que vous prenez en faisant confiance au logiciel source fermée d'un tiers (et avouons-le, les fuites de Snowden ont montré que ce risque est très réel).
@AndrolGenhald Si vous voulez le voir et comment cela fonctionne, _so_far_, j'ai ajouté un lien vers le dépôt git à la fin de ma question.Merci pour votre conseil!
Allez les gars, c'est un gestionnaire de mots de passe privé.Il génère des mots de passe qui remplacent les `tr0ub4dor`s des autres.Dans son but, vous pourriez aussi bien utiliser quelques tours de RANDU comme «fonction de hachage» et le Dow Jones actuel comme «sel» ... - Bien sûr, si quelqu'un a accès à la base de données, vous 're vissé alors, mais j'ose dire si vous considérez que ce risque est important alors vous avez vos priorités erronées.Éviter tout logiciel à source fermée sur votre machine est un geste beaucoup plus sensé.(Ce qui ne veut pas dire que vous ne devriez pas utiliser à la place un gestionnaire open source éprouvé.)
@leftaroundabout Pour moi, le problème n'est pas que ce n'est pas sûr si quelqu'un y accède;si vous souhaitez stocker vos mots de passe dans une feuille de calcul non chiffrée qui pourrait être acceptable en fonction de ce que vous considérez comme une menace.Le problème est qu'il essaie de crypter les mots de passe afin de les protéger, et cela échoue.
Vrai.Et comme vous l'avez dit, la mise en œuvre du PO n'a en effet que très peu de sens.Je faisais juste objection à votre déclaration initiale selon laquelle écrire son propre gestionnaire de mots de passe est une erreur.Ce n'est peut-être pas utile en soi de faire cela, mais cela ne peut pas vraiment nuire non plus de s'en servir pour soi-même (à moins, en effet, de l'utiliser pour des choses importantes et de laisser tomber d'autres couches de sécurité, ce qui serait une idée horrible).Et il _peut_ être assez instructif.
@leftaroundabout Je suppose que cela dépend de la façon dont vous interprétez "beaucoup d'expérience".Par rapport à l'expérience de l'OP, je pensais que «beaucoup d'expérience» signifiait que vous pouvez au moins obtenir le bon cryptage et ne pas avoir d'autres vulnérabilités ou erreurs évidentes.De cette façon, vous devriez être généralement d'accord si votre base de données cryptée fuit, mais vous ne voudrez probablement pas recommander à quiconque de l'utiliser.Les menaces que _vous_ considérez comme importantes ne sont pas nécessairement les mêmes que les menaces que _tout le monde_ considère comme importantes, et un gestionnaire de mots de passe général doit se protéger contre toutes les menaces qu'il peut.
Jeffrey Goldberg
2018-06-30 01:57:26 UTC
view on stackexchange narkive permalink

Tout d'abord, permettez-moi de vous révéler que je travaille pour 1Password, un gestionnaire de mots de passe, et bien que cela puisse sembler intéressé, je dois ajouter ma voix à ceux qui vous disent que l'écriture d'un gestionnaire de mots de passe sécurisé est plus difficile qu'il n'y paraît. D'un autre côté, il est bon que vous essayiez et posiez des questions à ce sujet en public. C'est un bon moyen d'apprendre que c'est plus difficile qu'il n'y paraît.

Ne vous authentifiez pas. Chiffrez plutôt

J'ai jeté un coup d'œil rapide à la source vers laquelle vous créez un lien dans votre mise à jour, et je suis ravi de constater que vous avez suivi certains conseils qui vous ont été proposés. loin. Mais à moins que j'aie mal interprété votre code, vous rencontrez toujours une erreur de conception fondamentale qui le rend extrêmement peu sûr .

Vous semblez traiter l'entrée du mot de passe principal comme une authentification question au lieu d'une dérivation de clé de chiffrement. Autrement dit, vous vérifiez le mot de passe entré (après le hachage) avec quelque chose qui est stocké, et si cette vérification réussit, vous utilisez cette clé stockée pour déchiffrer les données.

Ce que vous devriez faire est de stocker un clé de chiffrement chiffrée. Appelons cela la clé principale. Cela doit être généré de manière aléatoire lorsque vous configurez une nouvelle instance pour la première fois. Cette clé principale est ce que vous utilisez pour chiffrer et déchiffrer les données réelles.

La clé principale n'est jamais stockée non chiffrée. Il doit être chiffré avec ce qu'on appelle parfois une clé de chiffrement de clé (KEK). Cette KEK est dérivée via votre fonction de dérivation de clé (KDF) du mot de passe principal de l'utilisateur et d'un sel.

Ainsi, la sortie de votre utilisation de PBKDF2 (merci de l'utiliser au lieu d'un simple hachage répété) sera votre KEK, et vous utilisez la KEK pour déchiffrer la clé principale, puis vous utilisez la clé principale déchiffrée pour déchiffrer vos données.

Maintenant, c'est peut-être ce que vous faites et j'ai mal lu votre code. Mais si vous comparez simplement ce que vous dérivez via votre KDF à quelque chose de stocké et que vous décidez ensuite de déchiffrer, alors votre système est massivement et terriblement insécurisé.

Veuillez faire la première ligne la plus audacieuse du projet README crie le fait qu'il est extrêmement peu sûr. Et ajoutez cela à chaque fichier source également.

Quelques autres points

Voici quelques autres choses que j'ai remarquées en jetant un coup d'œil à la source

  • Utilisez un mode de chiffrement authentifié tel que GCM au lieu de CBC.

  • Votre approche consistant à chiffrer le tout fonctionnera pour de petites quantités de données, mais elle a gagné ne vous mettez pas à l'échelle une fois que vous avez des ensembles de données plus volumineux.

    Quand vient le temps de crypter (des parties de) enregistrements séparément, gardez à l'esprit que vous aurez besoin d'un nonce unique (pour GCM) ou de vecteurs d'initialisation uniques (si vous vous en tenez imprudemment à CBC) pour chaque enregistrement.

  • La destruction de vos données après 3 échecs est dangereuse et n'ajoute aucune sécurité.

    Un attaquant sophistiqué va simplement copier votre fichier de données et écrivez leur propre script pour essayer de déchiffrer le mot de passe. Ils feront également leur propre copie des données capturées. La destruction de vos données permet uniquement à quelqu'un de détruire vos données par accident ou par malveillance.

Combien de tours de PBKDF2

Donc à votre question initiale. La réponse est que cela dépend. D'un côté, cela dépend de la force du mot de passe principal et des types de ressources qu'un attaquant mettra au problème. Et cela dépend aussi des ressources que le défenseur peut y mettre. Par exemple, utiliserez-vous votre KDF sur un appareil mobile dont la capacité de la batterie est limitée?

Mais en l'occurrence, chez 1Password, nous essayons d'évaluer le coût du cracking en offrant des prix aux personnes ou aux groupes qui déchiffrent un mot de passe de 42,5 bits haché avec 100 000 tours de PBKDF2-HMAC-SHA256.

Diminution des gains grâce au hachage lent

Mais ce qui est plus important que de comprendre comment peser tout cela, c'est de comprendre que le hachage lent, bien qu'absolument essentiel pour un gestionnaire de mots de passe KDF, produit des gains marginaux décroissants une fois qu'il est réglé suffisamment haut .

Supposons que vous utilisiez des tours de 100K et que vous ayez un mot de passe principal, P . Si vous choisissez un chiffre aléatoire, de 0 à 9 et l'ajoutez à P , vous obtiendrez une résistance à la fissuration dix fois supérieure. Pour obtenir la même augmentation en augmentant les tours de PBKDF2, vous auriez besoin d'aller jusqu'à 1 million de tours. Le fait est qu'une fois que vous avez une quantité décente de hachage lent, vous obtenez beaucoup plus de force pour l'effort du défenseur en augmentant la force du mot de passe que si vous augmentez le nombre de tours.

J'ai écrit à ce sujet il y a quelques années, Bcrypt est génial, mais le craquage de mots de passe est-il impossible?

Ce n'est certainement pas facile.Dans le README, il vous dit de ne pas l'utiliser, je peux ajouter quelque chose indiquant qu'il n'est pas sécurisé et un travail en cours au sommet cependant.De plus, vous n'avez pas mal lu le code, ce que je fais est de hacher la clé et de comparer avec ce hachage stocké.Je vois maintenant que ce n'est probablement pas la meilleure solution.Merci pour votre réponse.
@CertifcateJunky: Considérez toujours ce que quelqu'un pourrait faire en changeant votre code source et en le recompilant.Cela montre clairement pourquoi vous ne pouvez pas simplement vérifier le mot de passe entré, puis autoriser l'utilisation d'une clé qui était déjà stockée sur le disque: modifiez le code pour contourner cette vérification et vous avez toujours une clé de déchiffrement fonctionnelle, si les bits de clé ne sont past en fait * dépend * du mot de passe de déverrouillage.C'est la différence entre simplement authentifier l'utilisateur et exiger qu'il fournisse réellement un secret qui se transforme en clé.Si votre code fonctionne comme ça, il va bien au-delà de "probablement pas la meilleure solution".
KEK ... ça m'a fait rire.
@PeterCordes J'y travaille davantage et j'ai eu l'idée (principalement grâce aux conseils de tous) de conserver le mot de passe principal, mais de l'utiliser uniquement comme vérification (pour l'instant) et de générer une "clé" à partir de ce mot de passe aveccaractères aléatoires et que non.La clé n'est déchiffrée et utilisée que si le hachage du mot de passe principal correspond au hachage stocké, et la clé n'est jamais stockée déchiffrée (sauf si vous comptez la mémoire qui est un tout autre jeu de balle).Cette «clé» est utilisée pour crypter les mots de passe au lieu du mot de passe principal.
@CertifcateJunky: Oui, transformer le mot de passe principal en clé de déchiffrement pour la clé principale est le bon type d'idée.Cette réponse suggère quelques * bonnes * façons de transformer les mots de passe en clés.
@PeterCordes Je cherche également à surveiller les changements de fichiers comme une autre précaution.
crovers
2018-06-28 19:43:35 UTC
view on stackexchange narkive permalink

N'utilisez pas le SHA256 brut - il peut être accéléré à l'aide de GPU et donc sujet à la force brute. Ce n'est pas du tout cassé, ce n'est tout simplement plus la meilleure pratique. PBKDF2 fonctionne pour contrer cela dans une certaine mesure, mais vous devriez utiliser bcrypt ou scrypt de préférence.

Réinventer la roue (ce qui est à peu près ce que vous faites si vous n'utilisez pas PBKDF2-SHA256, bcrypt ou scrypt) n'est jamais une bonne idée en crypto.

@Azxdreuwa Les ASIC pour scrypt (utilisé pour litecoin) sont possibles car des paramètres faibles ont été choisis.Le vrai problème avec scrypt est qu'il met à l'échelle la mémoire et l'utilisation du processeur ensemble, et il a été conçu pour un contexte de chiffrement de disque où le paramètre peut être plus élevé.Dans un contexte Web où vous avez besoin d'un coût inférieur, il est facile de se retrouver moins sécurisé que bcrypt, même s'il reste, espérons-le, résistant aux ASIC.Argon2 a heureusement des paramètres séparés pour le coût du processeur et de la mémoire.
Au cas où cela ne serait pas évident d'après mon commentaire précédent, ces ASIC ne pourraient pas être utilisés pour les paramètres de scrypt autres que ceux choisis pour le litecoin (qui sont particulièrement mauvais).
ilkkachu
2018-06-29 19:38:41 UTC
view on stackexchange narkive permalink

En regardant le code dans le lien que vous avez posté (reproduit ci-dessous, en partie), je suis un peu confus.

Si je l'ai lu correctement, main () appelle store_key () pour charger une clé à partir d'un fichier sur le disque, puis utilise compare () pour comparer une clé donnée par l'utilisateur avec celle-ci. Les deux passent par sha256_rounds () qui exécute PBKDF2 sur eux.

Ensuite, vous utilisez le même stored_key , celui chargé à partir du fichier, faire du chiffrement?

C'est complètement et complètement à l'envers. Toute personne ayant accès au fichier de clé peut simplement charger la clé stockée et l'utiliser pour décrypter les données stockées, ou stocker de nouvelles données cryptées sous la même clé, sans avoir à passer par le script pour " vérifiez "le mot de passe.

Au mieux, je pense que vous confondez l'utilisation du mot de passe / phrase de passe donné par l'utilisateur pour produire une clé de chiffrement , et l'authentification de l'utilisateur contre un hash du mot de passe stocké . Vous ne pouvez pas faire les deux avec le même hachage, le chiffrement est totalement inutile si vous avez stocké la clé de chiffrement avec les données chiffrées.

Bien sûr, les mots de passe sont traités avec une sorte de hachage / KDF à la fois lorsqu'il est utilisé pour l'authentification et lorsqu'il est utilisé pour produire une clé de chiffrement. Mais cela ressemble plus à une étape de prétraitement nécessaire simplement parce que les humains ne peuvent pas mémoriser les clés de 256 bits et que nous devons nous fier à des mots de passe à faible entropie. Ce que vous faites avec le hachage / clé que vous avez diffère entre les deux cas d'utilisation.


Ensuite, il y a la chose que vous avez un sel codé en dur dans sha256_rounds () , ce qui va à l'encontre de l'objectif d'un sel en général. Je pourrais aussi commenter le code plus généralement, mais ce n'est pas codereview.SE.

S'il vous plaît dites-moi que j'ai mal lu le code.


Les parties du code J'ai regardé:

  def main (): stored_key = store_key (MAIN_DIR) sinon comparer (stored_key): ... else: ... # later
password = prompt ("entrez le mot de passe à stocker:", hide = True) encrypted_password = AESCipher (stocké_key) .encrypt (password) def store_key (chemin): key_file = "{} /. key" .format (chemin) sinon os.path.exists (key_file): ... else: retval = open (key_file) .read () amount = retval.split (":") [- 1] édité = retval [16:] édité = édité [: int (montant)] retour modifié  
non, ça résume ça.Je n'ai pas dit que c'était sécurisé, juste que j'en faisais un: P, je vois votre point cependant.
-1
Je pense que vous comprenez mal ce que j'ai dit et que vous ne le prenez pas comme je le pensais.Je comprends parfaitement ce que vous dites et j'essaie en fait de trouver un moyen de le modifier.C'était une blague, pas une déclaration sérieuse.
Bufke
2018-06-29 19:05:50 UTC
view on stackexchange narkive permalink

Utilisez un outil mis à jour qui décidera pour vous et augmentera le nombre par défaut ou même l'algorithme au fil du temps. Je suggérerais libsodium, mais il y en a d'autres. Libsodium a des valeurs par défaut pour le hachage de mot de passe "interactif" et pour le chiffrement symétrique. Assurez-vous que votre logiciel peut un jour «mettre à jour» les paramètres selon vos besoins. Un outil comme libsodium changera ses valeurs par défaut de temps en temps pour que vous puissiez les suivre.

Je fais du développement pour un gestionnaire de mots de passe open source et j'utilise libsodium. J'ai également trouvé le document de sécurité de Mitro intéressant à lire.

Le but de l'outil est d'apprendre comment fonctionne le hachage et comment fonctionnent les gestionnaires de mots de passe.Je ne suggère à personne d'utiliser cet outil, parce que bien, _Je l'ai écrit_ (lol).Mais je pense que c'est une bonne pratique pour déterminer comment les choses fonctionnent.Si vous êtes intéressé, vous pouvez le voir [ici] (https://github.com/Ekultek/letmein)
Bien sûr - je comprends totalement cela.Allez l'écrire, faites des erreurs et apprenez!Je suggérerais toujours de regarder d'autres logiciels comme libsodium pour savoir ce qu'ils utilisent.En règle générale, un gestionnaire de mots de passe traite du problème de stockage des mots de passe et de présentation d'une interface utilisateur.Presque tous utiliseront d'autres bibliothèques de logiciels pour effectuer le cryptage proprement dit.Séparation des préoccupations.Merci pour le lien!Je vois que vous utilisez python - vous pourriez être intéressé par ce https://www.crypto101.io/ qui utilise Python dans des exemples.
Je vais la regarder.Je suis curieux de savoir comment ils maintiennent leur cryptage aux normes.Merci pour le lien!


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...