Question:
Comment remédier à la politique de sécurité des mots de passe erronés d'une grande entreprise?
Douglas Gaskell
2017-07-04 01:51:04 UTC
view on stackexchange narkive permalink

Je viens de réinitialiser mon mot de passe Western Digital et ils m'ont envoyé mon mot de passe en texte clair, au lieu de fournir un formulaire en ligne pour me permettre de le modifier. Cela m'inquiète vraiment car le site accepte / traite les paiements pour leurs lecteurs, et j'ai déjà effectué des paiements sur ce site.

En guise de contre-mesure, je considère ce mot de passe utilisé sur ce site comme s'il a déjà été divulgué, et j'assure un nouveau mot de passe unique pour tous les autres sites sur lesquels je l'ai utilisé. Pour être sûr.

Quelle est la meilleure façon de résoudre ce problème de manière à avoir le plus de chances de les encourager à corriger leur politique de mot de passe?

Vous ont-ils envoyé le mot de passe oublié ou un nouveau mot de passe qui vous permet de saisir un formulaire de réinitialisation de mot de passe?Si le premier, c'est un cas pour http://plaintextoffenders.com/, dans le dernier cas, je ne vois rien de peu sûr à ce sujet.
Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (http://chat.stackexchange.com/rooms/61779/discussion-on-question-by-douglas-gaskell-how-to-address-bad-password-security-p).
Pouvez-vous effectuer de nouveaux achats sans ressaisir les détails de votre carte?La possibilité de faire cela rend les sites comme PayPal vraiment sensibles.Un site de commerce électronique typique ne le permet pas ou vous oblige à au moins ressaisir le code de sécurité, ce qui réduit considérablement le risque.Amazon propose une variante intéressante dans laquelle ils vous obligent à saisir à nouveau le code de sécurité de votre carte si vous modifiez l'adresse de livraison.
Cinq réponses:
John Wu
2017-07-04 03:00:45 UTC
view on stackexchange narkive permalink

S'ils traitent les paiements par carte de crédit, ils doivent maintenir la conformité PCI-DSS. Vous pouvez toujours signaler une violation. Ils pourraient potentiellement envoyer un auditeur et insister sur des remédiations. L'ensemble du processus prendrait probablement un an ou plus. Cela ne me surprendrait pas s'ils y travaillent déjà, en supposant que vous ayez trouvé un problème de bonne foi.

Ne devrait-il pas s'agir d'une violation PCI-DSS uniquement si le compte de l'OP a une sorte d'accès aux données du titulaire de carte (ou du moins au système sur lequel il est stocké)?Ce n'est pas parce qu'ils peuvent accepter des paiements via leur site Web que les comptes des clients peuvent accéder de quelque manière que ce soit à ces données (bien sûr, s'ils envoient des mots de passe en clair dans les e-mails, qui sait ce qu'ils font).
[PCI Section 8] (https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf) couvre les mots de passe.Si l'OP peut effectuer un paiement, il peut accéder aux données du titulaire de la carte.
Est-ce que WD doit maintenir la conformité PCI-DSS même s'il utilise Digital River comme société de manutention pour sa boutique en ligne?
@JohnWu Petite stipulation, les sites pourraient utiliser des processeurs de paiement comme Stripe et ne jamais stocker de données de titulaire de carte, ce qui pourrait être presque entièrement transparent pour l'utilisateur final.Mais je doute qu'une entreprise comme WD l'utilise.
La conformité PCI-DSS est toujours en jeu, même avec Digital River, Stripe ou d'autres processeurs tiers.La vitrine aurait simplement un [niveau de conformité, probablement SAQ-A] inférieur (https://www.mwrinfosecurity.com/our-thinking/pci-compliance-which-saq-is-right-for-me/).
Mieux vaut dans un an que jamais.
@JohnWu "Si l'OP peut effectuer un paiement, il peut accéder aux données de titulaire de carte" n'est pas nécessairement vrai - dans de nombreux systèmes de paiement, aucune donnée de titulaire de carte n'est stockée, c'est-à-dire que vous ne pouvez pas accéder aux données de vos propres paiements antérieurs, et donc l'accès à votre compte n'est pasne donnez pas accès à vos données CHD.
La conformité PCI s'applique également aux marchands en ligne, mais pas au niveau d'examen qu'un processeur de paiement pourrait subir.Les processeurs de paiement ont tout intérêt à s'assurer que leurs marchands sont conformes à la norme PCI et factureront des frais supplémentaires lorsqu'ils ne sont pas conformes.
@Peteris: Je sais que vous fendez les cheveux, alors laissez-moi les diviser davantage: en entrant un numéro de carte sur une page Web et en l'utilisant pour effectuer un achat, un utilisateur accède aux données du titulaire de carte.Ces activités sont coordonnées par la vitrine, elle supporte donc également tout risque financier associé à la transaction.Le but de la conformité PCI-DSS est d'atténuer le risque.
@JohnWu oui, dans ce scénario, PCI DSS exigerait de crypter le CHD en transit (par exemple, utilisez https) et aurait d'autres exigences, mais (comme je l'ai dit) la conformité PCI DSS n'exigerait * pas * que l'utilisateur ait un mot de passe de compte sécurisé, enEn fait, il ne nécessite aucun mot de passe pour la personne effectuant le paiement, tant que le CHD n'est pas stocké.La norme PCI DSS détaille les exigences de mot de passe pour les comptes qui peuvent accéder à CHD, mais ces exigences de mot de passe ne s'appliquent à aucun des comptes qu'une organisation pourrait avoir en général et ne s'appliqueraient pas à ce scénario - elles peuvent facilement être conformes.
Heck ouais, je ne suppose pas qu'il y a une violation réelle ici sans rien savoir de leur système.Je pense que mon point principal est qu'un auditeur PCI pourrait encore examiner le système et faire des recommandations.
Chenmunka
2017-07-04 14:29:05 UTC
view on stackexchange narkive permalink

