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?

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.

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.

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.

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

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.

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:

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

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.

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.

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!

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.

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.

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.

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.

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

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)
  • Manuel PHP .
• 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).

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.

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)

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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