J'ai un programme, où le mot de passe à une base de données est défini par un utilisateur distant. Le programme enregistre le nom d'utilisateur et le mot de passe à une chaîne cryptée dans un fichier XML qui devrait autrement être lisible par l'homme. Cela fonctionne bien, j'utilise le cryptage C # DES avec une clé et il est crypté et déchiffré. Maintenant, le problème est que tout le monde peut utiliser le réflecteur pour voir la clé. Même avec obfuscation, la clé devrait être facilement apparente. Alors, comment traite-t-il de cela? Maintenant, je n'ai pas besoin de cela pour être sécurisé NSA, mais j'aimerais vraiment empêcher quiconque de se tromper. Merci.
Edit: Merci pour tous les conseils jusqu'à présent, des informations sur ce type de chose ne sont pas très répandues, et j'apprécie vraiment des conseils généraux ainsi que des réponses spécifiques.
6 Réponses :
Ce n'est pas vraiment un problème sur le relecteur ou non. Il s'agit de la gestion clé. DES et tout autre schéma de chiffrement s'appuie sur des clés modifiées régulièrement. Codage dur La clé du code viole évidemment ceci. Pour contourner cela, vous devriez examiner la gestion clé.
Edit: Pour élaborer un peu: Selon votre configuration, vous pouvez stocker les mots de passe hachés dans le système de fichiers et s'appuyer sur le système de fichiers / la sécurité de l'utilisateur ou dans une base de données une base de données sur les droits de la base de données.
Pourriez-vous être plus précis dans la façon dont on irait la manipulation de cela?
S'il vous plaît commenter quand le vote en bas. Merci.
Malheureusement, il n'y a jamais une façon 100% sécurisée de faire cela. Vous pouvez bloquer le code, utiliser le code non géré pour les zones secrètes, mais comme votre application est en mesure de lire le mot de passe à nouveau, alors tout attaquant qui met suffisamment d'efforts.
Essayez d'utiliser DPAPI (System.Security.Protectiondata Class). Cela protège vos données cryptées à l'aide des informations d'identification de l'utilisateur ou de la machine. Donc, seul le compte d'utilisateur qui accède aux données (informations d'identification de l'utilisateur) ou à un utilisateur pouvant se connecter à la machine (les informations d'identification de la machine) pourra décrypter vos données.
Cette approche fonctionne bien pour les programmes côté serveur, mais ne va pas bien à l'échelle du côté client
Cela fonctionne particulièrement bien pour le code côté client. Il est plus difficile d'utiliser DPAPI sur une application côté serveur (impersonnation, accès au compte de service aux profils, etc.). Sur un client, l'utilisateur spécifie son mot de passe sur la première exécution de l'application qui est crypté avec leur clé DPAPI. Les données cryptées sont stockées sur leur système de sorte que seules elles (ou un administrateur) peuvent décrypter ces données. Lorsque l'utilisateur démarre à nouveau l'application, DPAPI utilise ses clés pour déchiffrer le mot de passe. Vous bénéficiez d'un avantage de ne pas stocker une clé de cryptage commune dans l'assemblage où elle peut être facilement craquée.
Vous ne devriez pas stocker le mot de passe crypté du tout. Vous devriez le stocker haché à la place, avec une fonction de hachage à sens unique. Voir:
N'aidez pas dans la situation de l'OP, où il a besoin du mot de passe pour accéder à une ressource externe (une base de données).
Et comment allez-vous présenter exactement un hash dans une chaîne de connexion?
Nous avons eu une situation similaire. Nous avons fini par mettre la clé dans un fichier et que l'utilisateur saisit une sorte de mot de passe (ou une clé à l'aide de hachage) pour pouvoir lire le fichier. Ce fut la douleur de rendre l'utilisateur saisir plus d'informations, mais elle supprime la clé du programme.
Vous ne devez pas chiffrer votre mot de passe à l'aide d'un secret intégré dans votre application, c'est la racine de vos problèmes. Quelle que soit la force de votre cryptage, la clé est clairement exposée dans votre code.
Vous devez demander à votre utilisateur les informations d'identification, stocker l'utilisateur / nom de données et votre mot de passe dans une section de configuration ordinaire de votre app.config et comptez sur le DPAPI soutenu sur DPAPIPROCECTCONFigurationProvider Classe Pour chiffrer et décrypter la section pour vous, en utilisant les touches de la machine ou un utilisateur clé spécifique. Voir le lien que j'ai fourni pour un exemple complet comment faire cela.
Vous posez une question de sécurité. Vous avez identifié la ressource vulnérable - la base de données. Vous avez identifié la vulnérabilité - le manque de cryptage effectif sur le fichier de mots de passe. Vous n'avez pas identifié la menace . Il est dangereusement contre-productif d'essayer de trouver des mesures d'atténuation à la vulnérabilité sans d'abord identifier la menace! Qui menace votre ressource et comment?
Eh bien, personne spécifiquement, je voudrais coder mon application pour être sécurisé et non quelles sont les meilleures pratiques.
La meilleure pratique n ° 1 pour le codage des applications sécurisées est d'identifier les menaces. Vous ne pouvez pas être sécurisé si vous ne savez même pas quelles menaces vous garantissez le code. Je veux dire, suppose que je vous ai demandé de me concevoir une maison sécurisée. Vous commenceriez probablement en faisant une liste de menaces pour les occupants de la maison comme première étape, non?
Vous devriez probablement prendre une copie de écrire du code sécurisé . Il vous faudra tout au long du processus d'apprentissage sur la manière d'identifier différents types de menaces et de vulnérabilités et quelles techniques différentes pour les atténuer. Vous voudrez peut-être aussi lire mon article sur la raison pour laquelle écrire des applications sécurisées est comme boire du Dr Pepper: blogs.msdn.com/ericlippert/archive/2008/08/19/...
"Je veux dire, suppose que je vous ai demandé de me concevoir une maison sécurisée. Vous commencerez probablement en faisant une liste de menaces aux occupants de la maison comme premier pas, non?". Non, je commencerais avec les bases des meilleures pratiques (verrous sur les portes, ...). Je ne suis pas en désaccord avec votre point général sur la sécurité, mais je pense que la question de l'OP sur les bonnes pratiques de base est valide.
Je ne vous demande pas de me concevoir une maison . Chaque maison a des verrous sur les portes par défaut. Je vous demande de me concevoir spécifiquement une maison Secure , et la première question doit donc être "sécurisée pour qui, contre quelle menace?" La conception d'une maison sécurisée pour le potus est un problème très différent de la conception d'une maison sécurisée pour le gardien d'Alcatraz, est un problème très différent de concevoir une maison qui est sécurisée pour un abri des femmes battues. Lors de la conception de systèmes sécurisés, vous commencez toujours par les menaces à la ressource.
Plus spécifiquement, la "meilleure pratique" de toute forme de cryptage est la suivante: car le cryptage est un outil complexe et fragile extrêmement bien à atténuer un nombre minuscule nombre de vulnérabilités, et Inutile Pour tout le reste, la meilleure pratique pour tout système impliquant de cryptage est d'identifier clairement le problème que le cryptage est destiné à résoudre, puis à avoir des experts crypto de travailler précisément quels algorithmes résolvent ce problème. Encore une fois, la meilleure pratique pour Crypto est toujours de déterminer les menaces en premier.
Ne jamais stocker les mots de passe ou les clés dans votre fichier de programme ...