Question Comment dois-je aborder de façon éthique le stockage de mot de passe utilisateur pour une récupération ultérieure en texte clair?


Comme je continue à construire de plus en plus de sites Web et d'applications Web, on me demande souvent de stocker les mots de passe des utilisateurs de manière à pouvoir les récupérer si l'utilisateur a un problème (soit pour envoyer un mot de passe oublié, téléphone, etc.) Quand je peux je me bats amèrement contre cette pratique et je fais beaucoup de programmation «supplémentaire» pour faire des réinitialisations de mot de passe et une assistance administrative possible sans stocker leur mot de passe réel.

Quand je ne peux pas le combattre (ou je ne peux pas gagner), je code toujours le mot de passe d'une manière ou d'une autre afin qu'il ne soit pas stocké en clair dans la base de données - mais je sais que si ma base de données est piratée il n'en faudrait pas beaucoup pour que le coupable déchiffre les mots de passe, ce qui me met mal à l'aise.

Dans un monde parfait, les gens mettent fréquemment à jour les mots de passe et ne les dupliquent pas sur plusieurs sites différents. Malheureusement, je connais BEAUCOUP de gens qui ont le même mot de passe travail / domicile / email / banque. Je ne veux pas être responsable de leur disparition financière si les procédures de sécurité de ma base de données échouent pour une raison quelconque.

Moralement et éthiquement, je me sens responsable de protéger ce qui peut être, pour certains utilisateurs, leur gagne-pain, même s'ils le traitent avec beaucoup moins de respect. Je suis certain qu'il y a de nombreuses pistes à aborder et des arguments à faire pour saler les hachages et les différentes options d'encodage, mais y a-t-il une seule «meilleure pratique» quand vous devez les stocker? Dans presque tous les cas, j'utilise PHP et MySQL si cela fait une différence dans la façon dont je devrais gérer les spécificités.

Informations supplémentaires pour Bounty

Je tiens à préciser que je sais que ce n'est pas quelque chose que vous voulez faire et que, dans la plupart des cas, le refus est le meilleur. Cependant, je ne cherche pas une conférence sur les mérites de cette approche. Je suis à la recherche des meilleures mesures à prendre si vous adoptez cette approche.

Dans une note ci-dessous, j'ai fait remarquer que les sites Web destinés en grande partie aux personnes âgées, aux handicapés mentaux ou très jeunes peuvent devenir confus pour les gens lorsqu'on leur demande d'effectuer une routine de récupération de mot de passe sécurisée. Bien que nous puissions trouver cela simple et banal dans certains cas, certains utilisateurs ont besoin de l'aide supplémentaire d'un technicien de service pour les aider à entrer dans le système ou pour l'envoyer directement par e-mail.

Dans de tels systèmes, le taux d'attrition de ces données démographiques pourrait entraver l'application si les utilisateurs ne bénéficiaient pas de ce niveau d'aide à l'accès, alors veuillez répondre en gardant cette configuration à l'esprit.

Merci à tout le monde

