Comment dois-je aborder le stockage des mots de passe des utilisateurs de manière éthique pour une récupération ultérieure du texte en clair?


1344

Alors que je continue de créer 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 / quand l'utilisateur a un problème (soit pour envoyer par e-mail un lien de mot de passe oublié, parcourez-les via le téléphone, etc.) Quand je peux, je lutte amèrement contre cette pratique et je fais beaucoup de programmation «supplémentaire» pour rendre possible la réinitialisation des mots de passe et l'assistance administrative sans stocker leur mot de passe réel.

Lorsque je ne peux pas le combattre (ou que je ne peux pas gagner), alors je code toujours le mot de passe d'une certaine manière afin qu'il ne soit pas stocké sous forme de texte brut dans la base de données, bien que je sache que si ma base de données est piratée il ne faudrait pas grand-chose au coupable pour déchiffrer les mots de passe, ce qui me met mal à l'aise.

Dans un monde parfait, les gens mettraient à jour leurs mots de passe fréquemment et ne les dupliqueraient pas sur de nombreux sites différents - malheureusement, je connais BEAUCOUP de personnes qui ont le même mot de passe professionnel / personnel / e-mail / bancaire, et me l'ont même donné librement quand ils ont besoin d'aide. Je ne veux pas être le seul responsable de leur disparition financière si mes procédures de sécurité DB é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 existe de nombreuses avenues à aborder et des arguments à faire pour saler les hachages et les différentes options de codage, mais y a-t-il une seule «meilleure pratique» lorsque 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 dois gérer les détails.

Informations complémentaires sur 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 préférable. Cependant, je ne cherche pas une conférence sur les mérites de cette approche. Je recherche les meilleures mesures à prendre si vous adoptez cette approche.

Dans une note ci-dessous, j'ai souligné que les sites Web destinés principalement aux personnes âgées, aux personnes handicapées mentales ou aux très jeunes peuvent devenir déroutants pour les personnes 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'avoir un technicien de service pour les aider dans le système ou de l'avoir envoyé par e-mail / affiché directement pour eux.

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'assistance d'accès, veuillez donc répondre avec une telle configuration à l'esprit.

Merci à tout le monde

Cela a été une question amusante avec beaucoup de débats et je l'ai appréciée. En fin de compte, j'ai sélectionné une réponse qui conserve à la fois la sécurité des mots de passe (je n'aurai pas à conserver du texte brut ou des mots de passe récupérables), mais permet également à la base d'utilisateurs que j'ai spécifiée de se connecter à un système sans les principaux inconvénients que j'ai trouvés dans récupération normale du mot de passe.

Comme toujours, il y avait environ 5 réponses que j'aurais voulu marquer comme correctes pour différentes raisons, mais j'ai dû choisir la meilleure - tout le reste a obtenu 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 100 votes pour complimenter et j'espère que cette discussion a aidé quelqu'un d'autre avec la même préoccupation que moi.


155
Je pense qu'il sait que ce n'est pas bon. Il est toujours à la recherche de la meilleure solution selon les exigences énoncées.
stefanw

33
À la fin de la journée, tout ce que vous ferez sera de mettre en œuvre avec soin une vulnérabilité évitable.
tour le

20
@Michael Brooks - Je veux que vous sachiez que je suis absolument d'accord avec CWE-257 et j'aimerais simplement citer ce mot pour chaque fois qu'on me demande de rendre les mots de passe récupérables en texte clair. Cependant, en réalité, les clients et les utilisateurs sont rarement intéressés par les réglementations NIST et veulent juste que je le fasse de toute façon. 90% du temps, je peux les convaincre du contraire, mais dans ces 10% du temps où je ne peux pas, j'essaie de déterminer la meilleure ligne de conduite - dans ces cas, CWE-257 a des cendres dans ma main (malheureusement).
Shane

81
@AviD: La "faible valeur" du système n'a absolument aucune incidence sur ce problème car les gens réutilisent leurs mots de passe . Pourquoi les gens ne peuvent-ils pas comprendre ce simple fait? Si vous déchiffrez les mots de passe sur certains systèmes de «faible valeur», vous aurez probablement plusieurs mots de passe valides pour d'autres systèmes de «haute valeur».
Aaronaught

20
Un autre point a également été passé sous silence, que je viens de mentionner dans le flux de commentaires à ma réponse: Comment savez-vous que la personne qui demande ces exigences est digne de confiance? Et si l'excuse de "l'utilisabilité" n'est qu'une façade masquant une réelle intention de voler les mots de passe à un moment donné dans le futur? Votre naïveté a peut-être coûté des millions aux clients et aux actionnaires. Combien de fois les experts en sécurité doivent-ils répéter cela avant qu'il ne s'enfonce enfin: les menaces de sécurité les plus courantes et les plus graves sont toujours INTERNE.
Aaronaught

Réponses:


1037

Que diriez-vous de prendre une autre approche ou un autre angle avec ce problème? Demandez pourquoi le mot de passe doit être en clair: si c'est pour que l'utilisateur puisse récupérer le mot de passe, alors à proprement parler, 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 de toute façon), vous doivent être en mesure de leur donner un mot de passe qu'ils peuvent 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 de réinitialisation de mot de passe couramment utilisés aujourd'hui est que les mots de passe générés produits dans une opération de réinitialisation sont généralement un tas de caractères aléatoires, il est donc difficile pour l'utilisateur de simplement taper correctement à moins qu'ils ne copient-n- pâte. Cela peut être un problème pour les utilisateurs d'ordinateurs moins avertis.

Une façon de contourner ce problème est de fournir des mots de passe générés automatiquement qui sont du texte en langage plus ou moins naturel. Bien que les chaînes de langage naturel puissent ne pas avoir l'entropie d'une chaîne de caractères aléatoires de la même longueur, rien ne dit que votre mot de passe généré automatiquement ne doit avoir que 8 (ou 10 ou 12) caractères. Obtenez une phrase de passe 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 savent 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 également 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, minuscules, les chiffres et 10 symboles de ponctuation (pour un total de 72 symboles valides) auraient une entropie de 61,7 bits. En utilisant un dictionnaire de 7776 mots (comme Diceware l'utilise) qui pourrait être sélectionné au hasard pour une phrase de passe de six mots, la phrase de passe aurait une entropie de 77,4 bits. Voir leFAQ Diceware pour plus d'informations.

  • une phrase secrète avec environ 77 bits d'entropie: "admettre la prose flare table aigu 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 le copier-coller, la phrase n'est pas moins facile à utiliser que le mot de passe non plus, 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 de passe générée automatiquement, générez moins de mots (ce que je suis sûr que vos utilisateurs apprécieraient).

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 me soucierais probablement pas si 80% des mots de passe que j'utilise sur divers sites Web ont été violés: tout ce qui pourrait arriver est une personne qui spamme ou poste sous mon nom pendant un certain temps. Ce ne serait pas génial, mais ce n'est pas comme s'ils s'introduiraient sur mon compte bancaire. Cependant, étant donné que de nombreuses personnes utilisent le même mot de passe pour leurs sites de forum Web que pour leurs comptes bancaires (et probablement des bases de données de sécurité nationale), je pense qu'il serait préférable de traiter même ces mots de passe «de faible valeur» comme non -restaurable.


93
+1 pour les mots de passe, qui semblent actuellement offrir le meilleur équilibre entre la force des mots de passe et le rappel des utilisateurs.
Aaronaught

197
Vous pouvez également faire une phrase complète, par exemple, <adjectif> <nom> est <verbe> <adverbe>. Le chat vert saute sauvagement. avoir des listes pour les catégories. avec 1024 choix pour chacun vous avez 40 bits d'entropie.
Dominik Weber

28
+1 pour avoir considéré la réutilisation des mots de passe comme un problème critique pour l'éviter
lurscher

57
"Pensez-y - si l'utilisateur a besoin de récupérer le mot de passe, c'est parce qu'il l'a oublié" - pas nécessairement vrai! Je veux souvent obtenir mon mot de passe parce que je suis sur l'ordinateur portable, et je SAIS que ma machine à la maison a mon mot de passe stocké, ou qu'il est écrit dans un endroit sûr, et je ne veux pas le casser en obtenant un nouveau .
joachim

5
La question la mieux notée sur le nouveau site IT Security SE concerne la validité de ce calcul d'entropie. (Eh bien, techniquement, il s'agit du xkcd lié à @Pieter.)
Pops

592

Imaginez que 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 trop cher à entretenir, je ne veux pas de portes latérales ou arrière.
Architecte: Monsieur, les sorties de secours ne sont pas facultatives, elles sont requises conformément au code de prévention des incendies de la ville.
Client: Je ne vous paie pas pour discuter. Faites ce que je vous ai demandé.

L'architecte demande-t-il alors comment construire éthiquement ce bâtiment sans issues de secours?

Dans l'industrie du bâtiment et de l'ingénierie, la conversation se terminera probablement comme suit:

Architecte: Ce bâtiment ne peut pas être construit sans sorties de secours. Vous pouvez vous adresser à tout autre professionnel agréé et il vous dira la même chose. Je pars maintenant; rappelez-moi lorsque vous serez prêt à coopérer.

La programmation informatique n'est peut-être pas une profession sous licence , mais les gens semblent souvent se demander pourquoi notre profession n'obtient pas le même respect qu'un ingénieur civil ou mécanicien - eh bien, ne cherchez pas plus loin. Ces professions, lorsqu'on leur remettra des ordures (ou des conditions carrément dangereuses), refuseront tout 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 faites partie d'une société cotée en bourse, mais le stockage des mots de passe sous une forme récupérable vous ferait échouer plusieurs types d'audits de sécurité différents. Le problème n'est pas de savoir à quel point il serait difficile pour un "pirate" 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. Vous devez vous protéger contre un employé mécontent qui marche avec tous les mots de passe et les vend au plus offrant. L'utilisation d'un chiffrement asymétrique et le stockage de la clé privée dans une base de données distincte ne font absolument rien pour empêcher ce scénario; il y aura toujours quelqu'un qui aura accès à la base de données privée, et c'est un grave risque pour la sécurité.

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


124
@Aaronaught - Je pense que c'est un point juste et valable, mais permettez-moi de vous le dire. Vous travaillez sur un projet pour une entreprise en tant qu'employé et votre patron dit «c'est une exigence de notre système» (pour une raison quelconque). Quittez-vous le travail plein d'indignation juste? Je sais qu'il y a une obligation quand je suis en plein contrôle d'être responsable - mais si une entreprise choisit de risquer l'échec des audits ou de la responsabilité, alors est-il de mon devoir de sacrifier mon travail pour prouver un point, ou est-ce que je cherche le MEILLEUR et le moyen le plus SÛR de faire ce qu'ils disent? Je joue juste l'avocat du diable ..
Shane