Si une entreprise vous envoie vos informations de connexion sous forme de texte brut, vous pouvez lui en faire honte publiquement, soit la vôtre, soit la nouvelle.

Contrevenants en texte brut que vous pouvez publier leur stupidité en soumettant simplement une capture d'écran de l'e-mail incriminé. Veillez à masquer tous les détails sensibles. C'est un site qui mérite d'être surveillé, afin que vous sachiez quelles entreprises éviter d'utiliser.

J'étais curieux de savoir si PTO fait l'effort d'aviser le contrevenant du problème.Ils ne le confirment pas sur leur site (que je peux voir), mais j'ai trouvé un rapport de bogue sur un contrevenant qui semble indiquer que PTO contactera le contrevenant pour vous.Ainsi, vous auriez probablement * juste * à envoyer le site à PTO, sans essayer de savoir comment contacter l'entreprise vous-même.Mais cela ne fait pas de mal de contacter l'entreprise de toute façon, d'autant plus qu'on ne sait pas si PTO fait toujours cela.
Leur publication la plus récente date de plus d'un an.Le site est-il toujours actif?
Le site semble incertain.J'ai soumis probablement quelques dizaines de sites qui m'ont envoyé mon mot de passe (saisi) après la création d'un compte ou une réinitialisation.Et aucun n'est jamais apparu sur leurs listes.Une alternative devrait être faite ...
Swashbuckler
2017-07-04 02:03:18 UTC
view on stackexchange narkive permalink

Il semble que Western Digital ne dispose pas d'une équipe de sécurité que vous pouvez contacter directement à propos des vulnérabilités. En fait, j'ai trouvé un article sur leur site d'assistance demandant spécifiquement pourquoi il n'y avait pas d'adresse e-mail ou de clé PGP à utiliser pour les vulnérabilités et personne de WD n'a répondu.

Ce que j'ai trouvé, c'est que quelqu'un ont déclaré qu'ils devaient signaler une vulnérabilité et une personne de soutien a répondu qu'il enverrait un message privé à la personne. Je vous suggère de faire de même.

TheJulyPlot
2017-07-04 20:34:02 UTC
view on stackexchange narkive permalink

