stockage sécurisé d'une chaine de connexion en .net

Version imprimable

Voir 40 message(s) de cette discussion en une page

24/03/2010, 22h38
Pol63

stockage sécurisé d'une chaine de connexion en .net

bonjour

question qui me turlupine depuis des années
attention aux réponses trop rapides, j'ai déjà des arguments prouvant que ca ne marcherait pas :D

question : où mettre et comment accéder à ma chaine de connexion

informations :
- .exe (windows forms ou wpf)
- base de données avec connexion par login/mot de passe
- login/mot définis par le développeur

parce que mettre la chaine de connexion dans un string forcément via reflector on la retrouve
mettre le tout dans un fichier crypté et décrypter au démarrage du programme c'est pas bon non plus, l'algo de décryptage peut etre retrouvé via reflector

le débat est ouvert, est-ce possible de sécuriser une donnée en .net ...
25/03/2010, 09h25
Guulh

Dynamiquement, en tous cas, il existe la classe SecureString. Mais ça te dit pas comment l'entreposer... :aie:

Je suppose que t'as jeté un oeil ici aussi ?
25/03/2010, 09h36
cybermaxs

Salut,

Il existe un mécanisme natif de protection des fichiers de config via DPAPI. Les sections peuvent ainsi être cryptées en faisant appel aux services de crypto de l'OS.

Je te propose ce lien ou encore celui-ci pour voir le résultat.

