Protection des mots de passe des utilisateurs dans les applications de bureau (Rev 2)

Question

Je crée un client Twitter et j'évalue les différentes façons de protéger les informations de connexion de l'utilisateur.

IMPORTANT: Je dois protéger les données de l'utilisateur d'autres applications. Par exemple, imaginez ce qui se passe si un bot commence à voler des mots de passe Twhirl ou Hotmail / GMail / Yahoo / Paypal à partir d’applications exécutées sur le bureau de l’utilisateur.

Clarification: je l’ai déjà demandé sans la partie "importante", mais l’interface utilisateur de stackoverflow n’aide pas à ajouter des détails ultérieurement dans la conversation Q / A.

• Apparemment, le hachage ne le fait pas
• Obscurber de manière réversible, c’est comme essayer de se cacher derrière mon doigt
• Le texte brut sonne et est probablement promiscuité
• Demander à l'utilisateur de saisir son mot de passe à chaque fois rend l'application fastidieuse

Des idées?

Answer 1

Ceci est un catch-22. Soit vous indiquez à l'utilisateur son mot de passe à chaque fois, soit vous le stockez de manière non sécurisée (obscurcie, cryptée, peu importe).

Pour résoudre ce problème, plusieurs systèmes d'exploitation doivent incorporer des gestionnaires de mots de passe intégrés, tels que le trousseau OS X. Ainsi, vous stockez simplement votre mot de passe dans le trousseau, le système d’exploitation le sécurise et il suffit à l’utilisateur de saisir un mot de passe principal. De nombreuses applications (comme Skype) sous OS X utilisent Keychain pour faire exactement ce que vous décrivez.

Mais puisque vous utilisez probablement Windows, je dirais qu'il faut opter pour l'obscurcissement et le cryptage. Je pense que vous êtes peut-être un peu paranoïaque à propos des robots voleurs de mots de passe; Si votre application n'a pas une base d'utilisateurs importante, les chances que quelqu'un la cible et tentent spécifiquement de voler les mots de passe sont plutôt faibles. En outre, ils devraient également avoir accès au système de fichiers de leur victime. Si tel est le cas, ils ont probablement un virus / ver et ont de plus gros problèmes.

Answer 2

Je pense qu'il vous manque la plus grande image ici:

Si le bureau est compromis, vous êtes F # *% ED!

Pour voler un mot de passe de votre programme, un virus devrait être exécuté sur le système en tant qu'administrateur. Si le virus y parvient, le vol de mots de passe de votre programme va bien au-delà de la liste des actions malveillantes qu’il souhaite faire.

Answer 3

Stockez-le en texte brut et prévenez l'utilisateur .

De cette façon, il n’ya aucune idée fausse sur le niveau de sécurité que vous avez atteint. Si les utilisateurs commencent à se plaindre, considérez xor'ing une constante publiée sur votre site Web. Si les utilisateurs continuent à se plaindre, " masquer " la constante dans votre code et dites-leur que c'est une mauvaise sécurité.

Si les utilisateurs ne peuvent empêcher les personnes malveillantes d'entrer dans la boîte, dans les faits toutes les données secrètes dont ils disposent sont connues du Dr. Evil. Peu importe que ce soit crypté ou non. Et s’ils parviennent à écarter les personnes malfaisantes, pourquoi ne pas stocker les mots de passe en texte brut?

Je pourrais parler de mon cul ici, bien sûr. Existe-t-il une étude montrant que le stockage de mots de passe en texte brut entraîne une sécurité moins bonne que leur stockage obscur?

Answer 4

Si vous créez un client Twitter, utilisez son API

Twitter a une très bonne documentation , je vous conseille donc de tout lire avant de créer un client. La partie la plus importante en ce qui concerne cette question est que vous n’avez pas besoin de stocker les mots de passe, stockez le OAuth à la place. Vous devez utiliser l’étape xAuth pour obtenir le jeton OAuth, puis utiliser les autres API de Twitter avec ce jeton OAuth si nécessaire.

  

xAuth offre aux applications de bureau et mobiles un moyen d’échanger une   nom d'utilisateur et mot de passe pour un jeton d'accès OAuth. Une fois le jeton d'accès   est récupéré, les développeurs activés par xAuth doivent disposer de la connexion et   mot de passe correspondant à l'utilisateur.

Vous ne stockez jamais de mots de passe si vous pouvez vous en sortir