Cela a été une question amusante avec beaucoup de débats et j'en ai profité. Au final, j'ai choisi une réponse qui conserve la sécurité par mot de passe (je n'aurai pas besoin de garder un texte clair ou des mots de passe récupérables), mais permet également à la base d'utilisateurs que je spécifie de se connecter à un système sans les inconvénients majeurs récupération de mot de passe normale.

Comme toujours il y avait environ 5 réponses que je voudrais marquer comme correctes pour différentes raisons, mais je devais choisir le meilleur - tout le reste a eu un +1. Merci tout le monde!

Merci également à tous les membres de la communauté Stack qui ont voté pour cette question et / ou l'ont marquée comme favorite. Je prends un total de 100 votes comme un compliment et j'espère que cette discussion a aidé quelqu'un d'autre avec la même préoccupation que moi.


1346
2018-02-17 19:54


origine


Réponses:


Que diriez-vous de prendre une autre approche ou un angle à ce problème? Demandez pourquoi le mot de passe doit être en texte clair: si c'est pour que l'utilisateur puisse récupérer le mot de passe, alors vous n'avez pas vraiment besoin de récupérer le mot de passe qu'ils ont défini (ils ne se souviennent pas de quoi il s'agit) besoin de pouvoir leur donner un mot de passe, ils peut utiliser.

Pensez-y: si l'utilisateur a besoin de récupérer le mot de passe, c'est parce qu'il l'a oublié. Dans ce cas, un nouveau mot de passe est aussi bon que l'ancien. Mais l'un des inconvénients des mécanismes courants de réinitialisation de mot de passe utilisés aujourd'hui est que les mots de passe générés lors d'une opération de réinitialisation sont généralement un ensemble de caractères aléatoires, il est donc difficile pour l'utilisateur de taper correctement à moins de copier-n- coller. Cela peut être un problème pour les utilisateurs d'ordinateurs moins avertis.

Un moyen de contourner ce problème est de fournir des mots de passe générés automatiquement qui sont plus ou moins de texte en langage naturel. Bien que les chaînes de langage naturel n'aient pas l'entropie d'une chaîne de caractères aléatoires de même longueur, rien ne dit que votre mot de passe généré automatiquement doit avoir seulement 8 (ou 10 ou 12) caractères. Obtenez une phrase secrète auto-générée à haute entropie en enchaînant plusieurs mots aléatoires (laissez un espace entre eux, afin qu'ils soient toujours reconnaissables et typables par tous ceux qui peuvent lire). Six mots aléatoires de longueur variable sont probablement plus faciles à taper correctement et avec confiance que 10 caractères aléatoires, et ils peuvent aussi avoir une entropie plus élevée. Par exemple, l'entropie d'un mot de passe de 10 caractères tiré au hasard à partir de majuscules, de minuscules, de chiffres et de 10 symboles de ponctuation (pour un total de 72 symboles valides) aurait une entropie de 61,7 bits. En utilisant un dictionnaire de 7776 mots (comme Diceware utilise) qui pourrait être choisi au hasard pour une phrase secrète de six mots, la phrase secrète aurait une entropie de 77,4 bits. Voir le Diceware FAQ pour plus d'informations.

  • une phrase secrète avec environ 77 bits d'entropie: "admettre la flare table en prose flair"

  • un mot de passe avec environ 74 bits d'entropie: "K: & $ R ^ tt ~ qkD"

Je sais que je préférerais taper la phrase, et avec copier-n-coller, la phrase n'est pas moins facile à utiliser que le mot de passe, donc pas de perte là-bas. Bien sûr, si votre site Web (ou quel que soit l'actif protégé) n'a pas besoin de 77 bits d'entropie pour une phrase secrète générée automatiquement, générez moins de mots (ce que vos utilisateurs apprécieraient sûrement).

Je comprends les arguments selon lesquels il existe des actifs protégés par mot de passe qui n'ont vraiment pas un niveau élevé de valeur, donc la violation d'un mot de passe pourrait ne pas être la fin du monde. Par exemple, je ne m'inquiéterais probablement pas de savoir si 80% des mots de passe que j'ai utilisés sur différents sites Web ont été piratés: tout ce qui pourrait arriver est un spam ou une publication sous mon nom pendant un moment. Ce ne serait pas génial, mais ce n'est pas comme s'ils allaient entrer dans mon compte en banque. Cependant, étant donné que beaucoup de gens utilisent le même mot de passe pour leurs sites de forum Web que pour leurs comptes bancaires (et probablement les bases de données de sécurité nationale), je pense qu'il serait préférable de gérer même les mots de passe de faible valeur. -restaurable.


1039
2018-02-28 08:16



Imaginez quelqu'un a commandé un grand bâtiment à construire - un bar, disons - et la conversation suivante a lieu:

Architecte:  Pour un bâtiment de cette taille et de cette capacité, vous aurez besoin de sorties de secours ici, ici et ici.
Client:  Non, c'est trop compliqué et cher à entretenir, je ne veux pas de portes latérales ou de portes arrière.
Architecte:  Monsieur, les sorties de secours ne sont pas facultatives, elles sont obligatoires selon le code de prévention des incendies de la ville.
Client:  Je ne te paie pas pour discuter. Fais juste ce que j'ai demandé.

Est-ce que l'architecte demande alors comment construire de façon éthique ce bâtiment sans sortie de feu?

Dans l'industrie du bâtiment et de l'ingénierie, la conversation risque le plus de se terminer comme ceci:

Architecte:  Ce bâtiment ne peut pas être construit sans sorties de secours. Vous pouvez aller à n'importe quel autre professionnel agréé et il vous dira la même chose. Je pars maintenant; rappelez-moi quand vous êtes prêt à coopérer.