(j'espère ne pas avoir répondu trop rapidement)

je vois pas trop comment mettre en place les solutions

genre le code suivant

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
protected override void OnStartup(StartupEventArgs e) 
{ 
    // Lots of other important stuff here... 
    EncryptConfigSection("userSettings/Witty.Properties.Settings"); 
    base.OnStartup(e); 
}
 
private void EncryptConfigSection(string sectionKey)
{
    Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
    ConfigurationSection section = config.GetSection(sectionKey);
    if (section != null)
    {
        if (!section.SectionInformation.IsProtected)
        {
            if (!section.ElementInformation.IsLocked)
            {
                section.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");
                section.SectionInformation.ForceSave = true;
                config.Save(ConfigurationSaveMode.Full);
            }
        }
    }
}

qui crypte le fichier .config, je le met où ?

et puis si dans mon code vb.net y a le code qui obtient le mot de passe, ce code peut etre copié dans un autre projet pour décrypter le .config, non ?

25/03/2010, 11h12
Guulh

Dans le lien que je t'ai filé, la protection ne vient pas du programme lui-même, mais du fait qu'il faut s'identifier comme quelqu'un ayant les droits sur le fichier contenant la clé de décryptage.

je cite :

Citation:

The user account or identity under which ASP.NET runs must have read access to the encryption key used to encrypt and decrypt sections of the Web.config file.
25/03/2010, 11h38
Pol63

sauf que je n'utilise pas asp.net
et que le programme doit etre déployé sur plusieurs pcs

Citation:
Envoyé par Pol63
je vois pas trop comment mettre en place les solutions

genre le code suivant
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 protected override void OnStartup(StartupEventArgs e) { // Lots of other important stuff here... EncryptConfigSection("userSettings/Witty.Properties.Settings"); base.OnStartup(e); } private void EncryptConfigSection(string sectionKey) { Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None); ConfigurationSection section = config.GetSection(sectionKey); if (section != null) { if (!section.SectionInformation.IsProtected) { if (!section.ElementInformation.IsLocked) { section.SectionInformation.ProtectSection("DataProtectionConfigurationProvider"); section.SectionInformation.ForceSave = true; config.Save(ConfigurationSaveMode.Full); } } }
}qui crypte le fichier .config, je le met où ?

et puis si dans mon code vb.net y a le code qui obtient le mot de passe, ce code peut etre copié dans un autre projet pour décrypter le .config, non ?
en réalité, ce qu'il faut comprendre c'est que l'on peut crypter le fichier le de config. Ce cryptage est lié aux jetons des clés publiques et privées de chaque machine. Il est n'est pas possible de crypter une section avant publication. Plusieurs méthodes sont possibles : action post déploiement, au démarrage de l'application, ...
L'exemple est en WPF, mais c'est utilisable aussi en ASPNET et Winforms.

25/03/2010, 17h00
Pol63

bon bah c'est dommage mais je ne comprends aucun des liens ...
25/03/2010, 17h11
cybermaxs

Citation:

Envoyé par Pol63

bon bah c'est dommage mais je ne comprends aucun des liens ...

L'important c'est la méthode EncryptConfigSection. Essaye de le faire sur un projet simple avec appsettings, tu vas vite voir le résultat sur ton fichier.
25/03/2010, 17h18
Pol63

déjà je comprends pas trop
mon fichier .config généré en mettant un setting (dans les propriétés du projet, je suis sous vb.net) de type string et application si je le supprime l'appli fonctionne quand meme
le fichier .config serait inclus dans le .exe ?
26/03/2010, 09h27
cybermaxs

Citation:

Envoyé par Pol63

déjà je comprends pas trop
mon fichier .config généré en mettant un setting (dans les propriétés du projet, je suis sous vb.net) de type string et application si je le supprime l'appli fonctionne quand meme
le fichier .config serait inclus dans le .exe ?

Non, le fichier de config reste un fichier de config comme pour toutes les applications DotNet.
Certaines sections sont altérées, ce qui fait qu'elles ne sont plus lisibles ni décryptable en dehors de la machine cible. Les providers de sécurité de DotNet permettront d'utiliser cette section de manière transparente dans l'appli comme si le fichier n'était pas crypté.
Si tu n'utilises pas le fichier de config, il n'y a aucune raison pour que son absence bloque l'appli...
26/03/2010, 10h21
Pol63

là je l'utilise à priori vu qu'il est généré et contient mes données
mais si je le supprime l'exe fonctionne quand même
26/03/2010, 10h33
cybermaxs

Citation:

Envoyé par Pol63

là je l'utilise à priori vu qu'il est généré et contient mes données
mais si je le supprime l'exe fonctionne quand même

Encore une fois, un fichier de config n'est pas requis pour lancer une application. Dans le cas général, le fichier de config permet de configurer certains élements de l'appli après le lancement de celle-ci. Qu'il soit "généré" ne veut pas dire qu'il soir "utilisé" car la majorité des composants .Net peuvent être utilisé sans config particulière (il existe une config machine qui fait cela). Cela dépend aussi du code de l'application : si tu gère l'absence d'un paramètre, tu n'auras peut être pas d'erreur. Essaye un de mettre une clé dans appSetting et de l'utiliser dans l'application : tu vas vite voir que dans ce cas, le fichier est requis au bon fonctionnement de l'appli mais pas pour son lancement.
26/03/2010, 11h10
Pol63

bon je commence à comprendre
en fait je m'étais emmêle les pinceaux à cause des settings qui sont à la fois mis dans app.config et dans du code généré automatiquement dans vb dans my.settings

mais si j'ai bien compris si on écrit soit même dans le fichier app.config, on peut ensuite lire dans ce fichier

par contre si j'ai bien suivi, il faut crypter le fichier après l'installation de l'exe, et la méthode de décrptage est dans le code de l'appli, mais dans ce cas, avec reflector en reprenant le code de décryptage dans un autre exe, n'a-t-on pas accès au mot de passe ?
de plus à un moment on est obligé d'écrire la vrai password dans le fichier de config avant d'appeler le cryptage, ce qui fait qu'il est accessible en clair durant ce temps
26/03/2010, 15h19
cybermaxs

Citation:

Envoyé par Pol63

mais si j'ai bien compris si on écrit soit même dans le fichier app.config, on peut ensuite lire dans ce fichier

Oui le fichier de config permet d'externaliser quelques comportements et données de ton application afin de la rendre plus modulaire (éviter de recompiler pour changer une valeur).

Citation:

par contre si j'ai bien suivi, il faut crypter le fichier après l'installation de l'exe, et la méthode de décrptage est dans le code de l'appli, mais dans ce cas, avec reflector en reprenant le code de décryptage dans un autre exe, n'a-t-on pas accès au mot de passe ?
de plus à un moment on est obligé d'écrire la vrai password dans le fichier de config avant d'appeler le cryptage, ce qui fait qu'il est accessible en clair durant ce temps

Cette méthode requiert en effet que le fichier soit crypté après. C'est à toi de gérer ce cryptage, lors du déploiement, du premier lancement, .... La méthode n'est pas réellement visible puisque elle utilise les services cryptographiques de Windows. Même visible elle utilise des couples de clé internes dans Windows donc plus difficilement accessibles.
20/05/2010, 12h07
foliv57

Bonjour,

Désolé de déterrer ce post, mais je trouve la question de pol63 très intéressante et, travaillant sur le sujet en ce moment, je pense que les solutions apportés ne sont pas suffisante.

Je m’explique :
La solution du cryptage du fichier de configuration est, bien entendu, la technique qui parait la plus sur et la plus pertinente. (C’est d’ailleurs celle que j’utilisais jusqu'à aujourd’hui)

Malheureusement, en approfondissant un peut, je me suis aperçu qu’il y avait une énorme faille de sécurité avec cette technique.

La section du fichier de configuration est cryptée à l’aide de clés de chiffrements mise à disposition, au mieux, qu’à un seul utilisateur ou à une seule machine.
Par ce fait, un utilisateur (développeur) mal intentionné, pourrait très facilement accéder aux informations cryptées.

Je prends comme exemple une chaine de connexion :
Le développeur voulant sécuriser cette chaine afin qu’aucune personne ne puisse accéder au mot de passe de connexion utilisera le code proposé par cybermaxs lors de l’installation de son application pour crypter la section connectionStrings.

Le développeur mal intentionné n’aura cas :
1) Installer l’application en question
2) Développer une bête application qui liste les chaine de connexion de son propre fichier de configuration (ConfigurationManager.ConnectionStrings)
3) Il n’a pu qu’a faire un copier coller de la section connectionStrings du fichier de configuration crypté dans son fichier de configuration et a lancer son application (Etant donné qu’il a installé l’appli protégée, il a donc accès au conteneur des clés de chiffrement et pourra donc afficher l’information cryptés sans problème)