44
Je ne suis pas avocat, mais réfléchissez. Si votre supérieur hiérarchique vous ordonne de faire quelque chose contre les intérêts de l'entreprise, par exemple en les exposant à une responsabilité facilement évitée, est-ce votre travail d'obéir ou de refuser poliment? Oui, c'est votre patron, mais ils ont leur propre patron, même si ce sont les investisseurs. Si vous ne dépassez pas leurs têtes, dont la tête va rouler lorsque votre trou de sécurité est exploité? Juste quelque chose à considérer.
Steven Sudit

68
Les développeurs essaient toujours de dire à quel point nos travaux sont tellement plus difficiles que d'autres parce que nous avons des exigences en matière de déchets qui changent tout le temps. Eh bien, c'est un parfait exemple de pourquoi; notre profession a désespérément besoin d'une colonne vertébrale. Notre profession doit désespérément pouvoir dire "non, ce n'est pas une exigence acceptable, ce n'est pas quelque chose que je peux développer de bonne foi, vous pouvez être mon client / employeur mais j'ai des responsabilités professionnelles envers vos clients et le public, et si vous voulez que cela soit fait, vous devrez chercher ailleurs. "
Aaronaught

36
@sfussenegger: Vous n'avez pas besoin de connaître l'arrière-plan. C'est inacceptable. Vous supposez que le client est digne de confiance à 100% - que se passe-t-il s'il demande spécifiquement cette exigence afin de pouvoir s'en sortir plus tard avec les mots de passe? La sécurité est l'un des rares éléments en développement qui sont sculptés dans la pierre. Il y a certaines choses que vous ne faites pas, et le stockage de mots de passe récupérables en est dix.
Aaronaught

37
OK, faisons une évaluation des risques, ici et maintenant. "Si vous stockez des mots de passe sous une forme récupérable, vous créez un risque non négligeable de vol de mots de passe. Il est également probable qu'au moins certains utilisateurs utiliseront les mêmes mots de passe pour leurs e-mails et comptes bancaires. Si des mots de passe sont volés et les comptes bancaires sont vidés, cela fera probablement les gros titres, personne ne fera plus jamais affaire avec vous, et vous serez probablement poursuivi en justice. " Pouvons-nous couper la merde maintenant? Le fait que vous ayez introduit le mot «nazis» dans cela montre clairement que vous n'avez aucun sens de la raison.
Aaronaught

206

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, lorsque le mot de passe doit être restauré en texte brut, vous pouvez décrypter manuellement ou semi-automatiquement avec la clé privée. La clé privée peut être stockée ailleurs et peut en outre être chiffrée symétriquement (ce qui nécessitera alors une interaction humaine pour déchiffrer le mot de passe).

Je pense que c'est en fait un peu similaire à la façon dont fonctionne l' agent de récupération Windows .

  • Les mots de passe sont stockés cryptés
  • Les gens peuvent se connecter sans décrypter en texte 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 bancaire, si vous le souhaitez).

34
-1 les mots de passe ne doivent jamais être "cryptés" C'est une violation de CWE-257 cwe.mitre.org/data/definitions/257.html
tour

100
1. La question indiquait que le mot de passe devrait être récupérable en texte clair, c'est donc une exigence. 2. J'utilise ici un cryptage asymétrique et non un cryptage symétrique. La clé à décrypter n'est pas nécessaire pour les opérations quotidiennes et peut être conservée dans un coffre-fort bancaire. L'argumentation dans le lien est valide, mais ne s'applique pas à cette situation.
stefanw

57
Certes, mais pourriez-vous convenir que, compte tenu des exigences, c'est la façon la plus responsable de le faire? Vous pouvez me frapper toute la journée avec votre CWE-257, cela ne changera pas le problème intéressant de stocker et de travailler en toute sécurité avec les informations d'identification et de pouvoir les récupérer dans leur forme d'origine si nécessaire.
stefanw

10
L'agent de récupération Windows est également un mauvais exemple ici, car il traite du chiffrement réel, pas de la gestion des mots de passe. Une clé de chiffrement n'est pas la même chose qu'un mot de passe; les règles et les pratiques qui les entourent sont complètement différentes. Le cryptage et l'authentification ne sont pas identiques. Le cryptage est pour la confidentialité - une clé est utilisée pour protéger les données . L'authentification est pour l' identité , où la clé est les données (c'est un facteur dans le processus d'authentification). Donc je le répète, le cryptage et l'authentification ne sont pas les mêmes. Vous ne pouvez pas valablement appliquer les principes de l'un à l'autre.
Aaronaught

16
+1 À quoi bon insister obsessionnellement sur CWE-257? C'est une faiblesse (CWE), pas une vulnérabilité (CVE). Comparer des mots de passe récupérables avec des débordements de tampon, c'est comparer des pommes et des oranges. Assurez-vous simplement que le client comprend le problème (laissez-le signer quelque chose qui le dit - sinon il ne se souviendra de rien s'il est en question) et allez-y. De plus, les mesures de sécurité requises dépendent de la valeur du système et du risque potentiel d'attaque. Si un attaquant réussi ne pouvait annuler que certains abonnements à la newsletter, il n'y a aucune raison de discuter de tout problème.
sfussenegger

133

N'abandonnez pas. L'arme que vous pouvez utiliser pour convaincre vos clients est la non-répudiabilité. Si vous pouvez reconstruire les mots de passe des utilisateurs via n'importe quel mécanisme, vous avez donné à leurs clients un mécanisme légal de non-répudiation et ils peuvent répudier toute transaction qui dépend de ce mot de passe, car il n'y a aucun moyen pour le fournisseur de prouver qu'il n'a pas reconstruit le mot de passe et mettre la transaction à travers eux-mêmes. Si les mots de passe sont correctement stockés sous forme de résumés plutôt que de texte chiffré, cela est impossible, ergo soit le client final a exécuté la transaction lui-même, soit a violé son obligation de diligence avec le mot de passe. Dans les deux cas, cela lui laisse entièrement la responsabilité. J'ai travaillé sur des cas où cela représenterait des centaines de millions de dollars. Pas quelque chose que vous voulez vous tromper.


2
Les journaux de serveur Web ne comptent pas dans un tribunal? Ou dans ce cas, ils seraient également supposés être truqués?
Vinko Vrsalovic

10
@Vinko Vrsalovic, les journaux de serveur Web DEVRAIENT compter en cour, pour ce faire, vous devez prouver la non-répudiation, la preuve d'authenticité, la chaîne de preuves, etc., quels journaux de serveur Web ne sont clairement pas.
AviD

7
Exactement. Le fournisseur doit prouver que seul le client aurait pu effectuer cette transaction. Un journal de serveur Web ne fait pas cela.
Marquis de Lorne

Tous les mots de passe ne sont pas nécessaires pour les "transactions", pour ainsi dire. Supposons que le site Web sert à développer une liste de signets de pages Web. Dans ce cas, la limite de responsabilité (qui est généralement indiquée dans les CGU lors de l'inscription sur le site) est nulle, car il n'y a pas de transaction financière. Si le site Web n'a aucune action affectant les autres, tout au plus, les données sont perdues pour l'utilisateur piraté. L'entreprise est protégée par les CGU.
Sablefoste

1
@Sablefoste Sur ce site Web. Si l'utilisateur utilise le même mot de passe ailleurs, vous créez un risque de fuite de ses informations d'identification privées. Si vous ne vous engagez jamais dans la pratique, vous ne pouvez pas causer le problème.
Marquis de Lorne

94

Vous ne pouvez pas stocker de façon éthique les mots de passe pour une récupération ultérieure de texte en clair. C'est aussi simple que ça. Même Jon Skeet ne peut pas éthiquement stocker les mots de passe pour une récupération ultérieure en texte brut. Si vos utilisateurs peuvent récupérer les mots de passe en texte brut d'une manière ou d'une autre, un pirate qui trouve une faille de sécurité dans votre code le peut aussi. 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 de mots de passe récupérable est contraire à la loi. Ici au Royaume-Uni en tout cas, la loi sur la protection des données de 1998 (en particulier, l'annexe 1, partie II, paragraphe 9) oblige les responsables du traitement à utiliser les mesures techniques appropriées pour assurer la sécurité des données personnelles, en tenant compte, entre autres, de la 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 à cerner le problème, signalez-leur des exemples concrets, comme celui-ci .

Le moyen le plus simple de permettre aux utilisateurs de récupérer une connexion est de leur envoyer par e-mail un lien unique qui les connecte automatiquement et les amène directement sur une page où ils peuvent choisir un nouveau mot de passe. Créez un prototype et montrez-le-lui en action.

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

Mise à 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 giflé avec un recours collectif de 5 millions de dollars ; Sony a reçu une amende de 250 000 £ pour piratage de données PlayStation . Si je me souviens bien, LinkedIn chiffrait en fait les mots de passe de ses utilisateurs, mais le chiffrement qu'il utilisait était trop faible pour être efficace.


8
@jimmycakes - C'est une bonne chose à faire sur un système à faible sécurité, mais si vous stockez des données de grande valeur, vous devez supposer que l'e-mail des personnes est déjà compromis et que leur envoyer un lien de connexion directe compromet votre système. +1 pour avoir répondu à ma question avec une alternative possible, mais en soulignant une faille dans la logique dans son ensemble. Je ne veux pas que Payppal envoie un lien de connexion directe JAMAIS. Cela peut sembler paranoïaque, mais je suppose toujours que mon compte de messagerie est corrompu - cela me garde honnête. ;)
Shane

Absolument - je m'attends à ce que ma banque me donne au moins un appel téléphonique et vérifie mon identité avant de me laisser réinitialiser ( pas récupérer) mon mot de passe. Ce que j'ai décrit ici est la norme minimale absolue de sécurité par mot de passe que j'attendrais de n'importe quel site Web, n'importe où.
jammycakes

1
Ignorer la banque ou paypal qui n'aurait pas la restriction que vous avez définie de toute façon; Si vous supposez que leur e-mail est compromis, comment une méthode en ligne est-elle possible? Si vous envoyez un mot de passe généré par e-mail, comment cela est-il plus sûr?
Peter Coulton

Je ne parle pas d'obtenir le mot de passe d'un seul individu, je parle d'obtenir plusieurs mots de passe à partir d'une base de données. Si un système stocke les mots de passe de manière récupérable en texte brut, un pirate peut potentiellement écrire un script pour extraire tous les mots de passe de votre base de données.
jammycakes

