Comment puis-je convaincre mon patron que le stockage de mots de passe tiers en texte brut est une mauvaise idée?
Garder les choses vagues - Je travaille dans une entreprise qui gère les problèmes de conformité pour nos clients. Très souvent, cela signifie que nous devons nous connecter à leurs différents comptes pour différentes entités. Nous stockons leur nom d'utilisateur et leur mot de passe, à la fois pour leur permettre de se souvenir plus facilement et d'y avoir accès, et pour que nous puissions nous connecter à leur compte.
Ignorant le cauchemar de sécurité complet et total du partage des connexions pendant une minute, le nom d'utilisateur et les mots de passe semblent être stockés en texte brut. Hourra.
Comment puis-je convaincre mon patron, et les supérieurs, que A) C'est une idée terrible, B) une meilleure méthode/façon de les stocker
Pourquoi est-ce une terrible idée?
En enregistrant les identifiants de connexion des autres, l'entreprise prend sur elle une responsabilité. Étant donné que l'entreprise est désormais responsable de la malveillance qui pourrait survenir en utilisant ces informations d'identification, l'entreprise devrait prendre des mesures pour minimiser le risque. De plus, les entreprises qui interagissent avec les vôtres doivent assumer la responsabilité de vous faire confiance, ce qui peut nuire aux affaires si un incident devient public (comme mentionné par symcbean)
Le stockage des mots de passe en texte brut (comme vous le savez) n'offre aucune protection contre ce risque.
Quelle est la meilleure solution?
Comme vous l'avez mentionné dans un commentaire, ce dont vous avez besoin est quelque chose comme gestionnaire de mots de passe. En fait, ce que vous voulez est un gestionnaire de mots de passe.
Puisqu'il y a beaucoup de place pour l'erreur en matière de cryptographie, je suggère d'utiliser un gestionnaire de mots de passe établi. Vous pouvez trouver d'innombrables comparaisons en ligne, mais à la fin vos choix incluent ceux basés sur une interface graphique (comme 1password, LastPass, keepass, etc.) ou un basé sur un cli pour un accès automatisé (comme pass ou via le cli LastPass)
Oui, vous faites quelque chose d'horriblement mal. Le fait que votre employeur semble se spécialiser dans la conformité rend la situation bien pire. Les activités de l'entreprise reposent sur une réputation d'excellence en matière de conformité que vous méprisez activement.
Malheureusement à tous les niveaux d'une organisation, il est difficile de convaincre vos supérieurs que ce qu'ils font actuellement est une mauvaise idée. Si j'étais vous, je leur suggérerais de réfléchir à la réaction de leurs clients si:
- on leur a dit que vous stockez leurs informations d'identification en texte clair (sans aucun contrôle de libération/d'audit sur l'utilisation)
- ils ont lu dans le journal qu'un autre client avait été compromis à la suite de cette pratique
Quant à ce que serait une approche meilleure ... vous voulez vraiment l'approche droite, équilibrant la confidentialité, l'intégrité, la disponibilité et le budget. Il existe des produits commerciaux et open source qui pourraient aider à cela, mais cela nécessiterait beaucoup plus d'investigations et d'analyses que ce qui est approprié pour ce forum.
Vous ne voulez pas du tout stocker les mots de passe des utilisateurs, pas même dans KeePass ou quelque chose de similaire.
- Les informations sont masquées par défaut mais peuvent toujours être consultées facilement
- Les mots de passe sont facilement partagés, perdant la responsabilité, c'est-à-dire comment savez-vous que c'est l'utilisateur et non quelqu'un d'autre qui utilise son compte?
- Si un mot de passe est mis à jour (par exemple, un mauvais agent est découvert et que vous souhaitez empêcher tout accès ultérieur), il doit être mis à jour partout ailleurs où il est utilisé.
Voici quelques options, ventilées par scénario:
Si les systèmes que vous utilisez vous appartiennent et sont activement entretenus, vous pouvez demander une fonctionnalité d'usurpation de l'utilisateur. Chaque personne disposant d'un accès administrateur se connecte avec son propre compte administrateur qui est autorisé à basculer vers le compte de n'importe quel utilisateur de base sans avoir à connaître son mot de passe. De cette façon, vous avez un meilleur audit. Vous pouvez voir que ce n'est pas l'utilisateur réel qui a effectué les actions, mais l'utilisateur administrateur spécifique usurpant l'utilisateur. Cela vous protège, vous et l'utilisateur, car aucun ne peut accuser l'autre de malveillance, sauf s'il peut être prouvé que l'utilisateur avait le mot de passe administrateur ou que l'administrateur avait le mot de passe de l'utilisateur et utilisait directement son compte.
- Vous ne connaissez que votre propre mot de passe et vous ne pouvez pas découvrir le mot de passe d'un autre utilisateur, même s'il est menacé (un bon schéma de hachage prend des centaines d'années à se casser par mot de passe, en moyenne)
- Vous n'êtes responsable que de vos propres actions, pas de tout le monde
- Si le mot de passe d'un utilisateur est mis à jour, cela ne vous affecte pas car cela ne change pas la façon dont vous accédez à son compte
Si les systèmes sont externes, c'est-à-dire tiers, vous pouvez essayer de négocier le même type de fonctionnalité d'usurpation de l'utilisateur, en gardant à l'esprit que cela peut être une priorité très faible ou même pas une priorité pour certaines entreprises, c'est-à-dire ne jamais se produire , ou pourrait se produire très lentement (pensez années).
Si les systèmes ne sont plus maintenus, vous n'avez pas de chance. Vos choix sont de cesser de les utiliser en raison du risque, ou de continuer à stocker les mots de passe localement et à accepter le risque.
Rappelez-vous, il ne s'agit pas de si une violation se produira, mais quand une violation se produira.
Oui, plusieurs choses. Stocker des mots de passe en texte brut est évidemment une mauvaise idée. Il est préférable de les chiffrer, mais les mots de passe ne sont généralement pas stockés du tout. Un hachage irréversible est stocké à la place.
Mais le plus gros problème ici est que l'utilisation d'un mot de passe utilisateur pour remplir des formulaires signifie qu'il n'y a aucun moyen de savoir qui a fait quoi avec ces mots de passe. Disons que l'un des utilisateurs de votre clientèle fait quelque chose de mal, voire illégal. Ils affirment qu'il doit s'agir d'un membre de votre organisation. Pouvez-vous prouver que ce n'était pas le cas? Les utilisateurs savent que vous avez accès aux mots de passe, non?
Et comme mentionné dans les autres réponses, il est beaucoup plus probable que des tiers puissent obtenir ces informations d'identification et les utiliser. Si cela se produit, votre organisation est à nouveau potentiellement la cible du blâme.
Si j'étais vous, j'expliquerais les risques à qui vous pourriez écouter. Si je comprends bien, ces informations d'identification sont destinées aux systèmes tiers. Idéalement, vous auriez des comptes sur les systèmes destinés à vos utilisateurs internes. Si vous ne pouvez pas faire cela, vous devriez essayer d'avoir une sorte d'implémentation qui empêche les personnes de votre organisation de voir les mots de passe et les journaux lorsqu'ils accèdent à chaque système.
Si vous devez vous connecter à un compte étranger de quelqu'un d'autre, vous avez besoin de son nom d'utilisateur et de son mot de passe. Il n'y a aucun moyen de contourner cela. Vous ne pouvez pas hacher ou chiffrer1 eux, vous avez besoin des valeurs simples.
Bien sûr, c'est un cauchemar, car les utilisateurs doivent vous divulguer leurs informations d'identification. Ils ont confiance que vous ne les abusez pas. En supposant que vous ne les abusez pas intentionnellement (comme les vendre sur le marché noir dans le cadre de votre modèle commercial), vous devez éviter les fuites. Cela inclut les violations de données dans votre infrastructure ou les administrateurs de base de données pouvant y accéder. Donc, la meilleure pratique ici serait de pas de les stocker du tout. L'activité de votre entreprise consiste à aider l'utilisateur à remplir des formulaires et non à fournir un service de gestion des mots de passe. Pour ", il est plus facile pour [les utilisateurs] de se souvenir " de leurs informations d'identification n'est pas votre travail.
Une solution pourrait être d'écrire une extension de navigateur à installer par vos utilisateurs. Ils se connectent eux-mêmes à ces comptes étrangers, sur leur machine, et votre plugin y fait son travail. Votre serveur n'entre même jamais en contact avec les informations d'identification. (Bien sûr, l'utilisateur doit toujours faire confiance à l'extension pour ne pas les espionner).
Si ce n'est pas une option et que le travail, y compris la connexion, doit être effectué sur votre serveur, vous ne devez toujours pas stocker les informations d'identification de l'utilisateur. Transférez-les simplement au service de connexion étranger, puis stockez uniquement le jeton de session à utiliser avec l'API dans votre base de données aussi longtemps que vous en avez besoin. Si la base de données est violée, l'attaquant pourrait être en mesure de détourner les sessions (pire encore), mais il n'obtient pas le mot de passe en texte brut. Demandez à l'utilisateur de fournir à nouveau les informations d'identification si votre serveur doit se connecter plusieurs fois.
1: Bien sûr, vous devez toujours crypter toutes les données sensibles lorsque vous les stockez n'importe où, mais en fin de compte, la clé doit résider quelque part sur votre serveur, sur lequel un attaquant présumé pourrait également y accéder.
Les managers parlent le langage des affaires, pas la technologie.
Faites une estimation du risque auquel votre entreprise est confrontée avec ces pratiques, exprimé en devises (USD, EUR, selon ce qui est approprié). Il existe différentes méthodes pour ce faire. Une bonne approche consiste à estimer à la fois un scénario réaliste et le pire des cas. Dire à un manager qu'il y a 10% de chances par an d'un incident de sécurité qui pourrait coûter jusqu'à 5 millions de dollars à l'entreprise devrait lui attirer l'oreille.
En plus des dommages potentiels résultant de réclamations contractuelles contre vous de la part de vos entreprises clientes, vous devez également examiner les responsabilités civiles et pénales causées par une négligence grave. Une chance d'aller en prison est une autre chose qui a tendance à attirer l'attention des gestionnaires.
Si votre entreprise a mis en place une gestion des risques, coordonnez-vous avec les gars de là-bas concernant les méthodes et les estimations, le respect des pratiques d'entreprise rendra votre approche plus respectable.
La précaution minimum que vous devez prendre est d'utiliser un gestionnaire de mots de passe ou un autre système qui a) stocke les mots de passe cryptés et b) décrypte uniquement le mot de passe nécessaire, le cas échéant.
Idéalement, vous devriez passer à une méthode basée sur un certificat, mais cela dépend aussi de vos clients et n'est pas entièrement sous votre contrôle.
Vous devriez également avoir une politique de gestion des mots de passe en place qui documente la façon dont les mots de passe sont traités et contient des sanctions en cas de violation. Les filtres de sortie peuvent empêcher une catastrophe de courrier électronique.
Oui, le stockage des mots de passe en texte brut est idiot. Un employé a même accidentellement envoyé par e-mail tous ses mots de passe "stockés" à une liste de distribution interne lors d'un accident de copier-coller. Heureusement, aucun client ne figurait sur la liste.
Nous sommes donc passés à l'utilisation de Teampass qui fonctionne très bien en tant que base de données centralisée d'informations sur les mots de passe.
Il permet également aux groupes ayant différents niveaux d'accès, et chaque utilisateur peut avoir son propre ensemble de mots de passe privés stockés que personne d'autre ne peut lire.
C'est une configuration à partir d'un gestionnaire de mots de passe individuel où tout le monde conserve une copie des mots de passe localement. Donc, si le mot de passe d'un service est mis à jour, tout le monde voit cette mise à jour.
L'historique est également conservé, vous pouvez donc obtenir les mots de passe précédents pour le service X (peut-être qu'un hôte n'a pas été mis à jour et que vous devez remonter dans le temps)
Un autre angle, sauf pour l'évidence (que vous connaissez déjà, comme vous le montrez dans la question - le stockage de mots de passe non cryptés est mauvais):
Ne pas partager/donner des mots de passe est ou devrait être l'un des premiers points de toute directive de sécurité. Aucune banque saine, service en ligne ou autre entité ne demandera jamais de mot de passe. Ceci est ancré dans chaque utilisateur, pour de bonnes raisons.
Si j'étais votre client et que votre employeur me demandait un mot de passe, je ne) vous le donnerais pas et b) courrais à ma direction assez rapidement. J'essaierais beaucoup de m'assurer que nous ne serions plus votre client à tout moment.
Je ne donne même pas mon mot de passe à mes propres gars de support (dans le cas peu probable où ils ont besoin que je me connecte pour eux pendant une session de support, je le ferai moi-même). J'ai été à la réception des contrôles de sécurité (pour les systèmes et/ou les applications) et jamais un compte d'utilisateur réel a-t-il été transmis à la société de sécurité. S'ils doivent se connecter, ils obtiennent leurs propres comptes temporaires. J'ai demandé à des clients de me dire leur mot de passe, et je m'assure de les interrompre immédiatement et de les faire taper eux-mêmes.
TL; DR: N'hésitez pas à montrer à votre direction cette réponse - je serais un client perdu pour vous.