Je relance ce poste pour avoir votre avis sur le sujet.

Pensez-vous qu’il soit possible de limiter le décryptage à un seul assembly ?
29/06/2010, 14h00
sinople

A mon avis on a beau retourné le problème dans tous les sens on arrivera au mieux à compliquer la tâche de récupération de la chaîne de connexion.

Au final le programme doit à un moment ou a un autre décrypter cette information pour être utilisé sur une machine distante (Qui n'est pas sécurisable par définition, vu qu'a priori on a pas le contrôle dessus). L'utilisateur malveillant aura forcément un moyen de retrouver l'information en question (la difficulté peut tendre vers l'infini mais c'est jamais impossible).

Maintenant on se pose les questions suivante:

A quoi sert ma chaîne de connexion?

A se connecter à une base de donnée afin de réaliser un certain nombre d'opération sur les données contenue dans la base en question.

Pourquoi je ne veux pas afficher ma chaîne de connexion?

Afin d'éviter que l'utilisateur puisse accéder à mes données en évitant les traitements de mon application. (Et y réaliser des opérations non autorisée à l'aide d'une tierce application)

(Au final je m'en contre fou que l'utilisateur veut supprimer une fiche produit sur mon serveur SQL avec entreprise manager plutôt qu'à l'aide de mon programme)

Il faut donc que la sécurité et l'intégrité des données soient gérée par la base de donnée et non par l'application. A l'aide de comptes utilisateurs aux droits restreint et par l'utilisation de procédure stockée (à la place de requête UPDATE & Cie).

