Question:
Comment demander en toute sécurité les mots de passe du client en tant que cabinet de conseil?
Wim Deblauwe
2016-06-23 16:45:55 UTC
view on stackexchange narkive permalink

Dans mon travail de développeur, j'ai parfois besoin de combos nom d'utilisateur / mot de passe du client pour m'assurer que les paramètres des services tiers sont corrects pour fonctionner avec le site Web / l'application que nous construisons. Par exemple. un fournisseur de paiement que nous utilisons sur un site Web de jeu.

Quelle serait la bonne façon de demander son nom d'utilisateur et son mot de passe pour qu'il reste sécurisé? Si je leur envoie un e-mail, bien sûr, ils vont simplement me renvoyer un e-mail en texte brut avec le mot de passe, mais ce n'est pas sécurisé.

MISE À JOUR:

Je vois que ma question a été un peu mal comprise, alors je vais ajouter un exemple:

Supposons que je suis développeur pour CoolSoft, une société de logiciels. Une autre société (appelons-les Games, Inc.) veut que nous leur créions un site Web. Ce site Web utilisera des services tiers pour le paiement et le support client avec lesquels nous devons nous intégrer. Games, Inc. crée des comptes avec le fournisseur de paiement et le fournisseur de support client. Mais ils ne sont absolument pas techniques et nous avons besoin de leurs identifiants pour définir les URL de rappel correctes, etc. Comment peuvent-ils nous envoyer leur mot de passe en toute sécurité afin que nous puissions corriger les paramètres de leurs comptes (nous ne nous rencontrons jamais en personne)?

Le contact humain est-il hors de l'équation?
Oui, j'ai oublié de le mentionner en effet.
Bien que la réponse de Philip semble bonne, ce n'est pas toujours une solution possible, vous pouvez donc utiliser une application cryptée de bout en bout comme celle mentionnée par oleksii.
Je viens de remarquer une question similaire: http://superuser.com/questions/21391/how-can-clients-easily-and-securely-send-me-passwords
une fois que vous connaissez les crédits du client, qu'est-ce qui les empêche de vous blâmer pour tout problème qui survient à tout moment dans le futur?Vous ne voulez vraiment pas cette information
Je travaille avec un site tiers comme celui-ci où vous avez absolument besoin de ces informations d'identification pour faire du développement.Ce que nous faisons (puisque c'est toujours un travail de type de développement initial pour nous), c'est d'utiliser un mot de passe jetable pendant le développement.Ensuite, dans le cadre du transfert du produit, nous accompagnons le client dans la prise en charge des informations d'identification et la définition de son propre mot de passe réel.Cela élimine les problèmes que tout le monde mentionne au sujet du fait d'être blâmés pour des actions futures.
@NeilSmithline Euh, le fait qu'ils aient changé leur mot de passe dès qu'OP a fini de faire ce qu'il fait, parce qu'ils suivent une politique de sécurité sensée comme des gens sensés?
Veuillez vérifier votre site Web pour l'injection SQL.Votre code sent.
Vous devriez pouvoir simplement ajouter un hook d'administrateur dans votre code.Comme un paramètre caché `? Adminlogin = true`, puis entrez le mot de passe administrateur dans le compte de l'utilisateur.Le SQL pourrait vérifier le mot de passe de l'administrateur à la place.
Je suis désolé, votre exemple me rend les choses floues.Pouvez-vous préciser la fin?Pourquoi auriez-vous besoin des informations d'identification?Pourquoi devriez-vous "corriger les paramètres de leurs comptes"?
Votre exemple est trop abstrait.Que fait la société Games?Et que fait le site CoolSoft?
«Nous ne nous rencontrons jamais en personne» Peut-être que vous devriez.Il me semble qu'il y a trop d'acteurs dans cette pièce.CoolSoft, Games, le prestataire de paiement, le prestataire de support client: déjà 4 acteurs, c'est trop.Je pense que cela fait partie de votre problème.
Puis-je avoir une réponse à ma suggestion `? Adminlogin = true`?
Je suis déconcerté par le nombre de personnes qui expriment leur surprise face à ce scénario.Oui, dans un monde idéal, chaque acteur serait abonné à ce site, et collaborerait à la solution.Mais la question me paraît tout à fait raisonnable car "étant donné une situation malheureuse dont je ne suis pas totalement maître, comment minimiser les risques de sécurité".
Pour un exemple concret, considérons un panneau de contrôle DNS.Celles-ci sont complètement déroutantes pour les utilisateurs non techniques, mais peuvent nécessiter un accès multiple dans le cadre d'un déploiement.Dans un monde idéal, le fournisseur DNS permettrait de déléguer temporairement l'accès à un deuxième nom d'utilisateur, mais dans le monde réel, vous devrez vous connecter à ce panneau de contrôle d'une manière ou d'une autre.
Huit réponses:
Philipp
2016-06-23 17:05:58 UTC
view on stackexchange narkive permalink

