Cryptage de sections et/ou de paramètres dans un fichier App.config qui sera redistribué

Question

Je crée une application Windows régulière qui sera distribuée à plusieurs utilisateurs de mon service. Je dois inclure des mots de passe de connectivité dans le fichier App.config, et je ne veux évidemment pas que les utilisateurs finaux lancent simplement le bloc-notes et regardent les mots de passe.

Plusieurs articles indiquent comment chiffrer/déchiffrer des sections de configuration, mais il semble que vous deviez partager/expédier certaines clés avec la solution déployable.

Existe-t-il un moyen plus simple de chiffrer certains paramètres pour qu'ils ne soient pas lisibles par l'utilisateur, mais ne requièrent pas d'étapes ou de fichiers supplémentaires lors de la redistribution du programme? Un grand avantage serait que l'accès aux paramètres de configuration reste transparent dans le code .NET. Je pourrais toujours créer une méthode personnalisée pour sel/chiffrer la chaîne et dans mon code personnalisé décrypter, mais je me demande s'il y a quelque chose de plus simple. Toutes les réponses ou les liens vers des articles sur la façon de procéder sont grandement appréciés. Merci

Answer 1

Si vous essayez de chiffrer votre chaîne de connexion dans votre App.Config/Web.Config, vous pouvez le faire en utilisant la classe de configuration:

Configuration config = ConfigurationManager. OpenExeConfiguration(ConfigurationUserLevel.None); 
ConfigurationSection section = config.GetSection("connectionStrings"); 
if (section != null) 
{ 
    if (!section.IsReadOnly()) 
    { 
     section.SectionInformation.ProtectSection    ("RsaProtectedConfigurationProvider"); 
     section.SectionInformation.ForceSave = true; 
     config.Save(ConfigurationSaveMode.Full); 
    } 
} 

Il existe deux méthodes: RsaProtectedConfigurationProvider et DPAPIProtectedConfigurationProvider

Voir cette ->http://www.codeproject.com/KB/cs/Configuration_File.aspx et http://msdn.microsoft.com/en-us/library/89211k9b(VS.80).aspx.

Answer 2

De toute façon, le chiffrement et le décryptage du fichier de configuration de l'application est inutile que le fichier .EXE peut être examiné par Reflector! Bien sûr, vous pouvez obscurcir le code, mais cela va faire du débogage un cauchemar dans un environnement de production où un étrange bug inconnu/non découvert se glisse car vous ne seriez pas capable de dire quoi/où/pourquoi/comment surveiller un étrange bug qui n'apparaîtra que dans la version car la pile et les messages d'erreur seraient également masqués ...

C'est quelque chose à garder à l'esprit et un piège potentiel ... l'utilisateur n'est peut-être pas un technophile, mais il est certain ils pourraient en théorie, demander à un ami/parent/partenaire de pirater/casser à votre insu..Cette réponse n'est pas destinée à vous rebuter, et j'espère que vous ne vous sentirez pas offensé par ma réponse ...

J'espère que cet hel ps, Cordialement, Tom.

Answer 3

En bref, la cryptographie n'est pas une baguette magique qui peut réparer par magie un programme non sécurisé.

Un attaquant essayera d'obtenir des mots de passe à partir de la mémoire en utilisant un débogueur pendant que l'application est en cours d'exécution. Les mots de passe existeront également dans le binaire et ceux-ci peuvent être facilement obtenus. L'utilisation de tout cryptage peut être contournée car le mot de passe doit être en texte brut au moment de l'utilisation. Chaque fois que la mémoire est utilisée, elle peut également être observée avec un débogueur.

La réponse se trouve dans l'anti-débogage: http://www.codeproject.com/KB/security/Intro_To_Win_Anti_Debug.aspx

Plus fenêtres avancées anti-debugging:

http://www.veracode.com/blog/2008/12/anti-debugging-series-part-i/

http://www.veracode.com/blog/2008/12/anti-debugging-series-part-ii/

http://www.veracode.com/blog/2009/01/anti-debugging-series-part-iii/

http://www.veracode.com/blog/2009/02/anti-debugging-series-part-iv/