Le cryptage de cette chaine de connexion est à mon avis une fausse bataille!!!

C'est un peu le même principe que pour une application web. On réaliser les traitement et les tests sur le serveur et non en javascript dans le navigateur!
30/06/2010, 00h05
Graffito

Citation:

Pensez-vous qu’il soit possible de limiter le décryptage à un seul assembly ?

Pour mes appli qui ne demandent qu'un niveau de sécurité pas trop élevé,
il y a dans le source une clé de cryptage propre à l'appli.

L'utilisateur a une interface permettant de saisir le mot de passe (ou la chaine de connexion) : l'appli l'encode avec la clé de cryptage et l'enregistre en hexa dans un fichier texte.

Pour établir une connexion, l'appli lit le mot de passe (ou la chaine de connexion) cryptée et la décrypte.

Il est bien sur possible de retouver la clé de cryptage en désassemblant le code de l'exe et en introduisant une trace lors de l'établissement de la connexion.

Citation:

Pourquoi je ne veux pas afficher ma chaîne de connexion?
Afin d'éviter que l'utilisateur puisse accéder à mes données en évitant les traitements de mon application. (Et y réaliser des opérations non autorisée à l'aide d'une tierce application)

Ou par exemple que cette chaine puisse être utilisée par un Batch qui sera lancé chaque nuit, sans toutefois figurer en clair dans un fichier de config ou la base de registre.
17/07/2010, 11h01
foliv57

Citation:

Envoyé par sinople

Il faut donc que la sécurité et l'intégrité des données soient gérée par la base de donnée et non par l'application. A l'aide de comptes utilisateurs aux droits restreint et par l'utilisation de procédure stockée (à la place de requête UPDATE & Cie).

Le cryptage de cette chaine de connexion est à mon avis une fausse bataille!!!

Tout à fait d’accord avec toi. Le seul et unique moyen de sécuriser totalement sa base de données est de placer toute la sécurité au niveau de cette dernière.

Dans le cas d’SQL Server, cela permet même d’éliminer le mot de passe de la chaine de connexion en utilisant la sécurité des comptes utilisateur windows.

Mais bien entendu, le travail à faire au niveau de la base est bien plus gros lorsque l’utilisateur n’a accès qu’à certaines informations d’une tables par exemple (création de vues, procédures stockées et autres …). Mais je pense au final que c’est un mal pour un bien.

Malheureusement il réside un dernier petit point noir. Le cas ou on vous demande de développer une application qui devra s’interfacer sur une base de données existante sur laquelle vous n’avez aucun pouvoir de modification (étant donné qu’elle est probablement déjà en production) et pour laquelle on vous fournira uniquement une chaine de connexion avec, bien entendue, le mot de passe dans la chaine (mot de passe que l’utilisateur doit, bien entendue, ne pas connaître).

Je sais, je pousse le bouchon un peut loin, mais ca peut arriver. Je pense que dans ce cas la seule solution de secours est de placer la chaine dans le code de l’application et d’effectuer une obfuscation du code (Obfusquer = rendre le code illisible au décompileur ou lors de la réflexion).

Citation:

Envoyé par Graffito

il y a dans le source une clé de cryptage propre à l'appli.

Désolé Graffito, mais c’est la ou le chien se mort la queue =D. Au final on a toujours une clé quelque part. Et comme tu l’as dit, elle peut être visible à la décompilation.
04/08/2010, 10h16
Laur3nT

Ce sujet est assez proche de la problématique du logiciel de sécurisation HadoUsineAGaz :
http://www.freenews.fr/spip.php?article8655

Le sujet de comment avoir des informations intelligible dans une assembly .NET et indéchiffrable ailleurs est intéressant.

Malheureusement, j'ai peur que la réponse "idéal" n'existe pas.

Voir 40 message(s) de cette discussion en une page