Sécuriser un mot de passe dans le code source?
J'ai un mot de passe dans mon code qui est nécessaire pour se connecter à un serveur sftp. Quelle est la meilleure façon de "masquer" ou de le cacher dans le code?
Merci
Ne stockez pas votre mot de passe dans votre code source, stockez-le dans une section protégée de votre App.Config (ou Web.Config).
Voir Chiffrement des sections du fichier de configuration à l'aide de la configuration protégée dans cette section Microsoft Doc
Cela fonctionne en cryptant les clés de cryptage à l'aide de trucs Windows intégrés, verrouillés sur l'adresse Mac et diverses autres choses non documentées.
Cela fonctionnera même si vous utilisez plusieurs serveurs:
... si vous prévoyez d'utiliser le même fichier de configuration chiffré sur plusieurs serveurs, comme une batterie de serveurs Web, seul RsaProtectedConfigurationProvider vous permet d'exporter les clés de chiffrement utilisées pour chiffrer les données et de les importer sur un autre serveur.
En utilisant cela, si quelqu'un voulait obtenir votre mot de passe, il devrait d'abord casser la sécurité de Windows sur votre serveur (pas impossible, mais plus difficile que de chercher dans votre IL pour le mot de passe de loin).
Ne t'embête pas.
Tout ce que vous pouvez faire, votre attaquant peut l'annuler trivialement.
S'il ne doit s'exécuter que sur une seule machine, vous pouvez cependant utiliser la classe ProtectedData , qui le protégera en toute sécurité contre quiconque ne se trouvant pas sur cette machine et/ou cet utilisateur.
En général, la seule façon sécurisée à distance de le faire est de stocker la clé dans un emplacement séparé et sécurisé.
Par exemple, vous pouvez le crypter en utilisant un hachage (non MD5) d'un mot de passe, puis demander à l'utilisateur d'entrer le mot de passe afin que vous puissiez obtenir le hachage. (Le hachage et le mot de passe eux-mêmes ne seront stockés nulle part; vous devez créer un hachage distinct pour vérifier le mot de passe)
En fait, j'envisage d'utiliser la fonctionnalité "sections protégées" dans App.Config ou Web.Config pour être MOINS sûr que de stocker le mot de passe dans votre code.
Toute personne ayant accès au serveur peut déchiffrer cette section de la configuration aussi rapidement que vous l'avez chiffrée en exécutant la commande decrypt décrite dans l'article que tout le monde continue de citer:
aspnet_regiis -pd "connectionStrings" -app "/SampleApplication"
https://msdn.Microsoft.com/en-us/library/zhhddkxy.aspx#Anchor_1
Donc, cette fonctionnalité d'ASP.Net ajoute seulement de la sécurité dans le cas où un pirate aurait en quelque sorte accès à votre web.config mais pas à votre serveur entier (arrivé en 201 comme @ djteller mentionné dans le commentaire d’Oracle Padding Attack). Mais s'ils ont un accès au serveur, vous êtes exposé dans un cmd appel. Ils n'ont même pas besoin d'installer ildasm.exe.
Cependant, le stockage de mots de passe réels dans votre code est un cauchemar de maintenance. Donc, une chose que j'ai vue est de stocker un mot de passe crypté dans votre web.config et de stocker la clé de cryptage dans votre code. Cela atteint l'objectif de masquer les mots de passe de la navigation occasionnelle tout en étant maintenable.
Dans ce cas, un pirate doit au moins décompiler votre code, trouver votre clé, puis déterminer l'algorithme de chiffrement que vous utilisez. Pas impossible, mais certainement plus difficile que d'exécuter "aspnet_regiis -pd ...".
En attendant, je cherche aussi de meilleures réponses à cette question vieille de six ans ...
Le meilleur moyen est de ne pas le faire!
A défaut:
Chiffrement des sections du fichier de configuration à l'aide de la configuration protégée
Il n'y a pas de "meilleure façon" de stocker le mot de passe dans le code source car il peut être récupéré de plusieurs façons.
Vous pouvez masquer la chaîne de mot de passe ou même la crypter pour éviter de la révéler via une simple visualisation, mais elle ne peut pas être traitée comme une protection sérieuse.
Vous pouvez le mettre sous forme de valeur chiffrée dans le fichier web.config. Cela ne semble pas trop difficile: tutoriel K scott Allen http://odetocode.com/blogs/scott/archive/2006/01/08/encrypting-custom-configuration-sections.aspx
Je pense qu'il y a un article de blog Scott gu avec des liens vers d'autres informations. http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
Chiffrez-le avec quelque chose de fort comme AES, mais comme le laisse entendre SLaks, votre attaquant peut effectuer une rétro-ingénierie de votre code et déterminer la méthode et la clé de chiffrement. Tout ce que vous faites est d'ajouter une couche qui empêche les enfants de script et un certain niveau d'attaquant de pénétrer. Quelqu'un qui veut vraiment s'en sortir, peut le faire. Ils pourraient également exécuter votre programme et regarder quel mot de passe est envoyé.
N'enregistrez pas votre mot de passe dans le code source.
Lisez ceci: http://en.wikipedia.org/wiki/Security_through_obscurity
Il n'y a pas de bon moyen.
Tout ce que vous pouvez faire est d'utiliser un algorithme intelligent pour crypter le mot de passe.
Un ingénieur inversé expérimenté parviendrait à le casser.
Vous ne pouvez pas faire grand chose contre quelqu'un qui veut vraiment votre mot de passe. Cependant, si ce n'est pas une application publique (intranet? Application interne ou autre), vous pouvez simplement la crypter en utilisant un algorithme de cryptage symétrique, ou faire quelque chose comme l'encodage en base 64. Vous pouvez également exécuter un obfuscateur sur votre code pour qu'il soit moins évident qu'il y a un mot de passe quelque part.
Avez-vous une autre option? L'accès SFTP brut est un peu dangereux, vous pouvez peut-être créer une sorte de service proxy entre les deux, qui ne permet que les actions spécifiques dont votre application a besoin. Le stockage du mot de passe pour ce service dans votre code n'est pas aussi risqué que le stockage de votre mot de passe SFTP dans votre code.
Vous pouvez utiliser quelque chose comme SLP Code Protector pour bloquer l'ingénierie inverse de vos assemblages. Pourtant, je suis d'accord avec tout le monde, ce n'est pas la meilleure idée.