Je pense que cela relève probablement de la divulgation responsable. Il y a quelques mesures que vous devriez prendre qui ont déjà été mentionnées isolément, mais qui devraient probablement être prises dans le cadre d'une approche holistique du problème.

La première chose à faire est de signaler le problème à l'équipe d'assistance.

Détaillez les étapes à suivre pour reproduire le problème (par exemple, récupérer le mot de passe, recevoir le mot de passe en texte brut) et inclure des informations sur ce que cela révèle sur la façon dont ils gèrent les mots de passe et pourquoi c'est une mauvaise idée.

J'inclurais également des articles sur des problèmes de mijotage dans le passé pour fournir un contexte, par exemple celui-ci sur PlusNet.

Je leur expliquerais que s'ils n'ont pas résolu le problème avec x jours (90 jours coutures raisonnables pour moi) vous avez l'intention de prendre des mesures.

Dites-leur ce qu'est cette action. Par exemple, vous pensez qu'ils traitent des cartes de crédit et que vous avez l'intention de signaler une violation PCI. Expliquez clairement que si le problème n'est pas résolu, vous avez l'intention de le divulguer publiquement. (Article de blog, médias sociaux, en rapportant les médias spécialisés, sites de "honte", etc.)

Il faut se rappeler que même s'ils sont en faute, il leur faudra un certain temps pour mettre en œuvre le changement , (bien que douteux) ils peuvent ne pas se méfier du problème en raison d'un manque d'investissement et / ou de compétences dans l'équipe informatique, alors agissez de bonne foi et donnez-leur un délai raisonnable pour effectuer le changement.

La deuxième chose à faire est de suivre les étapes ci-dessus.

Le problème ici est bien sûr que cette question est passée directement à la divulgation publique.

Compte tenu de cela, j'inclurais un lien vers cette question, car voir un groupe de professionnels de la sécurité discuter du problème aiguillera sans aucun doute l'esprit de l'administrateur système (et si ce n'est pas le cas, Western Digital devrait rechercher un nouvel administrateur système)

Les décisions de conception intentionnelles de la part de l'entreprise fautive exigent-elles vraiment une divulgation responsable?Je trouve très improbable qu'un problème comme celui-ci soit le résultat d'un simple bug.
Qui sait quelle était la raison, décision de conception, négligence, etc. Non, ce n'est pas un bogue accordé, mais c'est un défaut.Personnellement, je ferais preuve de prudence et agirais de bonne foi en le leur signalant et en leur donnant une chance de mettre en œuvre un changement.Ce n'est cependant qu'une vue.
el.pescado
2017-07-05 19:46:10 UTC
view on stackexchange narkive permalink

Les mots de passe en texte clair ne sont pas votre problème (= utilisateur)

Vous devriez considérer le mot de passe comme un secret partagé - c'est-à-dire supposer que vous et WD le savez. Après tout, chaque fois que vous vous connectez à leur site, vous dites "Bonjour, je m'appelle Douglas Gaskell et mon mot de passe est Correct Horse Battery Staple, laissez-moi entrer". Si des méchants piratent leur site, ils n'ont pas besoin de votre mot de passe - ils ont probablement de toute façon accès à vos données. Ashley Madison a haché les mots de passe des utilisateurs, mais ce n'était pas une grande consolation après une violation de données.

Les propriétaires de sites ne devraient pas stocker les mots de passe en texte clair en raison des dangers de réutilisation des mots de passe - mais vous ne devriez pas ne réutilisez pas vos mots de passe en premier lieu. Choisissez des mots de passe forts et uniques pour chaque site . De cette façon, les mots de passe stockés en texte brut ne sont pas vraiment votre problème. Si vous avez réutiliser votre mot de passe WD sur d’autres sites, modifiez-le sur WD et sur tous les autres sites, si possible.

Ne perdez pas votre temps