Je me demande d'envoyer un lien / mot de passe par e-mail, de passer par un réseau en clair via des nœuds de réseau inconnus ...
Jakub

55

Après avoir lu cette partie:

Dans une note ci-dessous, j'ai souligné que les sites Web destinés principalement aux personnes âgées, aux personnes handicapées mentales ou aux très jeunes peuvent devenir déroutants pour les personnes 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'avoir un technicien de service pour les aider dans le système ou de l'avoir envoyé par e-mail / affiché directement pour eux.

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'assistance d'accès, veuillez donc répondre avec une telle configuration à l'esprit.

Je me demande si l'une de ces exigences rend obligatoire 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 client "laissez-moi vérifier quelques détails puis je vous donnerai un nouveau mot de passe . Lors de votre prochaine connexion, il vous demandera si vous souhaitez conserver ce mot de passe ou le changer en quelque chose dont vous vous souviendrez plus facilement."

Ensuite, le système est configuré pour savoir quand une réinitialisation du mot de passe s'est produite 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 sur PC que de se faire dire leur ancien mot de passe? Et tandis que la personne du service client peut se mettre à mal, la base de données elle-même est beaucoup plus sécurisée 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.


4
@john - Je pense que c'est une solution parfaitement viable. Préparez-vous à être flambé par les menaces internes! Vous savez, si je le faisais avec une réinitialisation de mot de passe intermédiaire (le technicien définit manuellement le mot de passe comme une mesure temporaire et indique à Mabel de taper 1234 comme mot de passe), cela fonctionnerait probablement bien sur un système ne contenant pas de données importantes. S'il s'agissait d'un environnement de haute sécurité, nous avons alors un problème où le service client peut définir le mot de passe du PDG sur 1234 et se connecter directement. Il n'y a pas de solution parfaite mais celle-ci fonctionne dans de nombreux cas. (+1)
Shane

5
Je viens de remarquer cette réponse. @Shane, je ne comprends pas pourquoi vous avez prédit une flambée de "menaces internes". La possibilité de changer un mot de passe n'est pas une faiblesse notable; le problème est la possibilité de découvrir un mot de passe susceptible d'être utilisé pour d' autres services - son e-mail, sa banque, ses sites d'achat en ligne qui stockent ses informations CC. Cette faiblesse ne se manifeste pas ici; si Bob réinitialise le mot de passe de Mabel et le lui dit par téléphone, cela ne lui donne accès à aucun de ses autres comptes. Cependant, je forcerais plutôt que de «suggérer» une réinitialisation du mot de passe lors de la connexion.
Aaronaught

@Aaronaught - Je vois votre point, mais je pense à des moments où même les gens du service client sont exclus de certaines zones d'un système (comme la paie, la comptabilité, etc.) et leur permettant de définir directement un mot de passe est un problème de sécurité en soi. Je vois cependant votre argument selon lequel le type de système sur lequel j'ai posé cette question diffère largement d'un système de comptabilité interne. Nous pourrions probablement avoir une discussion entièrement différente sur les systèmes internes propriétaires et la sécurité des mots de passe.
Shane

1
@Shane: Alors la question a encore moins de sens. J'ai supposé que vous vouliez que quelqu'un leur lise un mot de passe par téléphone. Si vous souhaitez envoyer aux utilisateurs leurs mots de passe par e-mail via un système de libre-service automatisé, vous pouvez tout aussi bien vous dispenser du mot de passe, car il est «protégé» par quelque chose de beaucoup plus faible. Vous devez peut-être être beaucoup plus précis sur le type de scénarios d'utilisation que vous essayez de prendre en charge. Peut-être que cette analyse vous montrera par la suite que les mots de passe récupérables ne sont même pas nécessaires.
Aaronaught

4
Le code fourni par la personne de support ne doit pas être littéralement le nouveau mot de passe. Il peut simplement s'agir d'un code à usage unique qui déverrouille la fonction de réinitialisation du mot de passe.
kgilpin

42

Michael Brooks a été assez bruyant sur 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 que diriez-vous de ces options:

  1. Chiffrez le mot de passe avec la clé publique de quelqu'un d'autre - une autorité externe. De cette façon, vous ne pouvez pas le reconstruire personnellement, et l'utilisateur devra s'adresser à cette autorité externe et demander à ce que son mot de passe soit récupéré.
  2. Chiffrez le mot de passe à l'aide d'une clé générée à partir d'une deuxième phrase secrète. Effectuez ce chiffrement côté client et ne le transmettez jamais en clair au serveur. Ensuite, pour récupérer, recommencez le déchiffrement côté client en regé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 utiliser l'ancienne approche des questions de sécurité.

Je pense que 1. est le meilleur choix, car il vous permet de désigner une personne au sein de l'entreprise du client pour détenir la clé privée. Assurez-vous qu'ils génèrent eux-mêmes la clé et stockez-la avec des instructions dans un coffre-fort, etc. il. En fournissant ces caractères à l'utilisateur, ils se souviendront probablement de ce que c'était!


8
Et, bien sûr, vous pouvez utiliser n'importe quelle technique de partage de secret pour exiger plusieurs personnes de votre entreprise pour le décryptage. Mais rien de tout cela ne remplit les exigences initiales de pouvoir envoyer un mot de passe à un utilisateur ou de demander à un supporter de premier niveau du téléphone de le
guider

27

Il y a eu beaucoup de discussions sur les problèmes de sécurité de l'utilisateur en réponse à cette question, mais j'aimerais ajouter une mention des avantages. Jusqu'à présent, je n'ai vu aucun avantage légitime mentionné pour avoir un mot de passe récupérable stocké sur le système. Considère ceci:

  • L'utilisateur a-t-il avantage à recevoir son mot de passe par e-mail? Non. Ils bénéficient davantage d'un lien de réinitialisation de mot de passe à usage unique, qui devrait leur permettre de choisir un mot de passe dont ils se souviendront.
  • L'utilisateur a-t-il avantage à voir son mot de passe affiché à l'écran? Non, pour la même raison que ci-dessus; ils doivent choisir un nouveau mot de passe.
  • L'utilisateur a-t-il avantage à ce qu'une personne de support lui dise le mot de passe? Non; encore une fois, si la personne de soutien considère que la demande de l'utilisateur pour son mot de passe est correctement authentifiée, il est plus avantageux pour l'utilisateur de se voir attribuer un nouveau mot de passe et la possibilité de le changer. De plus, l'assistance téléphonique est plus coûteuse que la réinitialisation automatique des mots de passe, de sorte que l'entreprise n'en profite pas non plus.

Il semble que les seuls qui puissent bénéficier de mots de passe récupérables sont ceux qui ont une intention malveillante ou qui soutiennent des API médiocres qui nécessitent un échange de mots de passe tiers (veuillez ne jamais utiliser lesdites API!). Peut-être pouvez-vous gagner votre argument en déclarant sincèrement à vos clients que l'entreprise ne gagne aucun avantage et seulement des responsabilités en stockant des mots de passe récupérables .

En lisant entre les lignes de ces types de demandes, vous verrez que vos clients ne comprennent probablement pas ou ne se soucient même pas du tout de la façon dont les mots de passe sont gérés. Ce qu'ils veulent vraiment, c'est un système d'authentification qui ne soit pas si difficile pour leurs utilisateurs. Donc, en plus de leur dire qu'ils ne veulent pas réellement de mots de passe récupérables, vous devez leur proposer des moyens de rendre le processus d'authentification moins pénible, surtout si vous n'avez pas besoin des niveaux de sécurité élevés d'une banque, par exemple:

  • Autorisez l'utilisateur à utiliser son adresse e-mail pour son nom d'utilisateur. J'ai vu d'innombrables cas où l'utilisateur oublie son nom d'utilisateur, mais peu oublient son adresse e-mail.
  • Offrez OpenID et laissez un tiers payer les frais d'oubli de l'utilisateur.
  • Soulagez les restrictions de mot de passe. Je suis sûr que nous avons tous été extrêmement ennuyés lorsqu'un site Web n'autorise pas votre mot de passe préféré en raison d'exigences inutiles comme «vous ne pouvez pas utiliser de caractères spéciaux» ou «votre mot de passe est trop long» ou «votre mot de passe doit commencer avec une lettre. " En outre, si la facilité d'utilisation est plus importante que la force des mots de passe, vous pouvez même assouplir les exigences non stupides en autorisant des mots de passe plus courts ou en ne nécessitant pas un mélange de classes de caractères. Avec des restrictions assouplies, les utilisateurs seront plus susceptibles d'utiliser un mot de passe qu'ils n'oublieront pas.
  • N'expire pas les mots de passe.
  • Autorisez l'utilisateur à réutiliser un ancien mot de passe.
  • Autorisez l'utilisateur à choisir sa propre question de réinitialisation de mot de passe.

Mais si vous, pour une raison quelconque (et dites-nous la raison) , vous avez vraiment, vraiment, vraiment besoin d'avoir un mot de passe récupérable, vous pouvez empêcher l'utilisateur de compromettre potentiellement ses autres comptes en ligne en lui donnant un non-mot de passe- système d'authentification basé. Parce que les gens connaissent déjà les systèmes de nom d'utilisateur / mot de passe et qu'ils sont une solution bien exercée, ce serait un dernier recours, mais il y a sûrement beaucoup d'alternatives créatives aux mots de passe:

  • Laissez l'utilisateur choisir une broche numérique, de préférence pas à 4 chiffres, et de préférence uniquement si les tentatives de force brute sont protégées contre.
  • Demandez à l'utilisateur de choisir une question avec une réponse courte à laquelle lui seul connaît la réponse, ne changera jamais, il se souviendra toujours et cela ne dérange pas les autres de le découvrir.
  • Demandez à l'utilisateur d'entrer un nom d'utilisateur, puis dessinez une forme facile à retenir avec suffisamment de permutations pour vous protéger contre les devinettes (voir cette astucieuse photo de la façon dont le G1 le fait pour déverrouiller le téléphone).
  • Pour un site Web pour enfants, vous pouvez générer automatiquement une créature floue en fonction du nom d'utilisateur (un peu comme un identicon) et demander à l'utilisateur de donner à la créature un nom secret. Ils peuvent ensuite être invités à entrer le nom secret de la créature pour se connecter.

J'ai répondu aux commentaires ici, dans ma réponse, car ils étaient assez longs - je pense qu'il est important de revoir l'analyse et la discussion des questions soulevées. stackoverflow.com/questions/2283937/…
AviD