La programmation informatique ne peut pas être une autorisé profession, mais les gens semblent souvent se demander pourquoi notre profession n'a pas le même respect qu'un ingénieur civil ou mécanique - eh bien, ne cherchez pas plus loin. Ces professions, lorsqu'il est remis aux ordures (ou tout à fait dangereux) des exigences, refusera simplement. Ils savent que ce n'est pas une excuse pour dire: «Eh bien, j'ai fait de mon mieux, mais il a insisté, et je dois faire ce qu'il dit. Ils pourraient perdre leur licence pour cette excuse.

Je ne sais pas si vous ou vos clients font partie d'une société cotée en bourse, mais stocker des mots de passe sous une forme récupérable vous ferait échouer plusieurs types différents d'audits de sécurité. Le problème n'est pas de savoir à quel point il serait difficile pour certains «hackers» ayant accès à votre base de données de récupérer les mots de passe. La grande majorité des menaces de sécurité sont internes.  Ce dont vous avez besoin pour vous protéger, c'est que certains employés mécontents s'éloignent avec tous les mots de passe et les vendent au plus offrant. L'utilisation du cryptage asymétrique et le stockage de la clé privée dans une base de données séparée ne font absolument rien pour empêcher ce scénario; il y aura toujours Quelqu'un avec l'accès à la base de données privée, et c'est un sérieux risque de sécurité.

Il n'existe aucun moyen éthique ou responsable de stocker les mots de passe sous une forme récupérable. Période.


593
2018-02-18 16:05



Vous pouvez crypter le mot de passe + un sel avec une clé publique. Pour les connexions, vérifiez simplement si la valeur stockée est égale à la valeur calculée à partir de l'entrée utilisateur + sel. S'il arrive un moment où le mot de passe doit être restauré en clair, vous pouvez le déchiffrer manuellement ou semi-automatiquement avec la clé privée. La clé privée peut être stockée ailleurs et peut en outre être cryptée symétriquement (ce qui nécessitera une interaction humaine pour décrypter le mot de passe).

Je pense que c'est en quelque sorte similaire à la façon dont le Agent de récupération Windows travaux.

  • Les mots de passe sont stockés cryptés
  • Les gens peuvent se connecter sans déchiffrer en clair
  • Les mots de passe peuvent être récupérés en texte brut, mais uniquement avec une clé privée, qui peut être stockée en dehors du système (dans un coffre-fort de la banque, si vous le souhaitez).

206
2018-02-17 20:07



N'abandonne pas. L'arme que vous pouvez utiliser pour convaincre vos clients est la non-répudiation. Si vous pouvez reconstruire les mots de passe des utilisateurs via n'importe quel mécanisme, vous avez donné leur clients un mécanisme de non-répudiation juridique et ils peuvent répudier toute transaction qui dépend de ce mot de passe, car il est impossible pour le fournisseur de prouver qu'ils n'ont pas reconstruit le mot de passe et de passer la transaction par eux-mêmes. Si les mots de passe sont correctement stockés sous forme de condensé plutôt que de texte chiffré, cela est impossible, le client final exécutant lui-même la transaction ou manquant à son obligation de diligence. le mot de passe. Dans les deux cas, cela laisse carrément la responsabilité de sa responsabilité. J'ai travaillé sur des cas où cela représenterait des centaines de millions de dollars. Pas quelque chose que tu veux te tromper.


134
2018-02-18 09:59



Vous ne pouvez pas stocker de mots de passe éthiquement pour une récupération ultérieure en texte brut. C'est aussi simple que ça. Même Jon Skeet ne peut pas stocker de mots de passe éthiquement pour la récupération de texte en clair plus tard. Si vos utilisateurs peuvent récupérer des mots de passe en texte brut d'une manière ou d'une autre, alors un pirate peut également potentiellement trouver une faille de sécurité dans votre code. Et ce n'est pas seulement le mot de passe d'un utilisateur qui est compromis, mais tous.

Si vos clients ont un problème avec cela, dites-leur que le stockage des mots de passe est contre la loi. Au Royaume-Uni, en tout état de cause, la loi de 1998 sur la protection des données (annexe 1, partie II, paragraphe 9) oblige les responsables du traitement à utiliser les mesures techniques appropriées pour protéger les données personnelles, en tenant compte, entre autres, les dommages qui pourraient être causés si les données étaient compromises - ce qui pourrait être considérable pour les utilisateurs qui partagent des mots de passe entre les sites. S'ils ont encore du mal à comprendre que c'est un problème, montrez-leur des exemples concrets, tels que celui-là.

