Comment mettre en œuvre protection par mot de passe pour les fichiers individuels?

Question

Je suis en train d'écrire une petite application de bureau qui devrait être en mesure de chiffrer un fichier de données et les protéger avec un mot de passe (c'est à direon doit entrer le bon mot de passe pour déchiffrer).Je veux que les données chiffrées fichier à être autonome et portable, de sorte que l'authentification doit être incorporées dans le fichier (ou alors, je suppose).

J'ai une stratégie qui semble fonctionner et qui semble logique en fonction de ce que je sais (ce qui est probablement juste assez pour être dangereux), mais je n'ai aucune idée si c'est vraiment un bon design ou pas.Alors, dites-moi:est-ce un fou?Est-il mieux/meilleur moyen de le faire?

• Étape 1:L'utilisateur entre dans la plaine de texte mot de passe, par exemple"MyDifficultPassword"
• Étape 2:Application des hachages de l'utilisateur-mot de passe et utilise cette valeur comme la clé symétrique pour chiffrer/déchiffrer le fichier de données.par exemple"MyDifficultPassword" --> "HashedUserPwdAndKey".
• Étape 3:Application des hachages de la valeur de hachage à partir de l'étape 2 et enregistre la nouvelle valeur dans le fichier de données de l'en-tête (c'est à direen clair la partie du fichier de données) et utilise cette valeur pour valider le mot de passe utilisateur.par exemple"HashedUserPwdAndKey" --> "HashedValueForAuthentication"

Fondamentalement, je suis en extrapolant à partir de la façon la plus commune pour mettre en œuvre le site web de mots de passe (quand vous n'êtes pas en utilisant OpenID, qui est), qui consiste à stocker l' (salé) hachage du mot de passe utilisateur dans votre base de données et de ne pas enregistrer le mot de passe réel.Mais depuis que j'utilise le hachage de mot de passe utilisateur de la clé de chiffrement symétrique, je ne peux pas utiliser la même valeur pour l'authentification.J'ai donc hachage de nouveau, essentiellement de le traiter comme un autre mot de passe et enregistrez le doublement la valeur de hachage du fichier de données.De cette façon, je peux prendre le fichier sur un autre PC et déchiffrer: il suffit de saisir mon mot de passe.

Alors, est-ce de la conception raisonnables de sécurité, ou désespérément naïf, ou quelque part entre les deux?Merci!

EDIT:la clarification et la question de suivi re:Sel.
Je pensais que le sel devait être gardé secret pour être utile, mais vos réponses et liens impliquent ce n'est pas le cas.Par exemple, cette spécification lié par erickson (ci-dessous) dit:

Ainsi, le mot de passe en fonction de dérivation de clé tel que défini ici est une fonction d'un mot de passe, un sel, et un nombre d'itérations, où les deux dernières quantités n'ont pas besoin d'être gardé secret.

Est-ce à dire que je pourrais stocker le sel de la valeur au même endroit/le dossier de hachage de la clé, et être encore plus sûr que si j'ai utilisé pas de sel lors de hachage?Comment cela fonctionne?

Un peu plus de contexte:le fichier crypté n'est pas destiné à être partagé avec ou déchiffrées par les autres, c'est vraiment unique-les données de l'utilisateur.Mais je tiens à le déployer dans un environnement partagé sur les ordinateurs, je n'est pas entièrement de contrôle (par ex.au travail) et être en mesure de migrer ou de déplacer les données, il vous suffit de copier le fichier (donc je peux l'utiliser à la maison, sur différents postes de travail, etc.).

Answer 1

La Génération De Clés

Je vous conseille d'utiliser un reconnu algorithme tel que PBKDF2 définis dans PKCS #5 de la version 2.0 pour générer une clé de votre mot de passe.Il est similaire à l'algorithme de vous décrire, mais est capable de générer plus de clés symétriques pour une utilisation avec l'algorithme AES.Vous devriez être capable de trouver une solution open-source de la bibliothèque qui implémente PBE générateurs de clés pour les différents algorithmes.

Format De Fichier

Vous pouvez également envisager d'utiliser la Syntaxe De Message Cryptographique comme un format de votre fichier.Cela nécessitera un peu d'étude sur votre partie, mais encore une fois il y a des bibliothèques existantes à utiliser, et il ouvre la possibilité d'inter-fonctionnement de manière plus fluide avec d'autres logiciels, comme S/MIME, les clients de messagerie.

Validation Du Mot De Passe

Quant à votre désir pour stocker une valeur de hachage du mot de passe, si vous utilisez PBKDF2 pour générer la clé, vous pouvez utiliser un mot de passe standard algorithme de hachage (gros sel, un millier de tours de hachage) pour que, et d'obtenir des valeurs différentes.

Sinon, vous pouvez calculer un MAC sur le contenu.Une collision de hachage d'un mot de passe est plus susceptible d'être utile à l'attaquant;un hash collision le contenu est susceptible d'être sans valeur.Mais il ne servirait à laisser un bénéficiaire légitime de savoir que le mot de passe erroné a été utilisée pour le déchiffrement.

Chiffrement De Sel

Sel aide à contrecarrer les pré-calculé les attaques de dictionnaire.

Supposons qu'un attaquant a une liste de probablement les mots de passe.Il peut hachage de chacun et de la comparer à la valeur de hachage de sa victime du mot de passe, et voir si elle correspond.Si la liste est grande, ce qui pourrait prendre du temps.Il ne veut pas passer autant de temps sur sa prochaine cible, de sorte qu'il enregistre le résultat dans un "dictionnaire" où un hachage de points correspondant à son entrée.Si la liste de mots de passe est très, très long, il peut utiliser des techniques comme l'un Table Arc-En-Ciel pour économiser de l'espace.

Cependant, supposons que sa prochaine cible salés leur mot de passe. Même si l'attaquant sait ce que le sel est, son précalculées tableau ne vaut rien—le sel des changements de la valeur de hachage à la suite de chaque mot de passe.Il a re-hachage de tous les mots de passe dans sa liste, l'apposition de la cible du sel à l'entrée.Chaque sel nécessite un autre dictionnaire, et si suffisamment de sels sont utilisés, l'attaquant n'aura pas de place pour stocker les dictionnaires pour eux tous.L'espace de Trading pour gagner du temps n'est plus une option;l'attaquant doit revenir pour le hachage de mot de passe dans sa liste, pour chaque objectif, il veut attaquer.

Donc, il n'est pas nécessaire de garder le sel de secret.Veiller à ce que l'attaquant ne dispose pas d'un pré-calculé dictionnaire correspondant à ce sel est suffisante.

Answer 2

Comme Niyaz a dit, l'approche semble raisonnable si vous utilisez une qualité de mise en œuvre de solides algorithmes, comme SHA-265 et AES pour le hachage et de chiffrement.En outre, je vous conseille d'utiliser un Sel afin de réduire la possibilité de créer un dictionnaire de tous les mots de passe.

Bien sûr, la lecture Bruce Schneier's Cryptographie Appliquée n'est jamais de mal non plus.

Answer 3

Si vous êtes en utilisant un puissant algorithme de hachage (SHA-2) et un puissant algorithme de Cryptage (AES), vous fera l'affaire avec cette approche.

Answer 4

Pourquoi ne pas utiliser une bibliothèque de compression qui prend en charge les fichiers protégés par mot?J'ai utilisé un mot de passe protégé fichier zip contenant du contenu XML dans le passé :}

Answer 5

Est-il vraiment besoin de sauver le hachage de mot de passe dans le fichier.Tu ne peux pas utiliser le mot de passe (ou le hachage de mot de passe) avec un peu de sel puis crypter le fichier avec elle.Lors du déchiffrement juste essayer de déchiffrer le fichier avec le mot de passe + le sel.Si l'utilisateur donne un mauvais mot de passe du fichier décrypté n'est pas correct.

Seuls inconvénients que je peux penser est que si l'utilisateur pénètre accidentellement dans un mauvais mot de passe et le déchiffrement est lent, il doit attendre que d'essayer de nouveau.Et bien sûr, si le mot de passe est oublié, il n'y a aucun moyen de décrypter le fichier.