L'utilisateur a-t-il avantage à voir son mot de passe affiché à l'écran? À mon avis - certainement oui! Chaque fois que je reçois un mot de passe obscur sur Internet, je remercie Apple de pouvoir le rendre visible, je n'ai donc pas à le retaper 100 fois dans la douleur. Je peux imaginer comment une personne handicapée se sentirait.
Dmitri Zaitsev

1
Pourquoi est-il préférable d'afficher un mot de passe obscur que de vous laisser choisir un nouveau mot de passe dont vous vous souviendrez?
Jacob

@Jacob: Plus d'entropie?
Alexander Shcheblikin

25

Suite au commentaire que j'ai fait sur la question:
Un point important a été très passé sous silence par presque tout le monde ... Ma réaction initiale était très similaire à @Michael Brooks, jusqu'à ce que je réalise, comme @stefanw, que le problème ici est des exigences brisées , mais ce sont ce qu'ils sont.
Mais alors, il m'est venu à l'esprit que ce n'était peut-être même pas le cas! Le point manquant ici, c'est la valeur tacite des actifs de l'application. En termes simples, pour un système de faible valeur, un mécanisme d'authentification entièrement sécurisé, avec tout le processus impliqué, serait exagéré et le mauvais choix de sécurité.
De toute évidence, pour une banque, les "meilleures pratiques" sont indispensables, et il n'y a aucun moyen de violer éthiquement CWE-257. Mais il est facile de penser à des systèmes de faible valeur où cela n'en vaut pas la peine (mais un simple mot de passe est toujours requis).

Il est important de se rappeler que la véritable expertise en matière de sécurité consiste à trouver des compromis appropriés, PAS à diffuser de manière dogmatique les «meilleures pratiques» que tout le monde peut lire en ligne.

En tant que tel, je suggère une autre solution: en
fonction de la valeur du système, et UNIQUEMENT SI le système est de faible valeur appropriée sans actif "coûteux" (l'identité elle-même, incluse), ET il existe des exigences commerciales valides qui rendent le processus approprié impossible (ou suffisamment difficile / cher), ET le client est mis au courant de toutes les mises en garde ...
Ensuite, il pourrait être approprié de simplement autoriser le chiffrement réversible, sans cerceaux spéciaux pour passer à travers.
J'arrête juste de dire de ne pas se soucier du chiffrement, car il est très simple / bon marché à mettre en œuvre (même en tenant compte de la gestion des clés passibles), et il fournit une certaine protection (plus que le coût de sa mise en œuvre). En outre, il vaut la peine de voir comment fournir à l'utilisateur le mot de passe d'origine, que ce soit par e-mail, en affichant sur l'écran, etc.
Étant donné que l'hypothèse ici est que la valeur du mot de passe volé (même globalement) est assez faible, ces solutions peuvent être valables.


Puisqu'il y a une discussion animée en cours, en fait PLUSIEURS discussions animées, dans les différents messages et fils de commentaires séparés, j'ajouterai quelques clarifications et répondrai à certains des très bons points qui ont été soulevés ailleurs ici.

Pour commencer, je pense qu'il est clair pour tout le monde ici que permettre la récupération du mot de passe d'origine de l'utilisateur est une mauvaise pratique et généralement pas une bonne idée. Ce n'est pas du tout contesté ...
De plus, je soulignerai que dans de nombreuses situations, voire PLUS - c'est vraiment faux, même répugnant, méchant ET laid .

Cependant, le nœud de la question est autour du principe , Y a-t-il une situation où il ne serait pas nécessaire d'interdire cela, et si oui, comment le faire de la manière la plus correcte appropriée à la situation .

Maintenant, comme @Thomas, @sfussenegger et quelques autres l'ont mentionné, la seule façon appropriée de répondre à cette question est de faire une analyse approfondie des risques de toute situation donnée (ou hypothétique), pour comprendre ce qui est en jeu, combien il vaut la peine de protéger et quelles autres mesures d'atténuation sont en jeu pour assurer cette protection.
Non, ce n'est PAS un mot à la mode, c'est l'un des outils de base les plus importants pour un professionnel de la sécurité en direct. Les meilleures pratiques sont bonnes jusqu'à un certain point (généralement comme lignes directrices pour les inexpérimentés et les hacks), après quoi une analyse réfléchie des risques prend le relais.

Vous savez, c'est drôle - je me considérais toujours comme l'un des fanatiques de la sécurité, et je suis en quelque sorte du côté opposé de ces soi-disant "experts en sécurité" ... Eh bien, la vérité est - parce que je suis un fanatique, et un véritable expert de la sécurité dans la vie réelle - je ne crois pas à faire jaillir le dogme des "meilleures pratiques" (ou CWE) SANS cette analyse des risques très importante .
"Méfiez-vous des fanatiques de la sécurité qui appliquent rapidement tout ce qui se trouve dans leur ceinture à outils sans savoir contre quel problème réel ils se battent. Plus de sécurité n'équivaut pas nécessairement à une bonne sécurité."
L'analyse des risques, et les vrais fanatiques de la sécurité, indiqueraient un compromis plus intelligent, basé sur la valeur / le risque, basé sur le risque, la perte potentielle, les menaces possibles, les atténuations complémentaires, etc. base de leurs recommandations, ou soutiennent des compromis logiques, mais préféreraient plutôt lancer des dogmes et des CWE sans même comprendre comment effectuer une analyse des risques, ne sont que des hacks de sécurité, et leur expertise ne vaut pas le papier toilette sur lequel ils l'ont imprimé.

En effet, c'est ainsi que nous obtenons le ridicule qu'est la sécurité aéroportuaire.

Mais avant de parler des compromis à faire dans CETTE SITUATION, examinons les risques apparents (apparents, car nous n'avons pas toutes les informations de base sur cette situation, nous émettons tous des hypothèses - car la question est de savoir quelle hypothèse il peut y avoir une situation ...)
Supposons un système de FAIBLE VALEUR, mais pas si trival que son accès public - le propriétaire du système veut empêcher une usurpation d'identité occasionnelle, mais une sécurité "élevée" n'est pas aussi primordiale que la facilité d'utilisation. (Oui, c'est un compromis légitime pour ACCEPTER le risque que n'importe quel script-kiddie compétent puisse pirater le site ... Attendez, APT n'est-il pas en vogue maintenant ...?)
Par exemple, disons que j'organise un site simple pour une grande réunion de famille, permettant à tout le monde de réfléchir sur où nous voulons aller en camping cette année. Je suis moins inquiet à propos d'un pirate anonyme, ou même du cousin Fred qui se faufile dans des suggestions répétées pour retourner au lac Wantanamanabikiliki, car je suis d'avis que tante Erma ne peut pas se connecter lorsqu'elle en a besoin. Maintenant, tante Erma, en tant que physicienne nucléaire, n'est pas très douée pour se souvenir des mots de passe, ni même pour utiliser des ordinateurs ... Je veux donc supprimer toutes les frictions possibles pour elle. Encore une fois, je ne suis PAS inquiet des hacks, je ne veux tout simplement pas d'erreurs idiotes de mauvaise connexion - je veux savoir qui vient et ce qu'ils veulent.

En tous cas.
Alors, quels sont nos principaux risques ici, si nous chiffrons symétriquement les mots de passe, au lieu d'utiliser un hachage unidirectionnel?

  • Usurper l'identité des utilisateurs? Non, j'ai déjà accepté ce risque, pas intéressant.
  • Administrateur maléfique? Eh bien, peut-être ... Mais encore une fois, je me fiche que quelqu'un puisse usurper l'identité d'un autre utilisateur, INTERNE ou non ... et de toute façon, un administrateur malveillant obtiendra votre mot de passe, peu importe quoi - si votre administrateur a mal tourné, son jeu de toute façon.
  • Un autre problème qui a été soulevé est que l'identité est en fait partagée entre plusieurs systèmes. Ah! Il s'agit d'un risque très intéressant qui nécessite un examen plus approfondi.
    Permettez-moi de commencer par affirmer que ce n'est pas l' identité réelle qui est partagée, mais plutôt la preuve ou les informations d'authentification. D'accord, car un mot de passe partagé me permettra effectivement d'accéder à un autre système (disons, mon compte bancaire ou gmail), c'est effectivement la même identité, donc c'est juste de la sémantique ... Sauf que ce n'est pas le cas . L'identité est gérée séparément par chaque système, dans ce scénario (bien qu'il puisse y avoir des systèmes d'identification tiers, tels que OAuth - toujours, son distinct de l'identité dans ce système - plus à ce sujet plus tard).
    En tant que tel, le principal point de risque ici est que l'utilisateur saisira volontairement son (même) mot de passe dans plusieurs systèmes différents - et maintenant, moi (l'administrateur) ou tout autre pirate de mon site aura accès aux mots de passe de tante Erma pour le site des missiles nucléaires.

Hmmm.

Vous semble-t-il quelque chose ici?

Cela devrait.

Commençons par le fait que la protection du système de missiles nucléaires n'est pas de ma responsabilité , je suis en train de construire un site de sortie pour la famille Frakkin (pour MA famille). Alors, à qui revient la responsabilité? Umm ... Et le système de missiles nucléaires? Duh.
Deuxièmement, si je voulais voler le mot de passe de quelqu'un (quelqu'un connu pour utiliser à plusieurs reprises le même mot de passe entre des sites sécurisés et des sites moins sécurisés) - pourquoi devrais-je prendre la peine de pirater votre site? Ou aux prises avec votre cryptage symétrique? Goshdarnitall, je peux simplement créer mon propre site Web simple , demander aux utilisateurs de s'inscrire pour recevoir des NOUVELLES TRÈS IMPORTANTES sur tout ce qu'ils veulent ... Puffo Presto, j'ai "volé" leurs mots de passe.

Oui, l'éducation des utilisateurs revient toujours pour nous mordre dans le hienie, n'est-ce pas?
Et il n'y a rien que vous puissiez faire à ce sujet ... Même si vous deviez hacher leurs mots de passe sur votre site et faire tout le reste auquel la TSA peut penser, vous avez ajouté une protection à leur mot de passe NOT ONE WHIT , s'ils veulent garder coller de manière promiscuité leurs mots de passe dans tous les sites sur lesquels ils se heurtent. N'essayez même pas d'essayer.

Autrement dit, vous ne possédez pas leurs mots de passe , alors arrêtez d'essayer d'agir comme vous.

Alors, mes chers experts en sécurité, comme une vieille dame demandait à Wendy's "O WH est le risque?"