Vous ne le faites pas.

Lorsque vous apprenez aux utilisateurs à donner leur nom d'utilisateur et leur mot de passe à quelqu'un, vous les apprenez à être vulnérables au phishing ou à d'autres attaques d'ingénierie sociale.

À la place, concevez le système de manière à ce qu'un administrateur puisse afficher et modifier ces paramètres sans avoir besoin des informations d'identification des utilisateurs.

Lorsque vous êtes dans une situation où vous avez vraiment besoin de voir les choses du point de vue de l'utilisateur pour résoudre un problème, demandez à l'utilisateur de taper le mot de passe pour vous, puis laissez-le vous montrer le problème. Cela peut être fait en personne ou avec un outil d'administration à distance.

Lorsque vous vous trouvez dans une situation où le client dispose des informations d'identification dont vous avez besoin dans votre application pour s'intégrer à une solution tierce, développez votre application dans un façon qu'un utilisateur non technique dispose d'une interface utilisateur facile à utiliser pour définir ces informations d'identification. Vous en aurez besoin de toute façon au cas où le client aurait besoin de les modifier et que vous ne soyez pas disponible.

L'utilisateur n'aura pas à saisir cela tant que l'application ne sera pas déployée sur ses propres serveurs. Pendant le développement, vous devez utiliser un compte de test de votre côté pour vous connecter avec les tiers. Vous ne voulez certainement pas entraîner de frais pour votre client car vous avez effectué des tests sur les interfaces de paiement tierces qui n'ont pas fonctionné comme vous le souhaitiez.

... quand c'est possible.Même dans les environnements modernes, il semble toujours y avoir des comptes système, des comptes d'administrateur de fournisseur ou d'autres informations d'identification qui finissent par être partagées.
Je pense que ma question n'était pas claire.J'ai ajouté un exemple qui, espérons-le, le rend plus clair.
@WimDeblauwe votre question était claire, la bonne réponse est toujours "Vous n'avez pas".Si vous voulez le tester de votre côté, il est préférable de sauvegarder le hachage de vos informations d'identification ... éditez-y le mot de passe / clé api ... test ... puis restaurez-y les informations d'identification.
@schroeder simplement parce que cela arrive tout le temps ne signifie pas qu'il est sécurisé ou une meilleure pratique.
Il me semble que l'outil d'administration à distance serait la voie à suivre et éviterait le besoin de partager un mot de passe.
@CaffeineAddiction Je dis que ce n'est pas toujours * possible * ...
L'administrateur distant @ben ne correspond pas à l'exemple de la question
@WimDeblauwe J'ai mis à jour la réponse.Ma conclusion ne change pas: vous n'avez pas besoin des mots de passe des utilisateurs et vous n'en voulez pas.
@schroeder bien sûr, à moins que je ne comprenne mal ce que signifie «administrateur à distance».J'imagine une session de bureau à distance comme le fait notre service informatique pour les utilisateurs du réseau d'entreprise lorsqu'ils ont besoin d'aide pour configurer quelque chose.L'utilisateur se connecte à tout ce qui a besoin d'accéder, et le support guidera l'utilisateur à travers la configuration ou prendra simplement le contrôle et le fera pour lui.Ensuite, par téléphone, l'assistance peut guider l'utilisateur dans la désactivation ou la désinstallation du logiciel distant utilisé, si nécessaire.
@ben a lu la mise à jour de Philipp sur sa réponse concernant l'intégration tierce
En lisant la question, il s’agit de devenir l’administrateur, pour une entreprise qui n’a pas d’employé propre, en tant qu’entrepreneur.Si le système dispose d'un compte d'entreprise et de comptes d'utilisateurs distincts qui peuvent être autorisés à accéder au compte d'entreprise, c'est très bien.Mais certains systèmes n'ont que des comptes d'entreprise avec des informations d'identification et il n'y a aucun moyen de contourner ces informations d'identification.
@JanHudec: Je lirais votre objection comme "il n'y a pas moyen sans encourir des dépenses déraisonnables".Il y a toujours un moyen.Mais avoir besoin des deux parties pour installer un logiciel à distance, ou former du personnel, ou ajouter un composant de gestion des informations d'identification (n initialement non planifié) à un système peut affecter le budget et / ou le temps.Dans ces cas, une organisation soucieuse de la sécurité doit au moins être consciente des meilleures pratiques et être capable de s'expliquer à elle-même et au client quels compromis elle fait et comment minimiser les risques.
@NeilSlater, il y a un tiers ici.Pensez à Google Play - ils permettent maintenant d'accorder des autorisations à d'autres comptes, mais au début, ils ne l'ont pas fait.L'entrepreneur embauché pour le gérer a donc besoin d'un accès et s'il n'y a qu'un seul ensemble d'informations d'identification, eh bien, l'entrepreneur en a besoin.La «dépense déraisonnable» consiste à «oublier complètement l'entreprise» ici.Il n'y a pas non plus de différence principale entre un entrepreneur et un employé - l'entreprise doit faire confiance à quelqu'un pour avoir le mot de passe principal.
C'est très révélateur de notre industrie de la sécurité que la réponse la plus votée n'est pas une solution et ne prend en fait pas beaucoup de cas en considération.Le PO ne demande pas les meilleures pratiques, il demande un moyen de transférer les mots de passe en toute sécurité.
schroeder
2016-06-23 17:02:49 UTC
view on stackexchange narkive permalink

