Toute façon de stocker un mot de passe en toute sécurité dans une application

Question

Je suis très confiant que la réponse à cette question est tout simplement non, mais je voudrais couvrir toutes mes bases.

Dans le contexte de .net, existe-t-il un moyen d'écrire une application, pas une application ou un service Web, mais une application telle qu'elle a accès à un service sans que l'utilisateur final ait accès au même service? Ou, plus concrètement, existe-t-il un moyen de stocker un mot de passe, des informations d'identification d'un formulaire dans une application ou dans une application et un fichier (auxquels l'utilisateur aurait également accès) que je pourrais affirmer un utilisateur ne peut pas utiliser pour extraire les informations d'identification et accéder à ce service en général? Je suis conscient que je pourrais rendre cela très difficile, mais j'ai l'impression que vu ce scénario et mis en place, je ne peux pas rendre la récupération de ces informations d'identification et ce mot de passe plus ou moins impossible. Y a-t-il un moyen de le faire lorsque je peux assurer aux parties intéressées qu'il serait sécuritaire?

Answer 1

La réponse est: non, il est impossible de faire en sorte que l'utilisateur ne peut pas obtenir le mot de passe pour votre service, mais vous pouvez prendre des mesures pour le faire pour les dur pour obtenir le mot de passe.

Certaines choses simples que vous pouvez faire

• Mémorisez le mot de passe crypté sur le disque dur des utilisateurs (qui comprend l'intérieur et les fichiers exe respectées dll) tout ne l'avoir stocké dans un SecureString alors sous la forme non chiffrée. Utilisez les obfuscateurs de code pour rendre plus difficile l'ingénierie inverse de votre code (vous devrez masquer la fonction de déchiffrement de la première suggestion). Héritier d'une personne expérimentée dans ce type de «codage défensif» en tant que consultant pour surveiller votre programme et rendre l'ingénierie inverse plus difficile.
• Ecrivez un service proxy entièrement sous votre contrôle et non hébergé sur un équipement auquel l'utilisateur final a physiquement accès et qui effectue les appels vers le service tiers que vous souhaitez protéger, un utilisateur final peut voir la connexion de votre proxy mais ne pouvait pas voir le login pour ce qui est derrière le proxy.

Toutes ces choses coûtent effort/argent, lors de la conception des mesures de sécurité comme cela, vous devez demander à votre auto la question simple "Combien va me coûter si une personne surmonte les protections que je mets en place et des actions avec le monde? ". Une fois que vous avez cette réponse, vous dépensez autant d'argent/d'efforts pour sécuriser votre produit, car si vous dépensez plus, il aurait été moins coûteux de laisser échapper l'information (une triste vérité sur le développement et la sécurité du logiciel).)