Quelques autres points, en réponse à certaines questions soulevées ci-dessus:

  • CWE n'est ni une loi, ni un règlement, ni même une norme. Il s'agit d'un ensemble de faiblesses communes , c'est-à-dire l'inverse des "meilleures pratiques".
  • La question de l'identité partagée est un problème réel, mais mal compris (ou déformé) par les opposants ici. Il s'agit de partager l'identité en soi (!), PAS de casser les mots de passe sur les systèmes de faible valeur. Si vous partagez un mot de passe entre un système de faible valeur et un système de haute valeur, le problème est déjà là!
  • D'ailleurs, le point précédent indiquerait en fait CONTRE l' utilisation d'OAuth et similaires pour ces deux systèmes à faible valeur et les systèmes bancaires à haute valeur.
  • Je sais que ce n'était qu'un exemple, mais (malheureusement) les systèmes du FBI ne sont pas vraiment les plus sécurisés du monde. Pas tout à fait comme les serveurs du blog de votre chat, mais ils ne dépassent pas non plus certaines des banques les plus sécurisées.
  • La connaissance partagée, ou le double contrôle, des clés de chiffrement ne se produit PAS uniquement dans l'armée, en fait, PCI-DSS exige maintenant cela de pratiquement tous les marchands, donc ce n'est plus vraiment si loin (SI la valeur le justifie).
  • Pour tous ceux qui se plaignent que des questions comme celles-ci sont ce qui rend la profession de développeur si mauvaise: ce sont des réponses comme celles-ci, qui rendent la profession de sécurité encore pire. Encore une fois, l'analyse des risques axée sur l'entreprise est ce qui est nécessaire, sinon vous vous rendez inutile. En plus d'avoir tort.
  • Je suppose que c'est pourquoi ce n'est pas une bonne idée de simplement prendre un développeur régulier et de lui laisser plus de responsabilités en matière de sécurité, sans s'entraîner à penser différemment et à chercher les bons compromis. Aucune offense, à ceux d'entre vous ici, je suis tout à fait d'accord - mais plus d'entraînement est nécessaire.

Ouf. Quel long message ...
Mais pour répondre à votre question initiale, @Shane:

  • Expliquez au client la bonne façon de faire les choses.
  • S'il insiste encore, expliquez-en plus, insistez, argumentez. Jetez une crise de colère, si nécessaire.
  • Expliquez-lui le RISQUE COMMERCIAL. Les détails sont bons, les chiffres sont meilleurs, une démo en direct est généralement la meilleure.
  • S'il insiste toujours ET présente des raisons commerciales valables - il est temps pour vous de faire un jugement:
    ce site est-il de faible valeur? Est-ce vraiment une analyse de rentabilisation valide? Est-ce que c'est assez bon pour toi? N'y a-t-il pas d'autres risques que vous pouvez considérer, qui l'emporteraient sur des raisons commerciales valables? (Et bien sûr, le client n'est PAS un site malveillant, mais c'est duh).
    Si oui, allez-y. Cela ne vaut pas l'effort, la friction et la perte d'utilisation (dans cette situation hypothétique) pour mettre en place le processus nécessaire. Toute autre décision (encore une fois, dans cette situation) est un mauvais compromis.

Donc, en fin de compte, et une réponse réelle - chiffrez-la avec un algorithme symétrique simple, protégez la clé de chiffrement avec des ACL solides et de préférence DPAPI ou similaire, documentez-la et demandez au client (quelqu'un assez âgé pour prendre cette décision) de signer il.


5
Les mots de passe partagés entre votre site de faible valeur avec «aucun» actif coûteux et Facebook / GMail / votre banque sont un actif coûteux, même sur les sites de faible valeur.
jammycakes

3
Je pense que le problème ici est que les groupes d'utilisateurs mentionnés ci-dessus ont tendance à utiliser le même mot de passe pour toutes les applications de différents niveaux de sécurité (des banques aux blogs de recettes). La question est donc de savoir s'il incombe au développeur de protéger les utilisateurs même contre eux-mêmes. Je dirais certainement oui!
ercan

7
Je suis désolé, mais l'identité elle - même est un atout de grande valeur, point final. Aucune exception, aucune excuse. Peu importe à quel point vous pensez que votre site est petit et sans conséquence. Et un mot de passe partagé est l'identité s'il permet au pirate d'accéder aux comptes Facebook, aux comptes Gmail, aux comptes bancaires de vos utilisateurs, etc. Cela n'a rien à voir avec la sémantique, mais tout a à voir avec les conséquences. Demandez à quiconque a été touché par une attaque de pirate comme celle-ci: theregister.co.uk/2009/08/24/4chan_pwns_christians
jammycakes

2
@Jacob, dans quel monde votre client serait-il poursuivi parce que les comptes d'Erma sur d'autres systèmes ont été compromis? Même en cas de négligence grave de la part de votre client (ce qui n'est PAS une évidence, comme je l'ai expliqué), et EN PLUS du fait qu'il n'y a AUCUNE MANIÈRE de prouver que l'autre système a été violé à cause du vôtre, il n'y a aucun réclamer toute forme de dommages d'un système sur l'autre système. Elle serait rejetée à l'amiable avec préjudice et jugerait le demandeur coupable d'outrage. Cependant, Erma pourrait être en faute pour avoir violé de nombreuses conditions d'utilisation ...
AviD

5
@Jacob, c'est tellement faux. Tout simplement parce que le mot de passe se trouve être le même (ce qui violerait clairement vos conditions d'utilisation et leur politique de sécurité), il n'y a pas de capacité juridique pour corroder les deux. C'est même à côté du fait que la prouver serait presque impossible. En passant, je soulignerai également qu'aucune loi n'oblige une entreprise aléatoire à ne pas avoir de pratiques de sécurité laxistes, à moins que des réglementations spécifiques soient pertinentes. Et en plus de cela, les mots de passe SONT cryptés (!), Donc le relâchement est loin d'être une conclusion perdue.
AviD

21

Que diriez-vous d'une maison de transition?

Stockez les mots de passe avec un cryptage fort et n'activez pas les réinitialisations.

Au lieu de réinitialiser les mots de passe, autorisez l'envoi d'un mot de passe à usage unique (qui doit être modifié dès la première connexion). Laissez ensuite l'utilisateur changer de mot de passe (le précédent s'il le souhaite).

Vous pouvez "vendre" cela comme un mécanisme sécurisé pour réinitialiser les mots de passe.


Vous savez, je l'ai utilisé dans plusieurs situations (généralement c'est mon terrain d'entente), mais j'ai des gens qui me disent que l'utilisateur final ne va tout simplement pas obtenir l'interaction et que le support doit être capable de leur dire leur mot de passe «en raison des circonstances de ce modèle d'entreprise». Je conviens cependant que lorsque cela est possible, cela est préférable.
Shane

Vous pouvez toujours informer votre client du risque que sa base de données tombe entre de mauvaises mains et qu'il obtienne la publicité de mots de passe volés ... Il existe de nombreux exemples.
Oded

6
Demandez-leur de signer le "design", avec une clause supplémentaire selon laquelle ils ne peuvent pas vous poursuivre si ce que vous leur aviez prévenu se produit effectivement ... Au moins alors vous vous couvrez.
Oded

4
-1 les mots de passe ne doivent jamais être "cryptés" C'est une violation de CWE-257 cwe.mitre.org/data/definitions/257.html
tour

34
@Michael Brooks: Il n'est pas nécessaire de voter et copier-coller le même commentaire encore et encore; nous savons tous que c'est une mauvaise pratique. Shane a déclaré qu'il n'avait pas de poids dans la question, cependant, et donc la prochaine meilleure chose est proposée.
Johannes Gorset

13

La seule façon de permettre à un utilisateur de récupérer son mot de passe d'origine est de le chiffrer avec sa propre clé publique. Seul cet utilisateur peut ensuite déchiffrer son mot de passe.

Les étapes seraient donc:

  1. L'utilisateur s'inscrit sur votre site (via SSL bien sûr) sans encore définir de mot de passe. Connectez-vous automatiquement ou fournissez un mot de passe temporaire.
  2. Vous proposez de stocker leur clé PGP publique pour une future récupération de mot de passe.
  3. Ils téléchargent leur clé PGP publique.
  4. Vous leur demandez de définir un nouveau mot de passe.
  5. Ils soumettent leur mot de passe.
  6. Vous hachez le mot de passe en utilisant le meilleur algorithme de hachage de mot de passe disponible (par exemple bcrypt). Utilisez-le lors de la validation de la prochaine connexion.
  7. Vous cryptez le mot de passe avec la clé publique et le stockez séparément.

Si l'utilisateur demande ensuite son mot de passe, vous répondez avec le mot de passe crypté (non haché). Si l'utilisateur ne souhaite pas pouvoir récupérer son mot de passe à l'avenir (il ne pourra le réinitialiser que sur un service généré), les étapes 3 et 7 peuvent être ignorées.


5
La plupart des utilisateurs n'ont pas de clé PGP (je n'en ai toujours pas; après 20 ans dans l'industrie, je n'en ai jamais ressenti le besoin), et ce n'est pas un processus sans friction d'en obtenir une. De plus, une clé privée n'est en fait qu'un proxy pour un mot de passe réel. C'est un mot de passe pour un mot de passe, en d'autres termes; ce sont des tortues tout le long.
Robert Harvey

