Et si le client a besoin de la capacité de récupérer des mots de passe?

J'ai actuellement hérité d'une application au travail et, à mon grand désarroi, je me suis rendu compte que les mots de passe des utilisateurs stockés dans la base de données sont cryptés à l'aide d'une fonction de cryptage interne, qui inclut également la possibilité de décrypter.

Il suffit donc de copier la table utilisateur et l'assemblage de chiffrement (toute personne ayant un accès de production à la base de données) pour ensuite avoir accès à 100 000 adresses électroniques et mots de passe potentiels.

J'essaie d'expliquer aux entreprises pourquoi ce n'est pas une bonne idée, mais les concepts de sécurité semblent aller au-delà de leurs idées, car ils ne sont pas techniquement orientés (c'est pour le gouvernement). De plus, il existe déjà des fonctionnalités dans l'application permettant aux utilisateurs admin de récupérer les mots de passe des utilisateurs afin de se connecter comme tels et de faire des choses (ce qu'ils ont dit, ils ont besoin).

Donc, ils ne comprennent pas les implications pour la sécurité. Et afin de mettre en place une politique de sécurité renforcée (hachage des mots de passe afin qu'ils ne puissent pas être facilement récupérés), je dois supprimer les fonctionnalités existantes.

Que devrais-je faire? Je n'ai pas créé le système de mot de passe en premier lieu, donc ce n'est pas comme si je pouvais être blâmé si quelque chose tournait mal. D'un autre côté, je ne me sens pas très bien et je ne souhaite pas non plus avoir accès à 100 000 connexions de messagerie potentielles.

Implémentez les fonctionnalités dont ils ont besoin de manière sécurisée. Les administrateurs qui se connectent en tant qu'un autre utilisateur peuvent être implémentés sans qu'ils connaissent le mot de passe de l'utilisateur. Ils peuvent se connecter en tant que tels et disposer ensuite d'une fonction 'changement d'identité'.

Sécuriser une base de données de mots de passe n’est pas un problème commercial, c’est un problème technique. Ne pas le faire est un bug. Si l'entreprise considère la sécurité comme un compromis entre fonctionnalités, la sécurité sera perdante. Vous ne devriez leur donner aucune raison d'y penser de cette façon.

Vous devez les convaincre qu'ils n'ont vraiment pas besoin d'être civilement responsables en cas d'intrusion de leur serveur. Ils n'ont pas non plus besoin de la réaction d'une base d'utilisateurs avertie qui réalise qu'ils font preuve de négligence.

Parfois, il y a des cas évidents où une partie a tort et l'autre a raison. C'est l'une de ces fois.

Regardez ce qui vient de se passer pour Sony. De plus, notre site a été piraté récemment, et l’une des choses qui l’empêchait d’être un désastre total était que nous utilisions une (relativement) bonne fonction de hachage à sens unique (SHA512). Depuis, nous avons opté pour bcrypt pour éviter même les attaques par force brute / dictionnaire (ou du moins les rendre inacceptables). Je ne trouve simplement rien d’autre conscionable.

Fait: les gens utilisent le même mot de passe sur de nombreux sites.

Votre patron ne réalise probablement pas que les gens utilisent souvent un seul mot de passe (ou un ensemble très limité) pour toutes sortes de services (y compris les opérations bancaires ou Facebook et autres). Si les utilisateurs peuvent modifier leur mot de passe sur votre système, ils utiliseront très probablement le même mot de passe qu'ailleurs.

Si votre patron pense que cet accès par mot de passe n'est pas un problème, vous devriez également le leur dire et peut-être qu'ils vont commencer à penser différemment. Même si votre application est derrière le mur et n'est pas accessible au public, elle peut constituer une menace pour la sécurité des autres services en ligne. Les noms d'utilisateur (surtout lorsqu'ils sont des emails) sont plutôt faciles à deviner. Je ne peux pas imaginer à quel point il serait amusant de se connecter au compte Facebook du chef et de mettre quelque chose sur son mur.

Les mots de passe des utilisateurs doivent toujours être traités comme des informations confidentielles de premier niveau auxquelles seuls un nombre limité de personnes ont accès. Il est préférable d'éviter de stocker de telles informations volatiles. Et même lorsque vous le faites, chaque accès à ces informations doit vous être accordé. C'est comme obtenir un papier confidentiel dans un coffre-fort hautement sécurisé qui ne peut être ouvert qu'avec plusieurs clés. Donc, les gens savent qui a été autorisé à accéder et quand.

Comment implémenter la délégation de compte

La délégation de compte dans votre application doit être effectuée différemment.

1. Les administrateurs doivent se connecter eux-mêmes, puis
2. soit (puisque ce sont des utilisateurs privilégiés)
   • entrez uniquement UserName ou
   • sélectionnez un utilisateur dans une liste pour vous connecter en tant que tel

Cela ne devrait absolument pas être fait en vous connectant avec la combinaison Nom d'utilisateur + Mot de passe .

Il est vrai que le nouvel écran devrait être développé pour permettre la connexion déléguée, mais quand même.

Pourquoi la connexion déléguée est-elle meilleure?

Vous pouvez également fournir des fonctionnalités supplémentaires qui indiqueraient clairement que des actions ont été effectuées par l'administrateur pour le compte d'un utilisateur (ce que vous ne pouvez pas savoir maintenant car les administrateurs agissent en tant que dieux et se connectent en tant que tels et peuvent faire des choses qui peuvent nuire véritable réputation des employés).

Vous devez convenir que les gens font des erreurs. Les admins sont aussi des personnes. Et s'ils commettent une erreur au nom de quelqu'un d'autre, ils essaieront de le leur reprocher. Je suis à 100% sûr à ce sujet. Cela rendra la sécurité plus sûre pour les utilisateurs non-administrateurs afin que leur réputation dans le monde réel ne souffre pas des erreurs des autres utilisateurs.

Vous ne mentionnez pas ce que l'application fait. Si ce sont des applications de passeport, pleines d'informations sur le vol d'identité qui doivent être protégées, elles méritent une protection maximale. Mais si c’est «Dites-moi les accidents de la route sur mon trajet de retour», quelles sont les conséquences d’une violation de mot de passe? Certains systèmes que j'ai écrits n'ont même pas de mot de passe - vous entrez simplement votre email, votre numéro d'étudiant ou un autre identifiant que les gens se connaissent souvent, et les propriétaires du système apprécient la facilité d'utilisation et l'impossibilité d'être verrouillé. sur la possible violation de la vie privée si les gens se font passer pour l’autre. Cela ne me pose pas de problème non plus. Pourquoi ai-je besoin d'un mot de passe pour configurer mon horaire de sessions préférées lors d'une conférence, par exemple?

Donc, si on m'avait invité à réviser le code et que vous m'aviez soulevé la question, nous commencerions par là. Que protégez-vous? Quelles sont les conséquences négatives d'une personne qui parvient à se connecter en tant qu'une autre personne? Quelles sont les conséquences négatives de l’exposition des données stockées de chacun? Peut-être qu'ils sont affreux. Vous les listeriez pour moi. Ensuite, quelles sont les conséquences pour les personnes qui ne peuvent pas cliquer sur "envoyer mon mot de passe par courrier électronique" mais doivent cliquer sur "réinitialiser mon mot de passe"? Arrêteraient-ils d'utiliser le site? Et que dire du personnel qui se connecte en tant que personne? Est-ce que cela fait économiser du temps, de l'argent, des ventes perdues ou quoi?

Le dernier élément de l’analyse coûts-avantages, auquel vous ne pouvez accéder que s’il existe une très grande différence entre les négatifs auxquels vous êtes exposé et les négatifs que vous obtiendrez lorsque vous supprimerez une fonctionnalité, est le coût de la réparation. Aurais-je dépensé un million pour m'épargner la possibilité d'une exposition de mille dollars? Non. Qu'en est-il de l'inverse? Cela dépend des chances, je suppose, mais ma première réponse serait oui.

ps - le gouvernement canadien a lancé un site de demande de passeport avec des identifiants dans l'URL: si vous modifiez l'URL avec un identifiant différent, vous voyez le formulaire à moitié rempli d'un autre citoyen aléatoire. Et j'ai des clients qui se connectent en tant que clients à des fins de service à la clientèle pour le bonheur général, alors je vois le bon côté de celui-ci, bien que je ne le supporte pas si les données derrière le mot de passe étaient réellement importantes pour les étrangers.

Cela peut être contraire à la loi et les exposer à des poursuites. S'ils conservent des informations personnelles sur l'utilisateur, ou si le système interagit avec d'autres systèmes, vous devrez peut-être vérifier si le système est soumis à la loi ou aux lois fédérales ou fédérales. c'est à dire. Sarbanes / Oxley, Californie OOPA, etc.

Outre les problèmes juridiques potentiels, vous pouvez également indiquer que tout administrateur peut à tout moment vider la table entière sur une clé de données portable et laisser la possibilité de se connecter en tant qu'utilisateur et de causer des dégâts, ou de vendre les données.

Même si vous supposez que tous les administrateurs sont dignes de confiance, cela compromettrait également la définition d'un mot de passe administrateur dévastateur.

De plus, vous n'avez pas besoin du mot de passe d'un utilisateur pour effectuer les opérations correspondantes. Vous pouvez implémenter une sudofonctionnalité similaire.

Cela ne peut pas être un système du gouvernement fédéral, car les exigences FIPS et FISMA interdiraient le cryptage réversible des mots de passe, et le ministère parent les giflerait à la lune.

Et afin de mettre en place une politique de sécurité renforcée (hachage des mots de passe afin qu'ils ne puissent pas être facilement récupérés), je dois supprimer les fonctionnalités existantes.

Pour ma société précédente, je me suis battue pour pouvoir envoyer des courriels de réinitialisation de mot de passe pour résoudre ce problème. Et j'ai continué à être rejeté. À la fin, j'en ai eu marre de pelleter la merde à contre-courant, alors je suis parti. C’était aussi un chef aux cheveux pointus qui pensait que les questions stupides posées par certains sites Web de banques comptaient comme une "authentification à 2 facteurs". Se disputer avec lui ressemblait à un dessin animé de Dilbert (il avait la forme du PHB).

De plus, il existe déjà des fonctionnalités dans l'application permettant aux utilisateurs admin de récupérer les mots de passe des utilisateurs afin de se connecter comme tels et de faire des choses (ce qu'ils ont dit, ils ont besoin).

J'ai vu cela implémenté dans une institution financière. Les personnes de la zone de support client se connecteraient avec leurs propres informations d'identification et, si elles en avaient le droit, pourraient faire semblant de se connecter en tant que client. Cela ne les connectait pas en tant que client, mais personnifiait le client . Ainsi, si le représentant du service clientèle décidait de retirer de l’argent, il ne l’indiquerait pas comme le client le notait dans les journaux: il le montrerait alors qu’il essayait de le faire (tout en envoyant une alerte pour qu’il soit renvoyé dès que possible. le rentacop pourrait se rendre à leur étage).

Fait mal, le personnel du service clientèle serait en mesure de faire croire que l'utilisateur final se livrait à une activité susceptible d'entraîner de lourdes responsabilités financières ou juridiques.

Le dernier site Web fédéral sur lequel je travaillais collectait 1/4 milliard de dollars par an auprès des utilisateurs finaux (il y en avait environ 400), de sorte que la journalisation devait être très stricte et que seul l'utilisateur final autorisé était autorisé à toucher. les pages Web où ils ont rapporté les choses sur lesquelles ils ont payé les taxes d'accise.

Sony était l'une des sociétés avec la dernière violation de sécurité. Ce n'était pas seulement le réseau PS3, c'était aussi leur réseau de jeux MMORPG, totalisant plus de 25 000 000 noms, adresses, numéros de cartes de crédit, noms d'utilisateur et mots de passe. Vous pouvez croire que je ne suis pas du tout heureux (je veux mon evercrack!).

Je fais référence au code de déontologie du génie logiciel sur de tels problèmes. Mon interprétation, votre première priorité est de ne pas porter atteinte à l’intérêt public (non pas comme une possibilité de mot de passe compromis, comme dans cet exemple, dans lequel une entreprise a modifié les ordinateurs portables Dell afin que la société de location puisse espionner leurs locataires sans le savoir). Après cela, votre responsabilité est d'informer votre client des risques potentiels et de les laisser en tenir compte. Bien sûr, c'est la base minimale. Vous devez utiliser votre propre jugement pour savoir si vous estimez que cela reste encore plus que vous ne pouvez vous permettre et le permettre.

Bien sûr, lorsque vous parlez d'un projet gouvernemental, si les informations privées des citoyens sont en danger à cause de ces pratiques, elles sapent l'intérêt public.

Vous pouvez imprimer la liste des courriels et le mot de passe déchiffré et le mettre sur le bureau de votre supérieur, avec un grand avertissement sur la page de couverture: "Confidentiel".

Faites la police minuscule afin de ne pas gaspiller le papier si.

Vous pouvez également leur montrer comment bugzilla permet aux administrateurs d'emprunter l'identité de personnes sans utiliser leur mot de passe.

Tout d'abord, je suis d'accord avec les autres réponses en soulignant qu'il est beaucoup plus prudent d'éviter cela, et ne stocke que les hachages de mots de passe, pas les mots de passe eux-mêmes, ou tout ce qui peut être transformé en mot de passe.

Cependant, il arrive parfois que vous ayez plus ou moins besoin de permettre la récupération. Dans le cas des mots de passe, vous souhaitez généralement récupérer en autorisant simplement un administrateur à modifier le mot de passe lorsque / si nécessaire plutôt qu'en récupérant le mot de passe existant.

Une autre possibilité, cependant, est que vous autorisiez l'utilisateur à stocker des données sur le serveur crypté avec son propre mot de passe. Dans ce cas, autoriser simplement un administrateur à modifier le mot de passe ne suffit pas . Le nouveau mot de passe ne fonctionnera pas pour décrypter les données et la plupart des utilisateurs trouveront inacceptable que toutes leurs données cryptées deviennent inaccessibles quand / s'ils oublient / perdent un mot de passe. Dans cette situation, il existe une solution raisonnablement sécurisée qui permet toujours une récupération lorsque cela est vraiment nécessaire.

Au lieu d'utiliser le mot de passe de l'utilisateur pour chiffrer les données, vous créez une clé aléatoire pour chiffrer les données elles-mêmes. Vous stockez ensuite cette clé à deux endroits: une fois chiffrée avec le mot de passe de l'utilisateur et à un autre endroit chiffrée avec un mot de passe administrateur. Puis, quand (pas vraiment si) l'utilisateur perd son mot de passe et ne peut plus accéder directement aux données, vous pouvez utiliser le mot de passe administrateur pour déchiffrer la clé réelle et l'utiliser pour récupérer les données et / ou rechiffrer la clé avec le nouveau mot de passe de l'utilisateur.

Si vous ne voulez pas totalement faire confiance à un seul administrateur, vous pouvez également le gérer. Par exemple, vous pouvez décider que 5 personnes auront des clés d’administrateur et vous voulez qu’au moins trois d’entre elles se mettent d’accord avant qu’une clé ne soit récupérée. Dans ce cas, lorsque vous stockez le mot de passe crypté à des fins administratives, vous le stockez plusieurs fois, une fois pour chaque ensemble de trois des cinq administrateurs (ce qui ne prend pas beaucoup de place, car vous ne stockez que plusieurs clés , ~ 256 bits chacun, pas de multiples copies des données). Chacune de ces copies est successivement cryptée avec (les hachages de) chacun des mots de passe de ces trois administrateurs.

Pour le déchiffrer, vous devez identifier les trois administrateurs qui entrent leur mot de passe, choisir la clé chiffrée appropriée pour cet ensemble de trois, puis déchiffrer à l'aide de chacun des trois mots de passe pour obtenir finalement la clé d'origine. Vous pouvez ensuite l'utiliser pour récupérer les données elles-mêmes ou simplement les rechiffrer avec le nouveau mot de passe de l'utilisateur afin qu'il puisse toujours accéder à ses données.

Cependant, pour ce faire, vous devez vraiment utiliser un algorithme de cryptage standard et (par forte préférence) une implémentation standard, bien connue et bien étudiée.

Cela m'inquiète, étant donné qu'il s'agit d'un projet gouvernemental. La récupération du mot de passe d'un utilisateur pour effectuer une action sous son identifiant rend absurde tout type d'audit de sécurité. La seule raison pour laquelle je vois ceci est la création d'une fausse piste d'audit.

Il n'est vraiment pas nécessaire d'utiliser un cryptage réversible pour les mots de passe. S'il existe un motif légitime d'usurper un ID utilisateur, vous pouvez le faire de la manière suivante:

• Stocker le hachage de mot de passe actuel
• Remplacer par une valeur connue
• (Faux-audit-trail-activity, par exemple, virer des fonds sur un compte offshore)
• Remplacer le mot de passe original

La dernière étape me mettrait mal à l'aise: quiconque était imitateur du système devrait savoir que cela s'est passé. Peut-être pouvez-vous convaincre l’entreprise en disant: «C’est comme si votre banque me permettait d’accéder à votre compte à votre insu, car j’avais dit que j’en avais vraiment besoin»

Leur croyance en un meilleur système de mot de passe n'est pas le problème. Créez une solution pour permettre à un administrateur / au support d'emprunter l'identité d'un compte d'utilisateur et de fournir votre solution pour les mots de passe. La sécurité en pâtit souvent pour des raisons de commodité. Rendez-le pratique et sécurisé.

Edit: Ils ne comprendront jamais parfaitement le problème de la sécurité par mot de passe, mais ils comprennent la perte de fonctionnalité. Faites cette proposition et voyez si vous pouvez obtenir l’approbation nécessaire pour apporter les modifications nécessaires. Ils ne savent même pas si cela prendra une heure ou un an. C'est un changement de fonctionnalité et non une reconstruction complète.

Compte tenu des événements actuels (fuite de données Epsilon et de Playstation Network), on peut espérer que les problèmes seront manifestement évidents.

Parfois, toutefois, en tant que développeur, vous ne pouvez tout simplement pas affecter la stratégie.

Je ferais de mon mieux pour montrer le potentiel de scandale et de dépense, ce qui devrait être facile, compte tenu également de l'actualité. Mais si cela échoue, que pouvez-vous vraiment faire? Pas tant. Quittez en signe de protestation, démontrez la vulnérabilité pour attirer l'attention. Ni l'un ni l'autre ne semblent d'excellentes options.

Je vous déconseille cela, mais si vous devez absolument avoir la capacité de déchiffrer les mots de passe, vous devez utiliser le chiffrement à clé publique. De cette façon, vous pouvez chiffrer tous les mots de passe à l'aide de la clé publique. Vous pouvez vérifier les mots de passe en cryptant avec la clé publique et en effectuant des comparaisons. Vous pouvez également conserver la clé privée ailleurs (pas sur l'ordinateur de production).

Habituellement, la raison pour laquelle un administrateur voit le mot de passe de l'utilisateur est qu'en cas de perte, il peut le donner à l'utilisateur. Autant que je sache, Windows ne permet pas à l'administrateur de voir le mot de passe non plus - alors pourquoi votre application devrait-elle l'être? Toute bibliothèque interne de chiffrement est surement cassée car je suis sûr que quiconque l’a écrite ne fonctionne pas pour la NSA.