En utilisant OAuth, le pire qui puisse arriver est qu'un tiers (un hacker black hat) obtienne l'accès à ce compte Twitter, mais pas le mot de passe . Cela protégera les utilisateurs qui utilisent naïvement le même mot de passe pour plusieurs services en ligne.

Utiliser un trousseau quelconque

Enfin, je conviens que des solutions préconfigurées telles que le trousseau OSX devraient être utilisées pour stocker les informations OAuth sensibles. Une machine compromise ne révélerait que les informations des trousseaux actuellement déverrouillés. Cela signifie que dans un système multi-utilisateurs, seuls les utilisateurs connectés voient leur trousseau devenir vulnérable.

Autres limitations de dégâts

Il se peut que certaines choses me manquent. Prenez Google "Meilleures pratiques de sécurité". et commencez à lire pour ce qui peut être pertinent.

MODIFIER (en réponse à la solution de cas générale souhaitée)

Vous souhaitez, en l'absence de toute intervention de l'utilisateur, accéder à un service en ligne. Cela signifie généralement que vous disposez au maximum d'un contrôle d'accès de niveau utilisateur sur les informations d'authentification via quelque chose comme Keychain.

Je n’ai jamais utilisé OSX Keychain, je vais maintenant parler de SELinux. Dans SELinux, vous pouvez également vous assurer que ces informations d’authentification ne seront données qu’à votre programme. Et si nous continuons à utiliser des outils au niveau du système d'exploitation, vous pouvez également signer tous les processus, du démarrage à la cryptographie, en étant certain qu'aucun autre programme ne pourrait imiter votre programme. Tout cela dépasse le cadre d'un système utilisateur typique et, avec ce niveau de configuration, vous pouvez être assuré que l'utilisateur n'est pas assez naïf pour être compromis, ou qu'un administrateur système est assez concitant. À ce niveau, nous pourrions protéger ces informations d'identification.

Supposons que nous n'allons pas si loin dans la protection de ces informations d'identification, nous pouvons dès lors supposer que le système est compromis. À ce stade, les informations d'identification de l'authentification sont compromises, l'obscurcissement / le chiffrement de ces informations d'identification du côté local n'ajoute pas de sécurité réelle ni le stockage d'une partie ou de la totalité de celui-ci sur un serveur tiers. Cela est facile à comprendre car, en l'absence de toute intervention de l'utilisateur, votre programme doit se lancer lui-même pour obtenir ces informations d'identification. Si votre programme peut le faire sans entrée, il en va de même pour quiconque a désossé votre protocole d'obscurcissement / chiffrement / serveur.

À ce stade, il s’agit de limiter les dommages, ne stockez pas le mot de passe en tant que données d’authentification. Utilisez OAuth, des sessions de cookies, des hashs salés, etc., ce ne sont que des jetons qui représentent le fait que vous aviez prouvé que vous connaissiez le mot de passe. Dans tous les systèmes efficaces, ces jetons peuvent être révoqués, leur durée expirée et / ou un échange périodique d'un nouveau jeton au cours d'une session active.

Le jeton (quelle que soit sa forme) peut également contenir des informations d’authentification autres que celles saisies par l’utilisateur, ce qui limite votre capacité à les utiliser ailleurs. Il pourrait par exemple encapsuler votre nom d’hôte et / ou votre adresse IP. Il est donc difficile d’utiliser les informations d’identité sur des machines différentes, car pour obtenir ces informations, il faudrait accéder au niveau approprié d’infrastructure réseau.

Answer 5

Après réflexion, je pense avoir trouvé un moyen. Je vais utiliser l'authentification ASP.net pour mon application de bureau d'application, stocker leurs informations d'identification en ligne et laisser le gestionnaire de mots de passe d'Internet Explorer gérer la mise en cache locale de cette paire secondaire ou d'informations d'identification pour moi.

Je devrai simplement les faire authentifier via un formulaire semblable à une API de Facebook lors de la première connexion.

Answer 6

Je ne comprends pas ... pourquoi le cryptage n'est-il pas bon? Utilisez une grande clé et enregistrez-la dans le magasin de clés de l'ordinateur (en supposant que Windows). Fait et fait.

Answer 7

OSX: utilisez le trousseau

Windows: Utiliser CryptProtectData et CryptUnprotectData

Linux: Utiliser le porte-clés GNOME et KDE KWallet