1
@RobertHarvey L'objectif est de permettre à un utilisateur de récupérer son mot de passe sans permettre aux employés du site ou à des pirates d'y accéder. En exigeant que le processus de récupération se déroule sur le propre ordinateur de l'utilisateur, vous appliquez cela. Il pourrait bien y avoir des alternatives au PGP qui pourraient y parvenir. Il peut y avoir des tortues tout le long (peut-être quelques éléphants le long du chemin), mais je ne vois pas d'autre moyen. Pour la population générale (peu susceptible d'être ciblée individuellement), avoir vos mots de passe sur un peu de papier et ne pas pouvoir les récupérer du service serait plus sûr que nous ne le sommes actuellement
Nicholas Shanks

Je l'aime parce qu'elle oblige tout le monde à avoir une clé publique PGP, ce qui est, étrangement, une chose très éthique à faire.
Lodewijk

vous pouvez simplement en générer un et le donner à l'utilisateur.
My1

@RobertHarvey Vous avez peut-être raison de dire que ce n'est "pas un processus sans friction", mais cela pourrait être un service supplémentaire pour les utilisateurs avancés, que les utilisateurs réguliers peuvent ignorer. Quant à l'argument selon lequel un PK est "un mot de passe pour un mot de passe", rappelez-vous qu'il peut en théorie l'être pour de nombreux mots de passe; vous pouvez utiliser des mots de passe différents pour différents services et les chiffrer tous à l'aide de la même clé. Le PK aura alors plus de valeur qu'un simple mot de passe. C'est peut-être d'une manière abstraite comparable à un gestionnaire de mots de passe (?). Je ne sais pas immédiatement quelles conséquences cela peut avoir ...
Kjartan

12

Je pense que la vraie question que vous devriez vous poser est: "Comment puis-je être meilleur pour convaincre les gens?"


4
@sneg - Eh bien, je suis un gars très convaincant, mais parfois c'est un patron et parfois un client, donc je n'ai pas toujours l'effet de levier dont j'ai besoin pour les convaincre d'une manière ou d'une autre. Je vais m'entraîner un peu plus dans le miroir ..;)
Shane

Pour être convaincant, vous n'avez pas vraiment besoin d'un autre levier que vos compétences et vos aptitudes à la communication. Si vous connaissez une meilleure façon de faire quelque chose mais que les gens n'écoutent pas ... Pensez-y.
z-boss

7
@ z-boss - Apparemment, vous n'avez pas travaillé avec / pour certaines des têtes dures avec lesquelles j'ai eu le plaisir de travailler. Parfois, cela n'a pas d'importance si votre langue est plaquée or et vous pouvez reprogrammer Google Chrome en une journée (ce qui pourrait sans doute le rendre utile), ils ne bougeront toujours pas.
Shane

11

J'ai le même problème. Et de la même manière je pense toujours que quelqu'un pirate mon système ce n'est pas une question de "si" mais de "quand".

Donc, quand je dois faire un site Web qui doit stocker des informations confidentielles récupérables, comme une carte de crédit ou un mot de passe, ce que je fais c'est:

  • crypter avec: openssl_encrypt (chaîne $ data, chaîne $ méthode, chaîne $ mot de passe)
  • argument de données :
    • les informations sensibles (par exemple le mot de passe utilisateur)
    • sérialiser si nécessaire, par exemple si les informations sont un tableau de données comme plusieurs informations sensibles
  • mot de passe arg : utilisez une information que seul l'utilisateur connaît comme:
    • la plaque d'immatriculation de l'utilisateur
    • numéro de sécurité sociale
    • numéro de téléphone de l'utilisateur
    • le nom de la mère de l'utilisateur
    • une chaîne aléatoire envoyée par email et / ou par sms au moment de l'inscription
  • méthode arg :
    • choisissez une méthode de chiffrement, comme "aes-256-cbc"
  • NE JAMAIS stocker les informations utilisées dans l'argument "mot de passe" dans la base de données (ou à n'importe quel endroit du système)

Lorsque nécessaire pour récupérer ces données, utilisez simplement la fonction "openssl_decrypt ()" et demandez à l'utilisateur la réponse. Par exemple: "Pour recevoir votre mot de passe, répondez à la question: Quel est votre numéro de téléphone portable?"

PS 1 : n'utilisez jamais comme mot de passe une donnée stockée dans la base de données. Si vous devez enregistrer le numéro de téléphone portable de l'utilisateur, n'utilisez jamais ces informations pour coder les données. Utilisez toujours une information que seul l'utilisateur connaît ou qui est difficile à connaître pour une personne non apparentée.

PS 2 : pour les informations de carte de crédit, comme "achat en un clic", ce que je fais est d'utiliser le mot de passe de connexion. Ce mot de passe est haché dans la base de données (sha1, md5, etc.), mais au moment de la connexion, je stocke le mot de passe en texte brut en session ou dans un cookie sécurisé non persistant (c'est-à-dire en mémoire). Ce mot de passe simple ne reste jamais dans la base de données, en effet il reste toujours en mémoire, détruit en fin de section. Lorsque l'utilisateur clique sur le bouton "Achat en un clic", le système utilise ce mot de passe. Si l'utilisateur était connecté avec un service comme Facebook, Twitter, etc., j'invite à nouveau le mot de passe au moment de l'achat (ok, ce n'est pas un «clic» complet) ou j'utilise ensuite certaines données du service que l'utilisateur a utilisé pour se connecter. (comme l'identifiant facebook).


9

La sécurisation des informations d'identification n'est pas une opération binaire: sécurisée / non sécurisée. La sécurité est une question d'évaluation des risques et est mesurée sur un continuum. Les fanatiques de la sécurité détestent penser de cette façon, mais la triste vérité est que rien n'est parfaitement sécurisé. Les mots de passe hachés avec des exigences de mot de passe strictes, des échantillons d'ADN et des analyses de la rétine sont plus sûrs mais à un coût de développement et d'expérience utilisateur. Les mots de passe en texte clair sont beaucoup moins sûrs mais moins chers à implémenter (mais devraient être évités). En fin de compte, cela revient à une analyse coûts / avantages d'une violation. Vous implémentez la sécurité en fonction de la valeur des données sécurisées et de leur valeur temporelle.

Quel est le coût du mot de passe de quelqu'un pour sortir dans la nature? Quel est le coût de l'emprunt d'identité dans le système donné? Pour les ordinateurs du FBI, le coût pourrait être énorme. Pour le site Web unique de cinq pages de Bob, le coût pourrait être négligeable. Un professionnel offre des options à ses clients et, en matière de sécurité, expose les avantages et les risques de toute mise en œuvre. Cela est d'autant plus vrai si le client demande quelque chose qui pourrait le mettre en danger en raison du non-respect des normes de l'industrie. Si un client demande spécifiquement un cryptage bidirectionnel, je veillerais à ce que vous documentiez vos objections, mais cela ne devrait pas vous empêcher de mettre en œuvre de la meilleure façon possible. Au bout du compte, c'est l'argent du client. Oui,

Si vous stockez des mots de passe avec un cryptage bidirectionnel, la sécurité se résume à la gestion des clés. Windows fournit des mécanismes pour restreindre l'accès aux clés privées des certificats aux comptes administratifs et aux mots de passe. Si vous hébergez sur une autre plate-forme, vous devrez voir quelles options vous avez disponibles sur celles-ci. Comme d'autres l'ont suggéré, vous pouvez utiliser un cryptage asymétrique.

Il n'y a pas de loi (ni la loi sur la protection des données au Royaume-Uni) dont je suis conscient qui stipule spécifiquement que les mots de passe doivent être stockés à l'aide de hachages unidirectionnels. La seule exigence de l'une de ces lois est simplement que des mesures raisonnables soient prises pour garantir la sécurité. Si l'accès à la base de données est restreint, même les mots de passe en texte brut peuvent légalement bénéficier d'une telle restriction.

Cependant, cela met en lumière un autre aspect: la préséance juridique. Si la priorité juridique suggère que vous devez utiliser des hachages unidirectionnels compte tenu de l'industrie dans laquelle votre système est construit, alors c'est tout à fait différent. Ce sont les munitions que vous utilisez pour convaincre votre client. Sauf que, la meilleure suggestion pour fournir une évaluation des risques raisonnable, documenter vos objections et mettre en œuvre le système de la manière la plus sécurisée possible selon les exigences du client.


10
Votre réponse ignore complètement que les mots de passe sont réutilisés sur plusieurs sites / services, ce qui est au cœur de ce sujet et la raison même pour laquelle les mots de passe récupérables sont considérés comme une grave faiblesse. Un professionnel de la sécurité ne délègue pas de décisions de sécurité au client non technique; un professionnel sait que ses responsabilités s'étendent au-delà du client payant et ne propose pas d'options à haut risque et sans récompense. -1 pour une diatribe lourde de rhétorique et extrêmement légère sur les faits - et pour ne même pas vraiment répondre à la question.
Aaronaught

4
Encore une fois, vous ignorez complètement l'évaluation des risques. Pour utiliser votre argument, vous ne pouvez pas vous contenter de hachages à sens unique. Vous devez également inclure les exigences de complexité, la longueur des mots de passe, les restrictions de réutilisation des mots de passe, etc. Faire valoir que les utilisateurs utiliseront des mots de passe stupides ou réutiliseront des mots de passe n'est pas une justification commerciale suffisante si le système n'est pas pertinent et franchement, j'ai répondu à la question. La réponse courte: faites pression pour utiliser une implémentation std, documentez vos objections si vous êtes annulé et passez à autre chose.
Thomas

7
Et encore une fois, vous répétez le canard que rien de tout cela n'a d'importance pour un système de faible valeur! La valeur du mot de passe d'un utilisateur n'a rien à voir avec la valeur du compte d'un utilisateur sur votre système. C'est un secret que vous devez toujours garder. J'aimerais pouvoir donner un autre -1 pour le commentaire démontrant que vous ne comprenez toujours pas les problèmes ici.
Aaronaught

5
L'évaluation des risques est la question centrale. La réutilisation des mots de passe n'est qu'un problème potentiel dans un ensemble beaucoup plus vaste de problèmes. Pourquoi ne pas avoir besoin de fobs? Pourquoi ne pas exiger que la personne se rende à votre bureau pour se connecter? Sans une évaluation raisonnable des risques, il n'y a aucun moyen de répondre à ces questions. Dans votre monde, tout est un risque, donc chaque système nécessite une sécurité de connexion au niveau du FBI. Ce n'est tout simplement pas ainsi que fonctionne le monde réel.
Thomas

7
La seule chose qui est claire ici est que tout votre argument n'est rien d'autre qu'un sophisme Slippery Slope et que vous essayez de faire rouler les lecteurs avec des mots à la mode comme «évaluation des risques» afin de couvrir ce fait. Soyez assuré que le système utilisé par le "FBI" sera beaucoup plus sûr qu'un hachage bcrypt et une longueur de mot de passe minimale. Si exiger des systèmes d'authentification standard fait de moi un "fanatique de la sécurité", alors je suppose que je suis un fanatique; personnellement, cela me fait mal de savoir qu'il y a des gens prêts à sacrifier MA sécurité pour de l'argent. C'est contraire à l'éthique .
Aaronaught

8

Intégrez la réponse à la question de sécurité de l'utilisateur à la clé de chiffrement et ne stockez pas la réponse à la question de sécurité en texte brut (hachez-la à la place)


L'utilisateur peut également répondre différemment à la question. Certaines questions demandent des réponses plus longues et faciles à reformuler plus tard.
Monoman

5
Les questions de sécurité sont une mauvaise idée. Comment obligez-vous votre maman à changer son nom de jeune fille une fois que les informations sont violées? Voir également la sécurité technique de Peter Gutmann .
2013

7