Les utilisateurs ne peuvent pas contrôler si leurs mots de passe sont hachés ou non. Les grandes entreprises ont des raisons de stocker les mots de passe sous une forme récupérable (ce qui n'implique pas nécessairement du texte en clair), ou prétendent en avoir un ou tout simplement s'en moquent. Leur système de mot de passe est peut-être utilisé par plusieurs services, certains d'entre eux pouvant être des mainframes terriblement hérités. Il est peu probable que vous changiez leur politique de mot de passe.

Au fait

Le stockage du mot de passe sous une forme récupérable n'implique pas de le stocker en texte brut. Il peut être chiffré.

TL; DR: Utilisez des mots de passe forts, ne les réutilisez pas, conservez-les dans un bon gestionnaire de mots de passe, activez l ' Authentification à deux facteurs pour les comptes qui sont précieux pour vous et ne vous inquiétez pas des choses que vous ne pouvez pas contrôler.

"Si des méchants piratent leur site (...), ils ont de toute façon accès à vos données."Non pas forcément.Ils n'ont pas toujours un accès complet.De plus, le mot de passe ne concerne pas uniquement la confidentialité.S'ils peuvent se connecter au site avec votre mot de passe, ils peuvent se faire passer pour vous et agir en votre nom.
S'ils ont accès à la base de données de mots de passe, ils peuvent probablement se faire passer pour vous sans avoir besoin de mot de passe.
@el.pescado pas si les mots de passe sont correctement hachés ....
Si les mots de passe sont stockés en clair, toute personne ayant accès aux mots de passe peut se faire passer pour n'importe qui dans le système, y compris le personnel de l'entreprise.C'est pourquoi vous êtes censé hacher correctement les mots de passe.
@schroeder Je veux dire, oui, vous devriez hacher les mots de passe de vos utilisateurs, mais en théorie, si vous avez accès aux mots de passe, hachés ou non, vous avez accès à toutes les autres données.
@el.pescado Encore une fois, pas nécessairement.Il est possible d'avoir accès aux hachages salés des mots de passe, sans avoir accès à d'autres données.Un scénario est celui où un attaquant divulgue les hachages salés, sans divulguer les autres données qu'il a obtenues.Cela est arrivé.
Je suis d'accord, mais c'est du point de vue de l'administrateur système.La question provient du PDV de l'utilisateur.
Eh bien, supposons que je suis un utilisateur d'un site bancaire.La banque utilise une base de données distincte pour les mots de passe (bonne idée).L'application a une vulnérabilité SQLi, mais uniquement sur la base de données de mots de passe.Si la banque sel et hache correctement, l'attaquant ne peut pas faire grand-chose - le serveur vérifiera le hachage de tout ce qui est envoyé avec la valeur stockée, donc ils ne peuvent pas se connecter en tant que moi ayant simplement le hachage salé.Mon argent est en sécurité (assez).Si la banque les stocke en texte clair, l'attaquant peut simplement se connecter en tant que moi et tout mon argent a disparu (et le récupérer est probablement un long processus juridique pour lequel je n'ai plus d'argent à payer).Problème d'utilisateur.
@Delioth C'est un excellent exemple.C'est pourquoi les systèmes bancaires en ligne utilisent 2FA (du moins ceux avec lesquels j'ai fait affaire).Avec 2FA activé, dans votre scénario, l'attaquant verrait le solde de votre compte (ça craint toujours, je suis d'accord), mais ne pourra pas transférer d'argent n'importe où.Je mettrai à jour ma réponse pour inclure 2FA.
@el.pescado vous pensez qu'une entreprise qui n'a même pas appris à ne pas stocker les mots de passe en clair utilise 2FA?C'est une hypothèse énorme, car les mots de passe en texte brut montrent peu d'attention pour la sécurité ou aucune connaissance des pratiques de sécurité.
+1 pour des conseils pragmatiques qui comprennent correctement les risques.
@Delioth peut dire la même chose de la séparation des mots de passe et d'autres données.Quelles sont les chances que les deux soient séparés, que les mots de passe ne soient ni hachés, ni chiffrés non plus, et n'utilisent aucune autre méthode d'authentification supplémentaire en même temps, et que la base de données de mots de passe soit celle qui est piratée?D'autre part, quelles sont les chances qu'ils commencent à hacher les mots de passe après un e-mail client en colère?BTW.Lorsque la banque fuit des informations d'identification et que de l'argent est volé, la procédure judiciaire ne serait pas difficile, du moins ici en Europe.


ⓘ
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...