Il existe de nombreux «gestionnaires de mots de passe d'équipe» qui permettent aux équipes de partager, modifier et révoquer l'accès aux informations d'identification. La plupart sont payants (ou gratuits pour les petites équipes), mais c'est probablement la meilleure solution. Ils fournissent généralement un cryptage, ainsi qu'un contrôle d'accès sur l'accès à des informations d'identification spécifiques.

Des exemples que vous pouvez donner?
@WimDeblauwe si vous google "gestionnaire de mot de passe d'équipe" vous avez beaucoup de choix
LastPass Enterprise est un exemple.https://lastpass.com/enterprise_overview.php
Et 1Password a également une équipe basée sur le cloud.https://1password.com/teams/
[CyberArk PIM] (http://www.cyberark.com/products/privileged-account-security-solution/enterprise-password-vault/) fonctionne bien pour les grandes organisations.
HopelessN00b
2016-06-23 20:08:16 UTC
view on stackexchange narkive permalink

La seule option viable que je vois (qui n'a pas encore été mentionnée, étrange) est d'avoir le (s) compte (s) de configuration du client avec les autorisations appropriées à utiliser sur ces systèmes / services Internet. De cette façon, ils gèrent les relations avec les fournisseurs et le paiement, mais vous avez des comptes qui ont l'accès dont vous avez besoin.

Comme la réponse de Phillip l'a indiqué, vous ne demandez tout simplement pas ou ne participez pas dans le partage des mots de passe. C'est tout simplement mauvais, car vous vous mettez en position d'être blâmé si quelque chose ne va pas lorsque quelqu'un d'autre utilise le compte partagé. ("Je sais que mes employés ne feraient jamais quelque chose comme ça, et vous êtes les seules personnes avec qui nous avons partagé le mot de passe, donc ça doit être quelque chose de vous ! ! ")

réponse parfaite, j'ajouterais aussi le souci des SLA d'être modifiés si les mots de passe devaient être échangés, je ne laisserais jamais personne avoir de mot de passe sans une obligation légale.Et l'avantage de la perte des informations d'identification pour votre compte moins privilégié lié à l'emploi ne serait pas aussi nuisible que la perte des crédits d'origine (à Dieu ne plaise si cela arrive).
Conceptuellement, c'est une bonne idée, mais cela impose toujours au client des exigences qui peuvent être difficiles à satisfaire.Il nécessite encore un certain savoir-faire technique côté client.
@Ijustpressbuttons la configuration des comptes utilisateurs n'est généralement pas un processus technique.Un client qui trouve que c'est une exigence onéreuse va être un cauchemar.
@HopelessN00b Cela dépend du système dans lequel ils créent des comptes, sûrement?Certains systèmes n'auront tout simplement pas la capacité de créer des connexions supplémentaires ou de déléguer l'accès;d'autres auront des systèmes complexes d'autorisations qui nécessitent une navigation.Comme beaucoup de réponses ici, cela semble dépendre de la capacité à influencer les protocoles de sécurité du tiers afin d'esquiver la question.Au mieux, il pourrait figurer sur une liste «épuiser ces possibilités avant de continuer».
@IMSoP Il y a beaucoup de conneries là-bas, bien sûr, un service «cloud» / web / n'importe quel service (service tiers qui s'intègre à un site Web) sur lequel il est difficile de configurer de nouveaux utilisateurs / comptes est un type particulier de merde.C'est comme fumer et pomper de l'essence en même temps.Ouais, vous pouvez généralement trouver un moyen de le faire fonctionner, mais vous ne devriez * vraiment * pas le faire.Si vos fournisseurs sont si mauvais, courez.
@HopelessN00b Je ne suis pas du tout d'accord.Le modèle d'autorisation par défaut pour la plupart des systèmes est que vous vous inscrivez pour un compte et que ce compte «possède» tout ce qu'il contient.La possibilité de créer des sous-comptes ou de déléguer l'accès à votre configuration à un autre compte est assez rare.Si vous refusiez tous les contrats où quelqu'un avait choisi un fournisseur moins que parfait, vous vous expulseriez d'un emploi.
Falco
2016-06-24 13:59:42 UTC
view on stackexchange narkive permalink

Je résume la situation comme suit

  • vous avez besoin d'accéder à un service tiers avec le compte de votre client
  • une réunion en personne n'est pas facile
  • une solution impliquant l'installation du logiciel par le client ou suivant une procédure complexe n'est pas souhaitable

Je pense que la meilleure solution serait: Envoyez-leur un nouveau mot de passe

Vous envoyez-leur un mot de passe de manière sécurisée et donnez-leur des instructions (par téléphone?) pour qu'ils définissent le mot de passe de leurs comptes temporaire à votre mot de passe proposé. - Ensuite, vous pouvez l'utiliser pour vous connecter à la page. Et lorsque vous avez terminé, ils peuvent réinitialiser leur mot de passe à la valeur d'origine.

Un moyen simple serait un lien unique dans le courrier, ce qui conduit à une page affichant le mot de passe. Le client peut cliquer dessus, copier le mot de passe. Et un attaquant ne pourra pas accéder au même lien de mot de passe. (De couse une attaque MitM ciblée avec la modification du contenu du courrier serait toujours possible et pourrait être atténuée en signant le courrier)

Vous pouvez également leur indiquer le mot de passe temporaire par téléphone, ils l'écrivent et modifient leur mot de passe du compte temporairement à celui que vous lui indiquez.

Cette méthode inverse présente plusieurs avantages:

  • Votre client peut respecter la règle "Ne jamais partager votre mot de passe"
  • Vous pouvez choisir un moyen sécurisé de relayer le mot de passe, vous n'avez pas à enseigner à votre client de manière sécurisée.
  • Votre client garde le contrôle de l'octroi et de la révocation de votre accès
HashHazard
2016-06-23 17:02:31 UTC
view on stackexchange narkive permalink

Il existe littéralement des tonnes de solutions pour transmettre des données (par exemple, des identifiants) en toute sécurité.

  • Si le client prend en charge le cryptage PGP / GPG, vous pouvez échanger des clés publiques et crypter les e-mails
  • Il existe également des sociétés spécialisées dans SecureMail (ZixCorp) ou vous pouvez acheter le vôtre (Cisco Ironport).
  • Si vous avez un site de collaboration (par exemple, un portail client pour le client), ils peuvent télécharger les informations d'identification sur le portail. FYI Alfresco est une application freeware qui fait du bon travail.
  • Même si le contact humain est hors de question, pouvez-vous envoyer un SMS? Peut-être qu'ils peuvent envoyer un message texte du mot de passe et fournir le nom d'utilisateur via un autre canal.
  • Si tout le reste échoue, les signaux de fumée et le courrier postal sont toujours une chose, mais les méthodes ci-dessus sont les vecteurs les plus courants.
Le texte n'est pas sécurisé à moins que vous ne le fassiez via une application telle que Signal
@rhymsy exactement pourquoi j'ai dit envoyer seulement le mot de passe.Un texte avec des caractères mélangés (et généralement via une image MMS au lieu de caractères réels) sans contexte environnant ne fait aucun bien à l'intercepteur.
@rhymsy - Ce n'est pas clair.Pouvons-nous envoyer des SMS via l'application Signal?
@Hollowproc - Si l'intercepteur veut intercepter le mot de passe, alors un texte de caractères sans signification est parfaitement significatif pour l'intercepteur.Pour les mots de passe, je préfère la règle ** «Ne jamais l'écrire» **, et je recommande plutôt le téléphone.Nous pouvons même être paranoïaques et diviser la communication en plusieurs appels téléphoniques.De / vers différents téléphones, de / vers différentes personnes…
@NicolasBarbulesco comme l'a dit OP, le téléphone n'est pas une option dans ce scénario.La solution «Signal» implique également que vous fassiez confiance à un tiers avec le contenu du message SMS / MMS qu'ils «chiffrent»;un simple message texte sans contexte devrait suffire, car les intercepter est plus difficile que vous ne le pensez et nécessite des pièces supplémentaires et un niveau de compromis déjà existant qui rendrait probablement l'obtention de ce mot de passe trivial par d'autres moyens.Certes, rien n'est parfait mais c'est un risque calculé.Dans ce cas, le risque est présent, mais faible, à mon humble avis.
@Hollowproc - Pourquoi le téléphone ne serait-il pas une option?Ce serait étrange.
@NicolasBarbulesco bat le FOM, mais c'est ce que l'OP a dit dans les commentaires sous la question: Le contact humain est-il hors de l'équation?- MadWard 23 juin à 11:49 Oui, j'ai oublié de le mentionner en effet.- Wim Deblauwe 23 juin à 11h50
@Hollowproc - Qu'est-ce que le FOM?
F *** outta me .. LOL
@Hollowproc - J'ai compris ce "contact humain" comme une rencontre humaine.Le téléphone est très courant dans les affaires des entreprises.Si le téléphone ne peut vraiment pas être utilisé, alors c'est un problème qui devrait être résolu ou évité en fuyant ce projet cauchemardesque.
@NicolasBarbulesco, J'ai également mes propres opinions sur les détails de la question (donc +1), mais j'ai essayé de rester neutre et j'ai indiqué la question posée.
Bill
2016-06-23 20:19:16 UTC
view on stackexchange narkive permalink

Restez simple, mais utilisez simplement deux formes de communication. Par exemple, dans un e-mail demandant des informations d'identification, demandez-leur de répondre avec un nom d'utilisateur uniquement, puis envoyez un mot de passe temporaire à votre numéro. Dès que possible après avoir obtenu les informations d'identification, changez le mot de passe temporaire en autre chose.

Oui, en théorie, quelqu'un pourrait voir l'e-mail et pirater SS7 pour obtenir le mot de passe, mais s'il peut le faire avant que vous puissiez changer le mot de passe temporaire, vous êtes quand même pwned.

Je ne comprends pas votre dernier paragraphe.Vous devriez peut-être le réécrire.Qu'est-ce que SS7?
@NicolasBarbulesco: google first hit = https://en.wikipedia.org/wiki/Signalling_System_No._7 est un protocole peu sécurisé utilisé dans les systèmes téléphoniques, y compris les systèmes cellulaires / mobiles qui gèrent les messages texte.Par conséquent, piratez SS7 (systèmes) pour obtenir le texte (contenant le mot de passe).
sidewaiise
2016-06-25 06:54:59 UTC
view on stackexchange narkive permalink

Vous ne devriez pas coder en dur les rappels qui répondent à un nom d'utilisateur / mot de passe spécifique. Si vous utilisez des outils tiers, vous devez configurer ces comptes pour eux et interagir avec ces outils via des jetons API. Il est préférable de créer le compte et d'attribuer les informations d'identification du compte au client.

L'OP ne vise pas à stocker le nom d'utilisateur et le mot de passe n'importe où;ils visent à se connecter personnellement afin de configurer les détails techniques dans un panneau de contrôle tiers dans le cadre d'un déploiement d'application.Et la configuration de nouveaux comptes n'est pas toujours une option, car il peut s'agir de comptes payants existants qui nécessitent de nouvelles fonctionnalités.
bortzmeyer
2016-06-27 00:18:22 UTC
view on stackexchange narkive permalink

Étrange que personne n'ait mentionné OAuth, qui, à première vue, est la solution parfaite au problème, tel que reformulé après la mise à jour.

OAuth est une solution qui devrait être déployée par le fournisseur de système tiers;le PO ne recherche pas l'accès à un système qu'il a lui-même conçu.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...