J'implémente des systèmes d'authentification à plusieurs facteurs pour une vie, donc pour moi, il est naturel de penser que vous pouvez réinitialiser ou reconstruire le mot de passe, tout en utilisant temporairement un facteur de moins pour authentifier l'utilisateur uniquement pour le flux de travail de réinitialisation / loisirs. En particulier, l'utilisation d'OTP (mots de passe à usage unique) comme certains des facteurs supplémentaires, atténue une grande partie du risque si la fenêtre de temps est courte pour le flux de travail suggéré. Nous avons implémenté avec succès des générateurs logiciels OTP pour smartphones (que la plupart des utilisateurs emportent avec eux toute la journée). Avant de se plaindre d'un plug-in commercial, ce que je dis, c'est que nous pouvons réduire les risques inhérents à garder les mots de passe facilement récupérables ou réinitialisables lorsqu'ils ne sont pas le seul facteur utilisé pour authentifier un utilisateur.


Supprimer temporairement un facteur d'un système d'authentification à plusieurs facteurs est en effet un moyen beaucoup plus sûr de réinitialiser un mot de passe que les systèmes exaspérants de «questions secrètes» que l'on trouve sur tant de sites. Mais en ce qui concerne le stockage des mots de passe dans un format récupérable, je ne sais pas comment cela aide, à moins que vous n'utilisiez le deuxième facteur pour chiffrer ou obscurcir le premier, et je ne sais pas comment c'est possible avec quelque chose comme un SecurID. Peux-tu expliquer?
Aaronaught

@Aaronaught Ce que j'ai dit, c'est que si vous êtes «obligé» d'avoir des mots de passe récupérables, le risque inhérent est plus faible s'il n'est pas le seul facteur d'authentification, et il est également plus facile pour l'utilisateur final, si ce flux de travail réutilise des facteurs qui il / elle possède déjà et a un accès actuel à, plutôt que d'essayer de se souvenir de «réponses secrètes» probablement oubliées ou d'utiliser des liens à durée limitée ou des mots de passe temporaires, tous deux envoyés par des canaux dangereux (sauf si vous utilisez S-MIME avec des certificats clients, ou PGP, les deux entraînant des coûts spécialement pour la gestion de l'association correcte et l'expiration / substitution)
Monoman

1
Je suppose que tout cela est vrai, mais le risque de compromis public est minime au départ; le problème le plus grave avec les mots de passe récupérables est la sécurité interne et potentiellement permettre à un employé mécontent de repartir avec les mots de passe e-mail de milliers de clients, ou un PDG tordu pour le vendre à des hameçonneurs et des spammeurs. L'authentification à deux facteurs est excellente pour lutter contre le vol d'identité et la recherche de mots de passe, mais n'apporte pas vraiment grand-chose en ce qui concerne la sécurité de la base de données de mots de passe.
Aaronaught

5

Désolé, mais tant que vous avez un moyen de décoder leur mot de passe, il n'y a aucun moyen qu'il soit sécurisé. Combattez-le amèrement, et si vous perdez, CYA.


5

Je viens de tomber sur cette discussion intéressante et passionnée. Ce qui m'a le plus surpris, c'est le peu d'attention accordé à la question fondamentale suivante:

  • Q1. Quelles sont les raisons réelles pour lesquelles l'utilisateur insiste pour avoir accès au mot de passe stocké en texte brut? Pourquoi est-il si précieux?

Les informations selon lesquelles les utilisateurs sont plus âgés ou plus jeunes ne répondent pas vraiment à cette question. Mais comment prendre une décision commerciale sans bien comprendre les préoccupations du client?

Maintenant, pourquoi est-ce important? Parce que si la véritable cause de la demande des clients est le système qui est douloureusement difficile à utiliser, alors peut-être que la résolution de la cause exacte résoudrait le problème réel?

Comme je n'ai pas ces informations et ne peux pas parler à ces clients, je ne peux que deviner: il s'agit de convivialité, voir ci-dessus.

Une autre question que j'ai vue posée:

  • Q2. Si l'utilisateur ne se souvient pas du mot de passe en premier lieu, pourquoi l'ancien mot de passe est-il important?

Et voici une réponse possible. Si vous avez un chat appelé "miaumiau" et avez utilisé son nom comme mot de passe mais que vous l'avez oublié, préféreriez-vous qu'on vous rappelle ce que c'était ou plutôt qu'on vous envoie quelque chose comme "# zy * RW (ew")?

Une autre raison possible est que l'utilisateur considère qu'il est difficile de trouver un nouveau mot de passe! Donc, avoir l'ancien mot de passe renvoyé donne l'illusion de la sauver à nouveau de ce travail douloureux.

J'essaie juste de comprendre la raison. Mais quelle qu'en soit la raison, c'est la raison et non la cause qui doit être abordée.

En tant qu'utilisateur, je veux des choses simples! Je ne veux pas travailler dur!

Si je me connecte à un site d'actualités pour lire les journaux, je veux taper 1111 comme mot de passe et continuer !!!

Je sais que ce n'est pas sûr, mais que m'importe que quelqu'un ait accès à mon "compte"? Oui, il peut aussi lire les nouvelles!

Le site stocke-t-il mes informations "privées"? Les nouvelles que j'ai lues aujourd'hui? Alors c'est le problème du site, pas le mien! Le site affiche-t-il des informations privées à l'utilisateur authentifié? Alors ne le montrez pas en premier lieu!

Il s'agit simplement de démontrer l'attitude de l'utilisateur face au problème.

Donc, pour résumer, je ne pense pas que ce soit un problème de savoir comment stocker "en toute sécurité" les mots de passe en texte brut (ce que nous savons impossible), mais plutôt comment répondre aux préoccupations réelles des clients.


4

Gestion des mots de passe perdus / oubliés:

Personne ne devrait jamais pouvoir récupérer les mots de passe.

Si les utilisateurs ont oublié leurs mots de passe, ils doivent au moins connaître leurs noms d'utilisateur ou adresses e-mail. Sur demande, générez un GUID dans la table Utilisateurs et envoyez un e-mail contenant un lien contenant le guide en tant que paramètre à l'adresse e-mail de l'utilisateur.

La page derrière le lien vérifie que le paramètre guid existe réellement (probablement avec une logique de temporisation) et demande à l'utilisateur un nouveau mot de passe.

Si vous avez besoin que les utilisateurs d'aide de la hotline ajoutent des rôles à votre modèle de subventions et permettent au rôle de la hotline de se connecter temporairement en tant qu'utilisateur identifié. Connectez-vous à toutes ces connexions par hotline. Par exemple, Bugzilla offre une telle fonction d'emprunt d'identité aux administrateurs.


Le GUID est une mauvaise idée, pas assez aléatoire et facile à utiliser. il y a d'autres problèmes avec cela, voir stackoverflow.com/questions/664673/…
AviD

3

Qu'en est-il de l'envoi par e-mail du mot de passe en clair lors de l'inscription, avant de le chiffrer et de le perdre? J'ai vu beaucoup de sites Web le faire, et obtenir ce mot de passe à partir du courrier électronique de l'utilisateur est plus sûr que de le laisser sur votre serveur / maquette.


Je ne suppose pas que le courrier électronique est plus sécurisé que tout autre système. Bien que cela me prive de la préoccupation juridique, il y a toujours le problème de la perte / suppression de votre e-mail et maintenant je reviens à la case départ.
Shane

Fournissez à la fois une réinitialisation du mot de passe et envoyez le mot de passe en clair par e-mail. Je pense que c'est tout ce que vous pouvez faire sur le sujet, sans conserver vous-même une copie du mot de passe.
casraf

C'est une idée absolument horrible. C'est à la fois inefficace (de nombreux utilisateurs suppriment les e-mails après avoir lu) et pire que ce contre quoi vous essayez de vous protéger (car les e-mails ne sont pas cryptés par défaut et transitent par des réseaux non fiables). Mieux vaut suggérer à l'utilisateur de noter lui-même le mot de passe, au moins en s'envoyant un e-mail, les informations ne vont jamais plus loin que le serveur de messagerie, pas sur tout Internet!
Ben Voigt

3

Si vous ne pouvez pas simplement rejeter l'exigence de stocker des mots de passe récupérables, qu'en est-il de votre contre-argument?

Nous pouvons soit hacher correctement les mots de passe et créer un mécanisme de réinitialisation pour les utilisateurs, soit supprimer toutes les informations personnellement identifiables du système. Vous pouvez utiliser une adresse e-mail pour configurer les préférences de l'utilisateur, mais c'est tout. Utilisez un cookie pour extraire automatiquement les préférences lors de vos prochaines visites et jeter les données après une période raisonnable.

La seule option qui est souvent négligée avec la politique de mot de passe est de savoir si un mot de passe est vraiment même nécessaire. Si la seule chose que fait votre politique de mot de passe est de provoquer des appels au service client, vous pouvez peut-être vous en débarrasser.


Tant que vous avez une adresse e-mail associée à un mot de passe et que ce mot de passe est récupérable, vous avez potentiellement divulgué le mot de passe pour cette adresse e-mail en raison de la réutilisation du mot de passe. C'est en fait la principale préoccupation ici. Il n'y a vraiment aucune autre information personnellement identifiable qui compte.
Aaronaught

1
Vous avez complètement manqué mon point. Si vous n'avez pas vraiment besoin d'un mot de passe, n'en récupérez pas. Les développeurs se retrouvent souvent coincés dans le mode de pensée «c'est comme ça que nous le faisons». Parfois, cela aide à jeter des notions préconçues.
anopres

2

Les utilisateurs ont-ils vraiment besoin de récupérer (par exemple, être informés) quel était le mot de passe qu'ils ont oublié, ou doivent-ils simplement pouvoir accéder au système? Si ce qu'ils veulent vraiment, c'est un mot de passe pour se connecter, pourquoi ne pas avoir une routine qui change simplement l'ancien mot de passe (quel qu'il soit) en un nouveau mot de passe que la personne de soutien peut donner à la personne qui a perdu son mot de passe?

J'ai travaillé avec des systèmes qui font exactement cela. La personne de support n'a aucun moyen de savoir quel est le mot de passe actuel, mais peut le réinitialiser à une nouvelle valeur. Bien sûr, toutes ces réinitialisations doivent être enregistrées quelque part et la bonne pratique consiste à générer un e-mail à l'utilisateur lui indiquant que le mot de passe a été réinitialisé.

Une autre possibilité est d'avoir deux mots de passe simultanés permettant d'accéder à un compte. L'un est le mot de passe "normal" que l'utilisateur gère et l'autre est comme un squelette / clé principale qui est connu du personnel de support uniquement et est le même pour tous les utilisateurs. De cette façon, lorsqu'un utilisateur a un problème, le support peut se connecter au compte avec la clé principale et aider l'utilisateur à changer son mot de passe. Inutile de dire que toutes les connexions avec la clé principale doivent également être enregistrées par le système. Comme mesure supplémentaire, chaque fois que la clé principale est utilisée, vous pouvez également valider les informations d'identification des personnes de support.

-EDIT- En réponse aux commentaires sur le fait de ne pas avoir de clé principale: je reconnais que c'est mauvais tout comme je pense qu'il est mauvais de permettre à toute personne autre que l'utilisateur d'avoir accès au compte de l'utilisateur. Si vous regardez la question, tout le postulat est que le client a rendu obligatoire un environnement de sécurité hautement compromis.

Une clé principale n'a pas besoin d'être aussi mauvaise qu'il n'y paraît. J'avais l'habitude de travailler dans une usine de défense où ils ont perçu la nécessité pour l'opérateur d'ordinateur central d'avoir un "accès spécial" à certaines occasions. Ils ont simplement mis le mot de passe spécial dans une enveloppe scellée et l'ont collé au bureau de l'opérateur. Pour utiliser le mot de passe (que l'opérateur ne connaissait pas), il a dû ouvrir l'enveloppe. À chaque changement de quart de travail, l'une des tâches du superviseur de quart était de voir si l'enveloppe avait été ouverte et, dans l'affirmative, le mot de passe a été changé immédiatement (par un autre service) et le nouveau mot de passe a été placé dans une nouvelle enveloppe et le processus a commencé tout. à nouveau. L'opérateur serait interrogé sur les raisons de son ouverture et l'incident serait documenté pour le dossier.