Le moyen le plus simple pour permettre aux utilisateurs de récupérer un identifiant est de leur envoyer par e-mail un lien unique qui les connecte automatiquement et les redirige directement vers une page où ils peuvent choisir un nouveau mot de passe. Créez un prototype et montrez-le en action à eux.

Voici quelques articles que j'ai écrits sur le sujet:

Mettre à jour: nous commençons maintenant à voir des poursuites et des poursuites contre les entreprises qui ne parviennent pas à sécuriser correctement les mots de passe de leurs utilisateurs. Exemple: LinkedIn a intenté une action en recours collectif de 5 millions de dollars; Sony a reçu une amende de 250 000 £ sur le hack de données PlayStation. Si je me souviens bien, LinkedIn chiffrait en fait les mots de passe de ses utilisateurs, mais le chiffrement utilisé était trop faible pour être efficace.


95
2018-02-23 15:20



Après avoir lu cette partie:

Dans une note ci-dessous, j'ai fait remarquer que   sites Web orientés en grande partie vers la   personnes âgées, handicapées mentales ou très   jeune peut devenir confus pour les gens   quand on leur demande d'effectuer un   routine de récupération de mot de passe sécurisé.   Bien que nous pouvons le trouver simple et   banal dans ces cas, certains utilisateurs ont besoin   l'aide supplémentaire soit d'avoir   un technicien de service les aider dans la   système ou l'avoir envoyé par e-mail   directement à eux.

Dans de tels systèmes, le taux d'attrition   de ces données démographiques pourraient entraver   l'application si les utilisateurs ne sont pas   compte tenu de ce niveau d'aide à l'accès,   alors s'il vous plaît répondre avec une telle configuration   esprit.

Je me demande si l'une de ces exigences exige un système de mot de passe récupérable. Par exemple: Tante Mabel appelle et dit "Votre programme internet ne fonctionne pas, je ne connais pas mon mot de passe". "OK" dit le drone du service à la clientèle "laissez-moi vérifier quelques détails et je vais vous donner un nouveau mot de passe. Lors de votre prochaine connexion, il vous demandera si vous voulez garder ce mot de passe ou le changer pour quelque chose dont vous vous souviendrez plus facilement. "

Ensuite, le système est configuré pour savoir quand un mot de passe a été réinitialisé et afficher un message "Voulez-vous conserver le nouveau mot de passe ou en choisir un nouveau".

Comment est-ce pire pour les moins instruits PC que d'avoir leur ancien mot de passe? Et tandis que la personne de service à la clientèle peut se méfier, la base de données elle-même est beaucoup plus sûre en cas de violation.

Commentez ce qui est mauvais sur ma suggestion et je proposerai une solution qui fait réellement ce que vous vouliez initialement.


55
2018-02-25 11:27



Michael Brooks a été assez bruyant à propos de CWE-257 - le fait que, quelle que soit la méthode que vous utilisez, vous (l'administrateur) pouvez toujours récupérer le mot de passe. Alors qu'en est-il de ces options:

  1. Chiffrer le mot de passe avec quelqu'un d'autre Clé publique - une autorité externe. De cette façon, vous ne pouvez pas le reconstruire personnellement, et l'utilisateur devra se rendre à cette autorité externe et demander à ce que son mot de passe soit récupéré.
  2. Chiffrer le mot de passe à l'aide d'une clé générée à partir d'une deuxième phrase secrète. Faites ce cryptage côté client et ne le transmettez jamais en clair au serveur. Ensuite, pour récupérer, refaites le déchiffrement côté client en re-générant la clé à partir de leur entrée. Certes, cette approche utilise essentiellement un deuxième mot de passe, mais vous pouvez toujours leur dire de l'écrire ou d'utiliser l'ancienne approche de la question de sécurité.

Je pense que 1. est le meilleur choix, car il vous permet de désigner quelqu'un dans l'entreprise du client pour détenir la clé privée. Assurez-vous qu'ils génèrent la clé eux-mêmes, et stockez-la avec des instructions dans un coffre-fort etc. Vous pouvez même ajouter de la sécurité en choisissant de chiffrer et de fournir certains caractères du mot de passe au tiers interne afin qu'ils puissent déchiffrer le mot de passe. il. En fournissant ces caractères à l'utilisateur, ils se souviendront probablement de ce que c'était!


42
2018-02-18 13:56