Bien que ce ne soit pas une procédure que je concevrais, elle a fonctionné et a fourni une excellente reddition de comptes. Tout a été enregistré et examiné, en plus tous les opérateurs avaient des autorisations secrètes DOD et nous n'avons jamais eu d'abus.

En raison de l'examen et de la surveillance, tous les opérateurs savaient que s'ils abusaient du privilège d'ouvrir l'enveloppe, ils pouvaient faire l'objet d'un licenciement immédiat et d'éventuelles poursuites pénales.

Donc, je suppose que la vraie réponse est que si l'on veut bien faire les choses, on embauche des personnes en qui on peut avoir confiance, faire des vérifications des antécédents et exercer une surveillance et une responsabilisation de gestion appropriées.

Mais là encore, si le client de ce pauvre garçon avait une bonne gestion, il n'aurait pas demandé une telle solution de sécurité en premier lieu, n'est-ce pas?


Une clé principale serait extrêmement risquée, le personnel de support aurait accès à tous les comptes - et une fois que vous aurez donné cette clé à un utilisateur, il aurait alors la clé principale et aurait accès à tout.
Carson Myers

Une clé principale est une idée terrible, car si quelqu'un la découvre (ou la fait divulguer par accident), elle peut l'exploiter. Le mécanisme de réinitialisation du mot de passe par compte est de loin préférable.
Phil Miller

Je suis curieux, je pensais que Linux par défaut avait un compte super utilisateur avec un accès root? N'est-ce pas une "clé principale" pour accéder à tous les fichiers du système?
JonnyBoats

@JonnyBoats Oui, ça l'est. C'est pourquoi les Unix modernes comme Mac OS X désactivent le compte root.
Nicholas Shanks

@NicholasShanks: désactiver le compte root ou désactiver la connexion interactive sur le compte root? Il y a encore beaucoup de code en cours d'exécution avec des autorisations illimitées.
Ben Voigt

2

D'après le peu que je comprends à ce sujet, je pense que si vous créez un site Web avec un code d'accès / mot de passe, vous ne devriez même pas voir le mot de passe en clair sur votre serveur. Le mot de passe doit être haché, et probablement salé, avant même qu'il ne quitte le client.

Si vous ne voyez jamais le mot de passe en texte clair, la question de la récupération ne se pose pas.

De plus, je suppose (sur le Web) que (prétendument) certains algorithmes tels que MD5 ne sont plus considérés comme sécurisés. Je n'ai aucun moyen de juger cela moi-même, mais c'est quelque chose à considérer.


1

ouvrez une base de données sur un serveur autonome et accordez une connexion à distance chiffrée à chaque serveur Web qui nécessite cette fonctionnalité.
il ne doit pas nécessairement s'agir d'une base de données relationnelle, il peut s'agir d'un système de fichiers avec accès FTP, utilisant des dossiers et des fichiers au lieu de tables et de lignes.
accordez aux serveurs Web des autorisations en écriture seule si vous le pouvez.

Stockez le cryptage non récupérable du mot de passe dans la base de données du site (appelons-le "pass-a") comme les gens normaux le font :)
à chaque nouvel utilisateur (ou changement de mot de passe) stockez une copie simple du mot de passe dans la base de données distante. utilisez l'ID du serveur, l'ID de l'utilisateur et "pass-a" comme clé composite pour ce mot de passe. vous pouvez même utiliser un cryptage bidirectionnel sur le mot de passe pour mieux dormir la nuit.

maintenant, pour que quelqu'un obtienne à la fois le mot de passe et son contexte (id du site + id d'utilisateur + "pass-a"), il doit:

  1. pirater la base de données du site Web pour obtenir une ou plusieurs paires ("pass-a", identifiant d'utilisateur).
  2. obtenir l'identifiant du site Web à partir d'un fichier de configuration
  3. rechercher et pirater la base de données de mots de passe distants.

vous pouvez contrôler l'accessibilité du service de récupération de mot de passe (l'exposer uniquement en tant que service Web sécurisé, autoriser uniquement une certaine quantité de récupération de mots de passe par jour, le faire manuellement, etc.), et même facturer des frais supplémentaires pour cet "arrangement de sécurité spécial".
Le serveur de base de données de récupération de mots de passe est assez caché car il ne remplit pas de nombreuses fonctions et peut être mieux sécurisé (vous pouvez personnaliser les autorisations, les processus et les services).

dans l'ensemble, vous compliquez le travail du pirate. le risque d'une faille de sécurité sur un serveur unique est toujours le même, mais les données significatives (une correspondance de compte et de mot de passe) seront difficiles à assembler.


3
Si le serveur d'applications peut y accéder, il en est de même pour toute personne ayant accès au serveur d'applications (qu'il s'agisse d'un pirate informatique ou d'un initié malveillant). Cela n'offre aucune sécurité supplémentaire.
molf

1
La sécurité supplémentaire ici est que la base de données du serveur d'applications ne contient pas de mots de passe (donc un deuxième piratage est nécessaire - vers la base de données de mots de passe), et la base de données de mots de passe peut être mieux protégée contre les activités irrégulières, car vous contrôlez l'accessibilité du service de récupération de mot de passe. afin que vous puissiez détecter les récupérations de données en masse, modifier la clé SSH de récupération sur une base hebdomadaire, ou même ne pas autoriser la récupération automatique des passes, et tout faire manuellement. Cette solution s'adapte également à tout autre schéma de chiffrement interne (comme les clés publiques + privées, sel, etc.) pour la base de données de mots de passe.
Amir Arad

1

Une autre option que vous n'avez peut-être pas envisagée est d'autoriser des actions par e-mail. C'est un peu lourd, mais j'ai implémenté cela pour un client qui avait besoin d'utilisateurs "en dehors" de leur système pour visualiser (lecture seule) certaines parties du système. Par exemple:

  1. Une fois qu'un utilisateur est enregistré, il dispose d'un accès complet (comme un site Web classique). L'inscription doit inclure un e-mail.
  2. Si des données ou une action sont nécessaires et que l'utilisateur ne se souvient pas de son mot de passe, il peut toujours effectuer l'action en cliquant sur un bouton spécial " m'envoyer un e-mail pour permission ", juste à côté du bouton " soumettre ".
  3. La demande est ensuite envoyée à l'e-mail avec un lien hypertexte leur demandant s'ils souhaitent que l'action soit effectuée. Ceci est similaire à un lien e-mail de réinitialisation de mot de passe, mais au lieu de réinitialiser le mot de passe, il effectue l' action unique .
  4. L'utilisateur clique ensuite sur "Oui", et il confirme que les données doivent être affichées, ou que l'action doit être effectuée, les données révélées, etc.

Comme vous l'avez mentionné dans les commentaires, cela ne fonctionnera pas si l'e-mail est compromis, mais cela répond au commentaire de @joachim de ne pas vouloir réinitialiser le mot de passe. Finalement, ils devraient utiliser la réinitialisation du mot de passe, mais ils pourraient le faire à un moment plus opportun, ou avec l'aide d'un administrateur ou d'un ami, selon les besoins.

Une solution à cette solution serait d'envoyer la demande d'action à un administrateur tiers de confiance. Cela fonctionnerait mieux dans les cas d'utilisateurs âgés, handicapés mentaux, très jeunes ou autrement confus. Bien sûr, cela nécessite un administrateur de confiance pour que ces personnes prennent en charge leurs actions.


1

Salez et hachez le mot de passe de l'utilisateur comme d'habitude. Lors de la connexion de l'utilisateur, autorisez à la fois le mot de passe de l'utilisateur (après salage / hachage), mais autorisez également ce que l'utilisateur a littéralement entré pour correspondre.

Cela permet à l'utilisateur d'entrer son mot de passe secret, mais lui permet également d'entrer la version salée / hachée de son mot de passe, ce que quelqu'un lirait de la base de données.

Fondamentalement, faites du mot de passe salé / haché un mot de passe "en texte brut".


Pourquoi pensez-vous qu'il est nécessaire de comparer ce que l'utilisateur a entré directement au mot de passe haché stocké dans la base de données? Quel genre de fonctionnalité cela vous donne-t-il? En outre, lors de cette opération, il est extrêmement important d'appliquer une fonction de comparaison à temps constant entre le mot de passe entré par l'utilisateur et le mot de passe haché de la base de données. Sinon, il est presque trivialement possible de déterminer le mot de passe haché en fonction des différences de synchronisation.
Artjom B.

1
@ArtjomB. La question demande comment protéger le mot de passe de l'utilisateur tout en permettant également au support client (CS) de parler / envoyer un e-mail à un utilisateur en saisissant son mot de passe oublié. En rendant la version hachée utilisable comme mot de passe en texte brut, CS peut la lire et demander à l'utilisateur de l'utiliser à la place de son mot de passe oublié. CS peut également l'utiliser pour se connecter en tant qu'utilisateur et les aider dans une tâche. Cela permet également aux utilisateurs qui sont à l'aise avec les systèmes automatisés de mot de passe oublié d'être protégés, car le mot de passe qu'ils saisissent et utilisent est haché.
Eliott

Je vois. Je n'ai pas lu la question dans son intégralité. L'utilisation d'une comparaison à temps constant est toujours nécessaire pour éviter une rupture triviale de l'ensemble du système.
Artjom B.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.