Comment dois-je aborder de manière éthique le stockage des mots de passe des utilisateurs pour une récupération ultérieure du texte en clair?
Tandis 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 à ce qu’ils puissent être récupérés si/lorsque l’utilisateur a un problème (envoyer par e-mail un lien de mot de passe oublié, passez-le au travers de la téléphone, etc.) Lorsque je peux me battre avec acharnement contre cette pratique et que je fais beaucoup de programmation "supplémentaire" pour rendre possible la réinitialisation du mot de passe et l’assistance administrative sans stocker leur mot de passe réel.
Quand je ne peux pas me battre (ou ne peux pas gagner), alors je code toujours le mot de passe de manière à ce que, du moins, il ne soit pas stocké en texte clair dans la base de données - bien que je sache que si ma base de données est piratée le coupable n'aurait pas besoin de beaucoup pour déchiffrer les mots de passe, alors ça me met mal à l'aise.
Dans un monde parfait, les gens mettraient à jour fréquemment les mots de passe et ne les dupliqueraient pas sur de nombreux sites. Malheureusement, je connais BEAUCOUP de personnes qui ont le même mot de passe travail/maison/email/banque et qui me l'ont même donné librement lorsqu'elles ont besoin d'assistance. Je ne veux pas être responsable de leur faillite financière si les procédures de sécurité de ma base de données échouent pour une raison quelconque.
Moralement et éthiquement, je me sens responsable de la protection de ce qui peut être, pour certains utilisateurs, leur gagne-pain, même s’ils le traitent avec beaucoup moins de respect. Je suis persuadé qu’il existe de nombreux moyens d’approche et d’argumenter les arguments en faveur du hachage du salage et des différentes options de codage, mais existe-t-il une "meilleure pratique" lorsqu’il faut les stocker? Dans presque tous les cas, j'utilise PHP et MySQL si cela ne change rien à la façon dont je devrais gérer les détails.
Informations supplémentaires pour Bounty
Je tiens à préciser que je sais que ce n’est pas quelque chose que vous souhaitez faire et que, dans la plupart des cas, le refus de le faire est préférable. Cependant, je ne cherche pas à donner une conférence sur les avantages de cette approche. Je cherche les meilleures mesures à prendre si vous adoptez cette approche.
Dans une note ci-dessous, j'ai souligné le fait que les sites Web principalement destinés aux personnes âgées, aux personnes ayant une déficience intellectuelle ou aux très jeunes enfants peuvent devenir source de confusion pour les utilisateurs qui leur demandent d'effectuer une routine de récupération de mot de passe sécurisé. Bien que cela puisse sembler simple et banal dans certains cas, certains utilisateurs ont besoin de l’aide supplémentaire d’un technicien de service pour les intégrer au système ou de leur envoyer un message directement par courrier électronique.
Dans de tels systèmes, le taux d'attrition lié à 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 en gardant à l'esprit une telle configuration.
Merci à tous
C'était une question amusante avec beaucoup de débats et j'ai apprécié. En fin de compte, j'ai sélectionné une réponse qui conserve la sécurité du mot de passe (je ne conserverai pas le texte brut ni les 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 inconvénients majeurs que j'ai trouvés dans récupération de mot de passe normale.
Comme toujours, il y avait environ 5 réponses que j'aurais aimé marquer comme étant correctes pour différentes raisons, mais je devais choisir la meilleure - tout le reste obtenait 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 comme un compliment et j'espère que cette discussion a aidé quelqu'un d'autre avec les mêmes préoccupations que moi.
Pourquoi ne pas adopter une autre approche ou un autre angle face à ce problème? Demandez pourquoi le mot de passe doit être écrit en texte brut: 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 pouvoir 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. Cependant, l’un des inconvénients des mécanismes courants de réinitialisation de mot de passe utilisés de nos jours est que les mots de passe générés générés lors d’une opération de réinitialisation consistent généralement en une multitude de caractères aléatoires. Il est donc difficile pour l’utilisateur de taper simplement correctement à moins qu’ils pâte. Cela peut être un problème pour les utilisateurs d’ordinateurs moins avertis.
Une solution à ce problème consiste à 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 en langage naturel puissent ne pas avoir l'entropie qu'une chaîne de caractères aléatoires de la même longueur, rien n'indique que votre mot de passe généré automatiquement ne doit comporter que 8 (ou 10 ou 12) caractères. Obtenez une phrase secrète générée automatiquement à entropie élevée en enchaînant plusieurs mots aléatoires (laissez un espace entre eux, afin qu'ils soient toujours reconnaissables et lisibles par quiconque est capable de 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 en majuscules, minuscules, chiffres et 10 symboles de ponctuation (pour un total de 72 symboles valides) aurait une entropie de 61,7 bits. En utilisant un dictionnaire de 7776 mots (utilisés par Diceware) pouvant être sélectionnés de manière aléatoire pour une phrase secrète de six mots, la phrase secrète aurait une entropie de 77,4 bits. Voir le FAQ Diceware pour plus d'informations.
une phrase secrète avec environ 77 bits d'entropie: "admit flare aiguë en prose"
un mot de passe avec environ 74 bits d'entropie: "K: & $ R ^ tt ~ qkD"
Je sais que je préférerais taper la phrase, et avec copier-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 l’actif protégé) n’a pas besoin de 77 bits d’entropie pour une phrase secrète générée automatiquement, générez moins de mots (ce que vos utilisateurs apprécieraient, j'en suis sûr).
Je comprends les arguments selon lesquels il existe des actifs protégés par mot de passe qui n’ont pas vraiment une valeur élevée, de sorte que la violation d’un mot de passe peut 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 différents sites Web étaient enfreints: tout ce qui pourrait se produire est une personne qui fait du spam ou qui poste sous mon nom pendant un moment. Ce ne serait pas génial, mais ce n’est pas comme s’ils allaient faire irruption dans mon compte bancaire. Toutefois, compte tenu du fait 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 gérer même ces mots de passe "de faible valeur" -restaurable.
Imaginez que quelqu'un ait commandé la construction d'un grand bâtiment - un bar, par exemple - et que la conversation suivante ait lieu:
Architecte: Pour un bâtiment de cette taille et de cette capacité, vous aurez besoin d'une sortie de secours ici, ici et ici.
Client: Non, c'est trop compliqué et trop coûteux à maintenir, je ne veux pas de portes latérales ni de portes arrière.
Architecte: Monsieur, les issues de secours ne sont pas facultatives, elles sont obligatoires conformément au code de prévention des incendies de la ville.
Client: Je ne vous paie pas pour argumenter. Faites juste ce que j'ai demandé.
L'architecte demande-t-il alors comment construire éthiquement ce bâtiment sans issue de secours?
Dans le secteur du bâtiment et de l’ingénierie, la conversation risque fort de se terminer ainsi:
Architecte: Ce bâtiment ne peut être construit sans issue de secours. Vous pouvez vous adresser à n’importe quel autre professionnel agréé et il vous dira la même chose. Je pars maintenant; rappelez-moi lorsque vous êtes prêt à coopérer
La programmation informatique n'est peut-être pas une profession licenciée , mais les gens semblent souvent se demander pourquoi notre profession ne jouit pas du même respect qu'un ingénieur en génie civil ou en génie mécanique - Eh bien, ne cherchez pas plus loin. Ces professions, lorsqu'elles seront traitées (ou carrément dangereuses), refuseront tout simplement. Ils savent que ce n'est pas une excuse pour dire: "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 appartenez à une société cotée en bourse, mais le fait de stocker les mots de passe sous une forme récupérable vous conduirait à l'échec de plusieurs types d'audit de sécurité. Le problème n’est pas que ce soit difficile pour un "pirate informatique" qui aurait eu accès à votre base de données pour 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 s'en va avec tous les mots de passe et les vend au plus offrant. L'utilisation d'un cryptage asymétrique et le stockage de la clé privée dans une base de données séparée ne permettent absolument pas d'éviter ce scénario. il y aura toujours quelqu'un ayant accès à la base de données privée, ce qui constitue un risque grave pour la sécurité.
Il n'y a pas de moyen éthique ou responsable de stocker les mots de passe sous une forme récupérable. Période.
Vous pouvez chiffrer 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 + du sel. S'il arrive un moment, lorsque le mot de passe doit être restauré en texte brut, vous pouvez le déchiffrer manuellement ou semi-automatiquement avec la clé privée. La clé privée peut être stockée ailleurs et peut en outre être cryptée symétriquement (ce qui nécessitera alors une interaction humaine pour décrypter le mot de passe).
Je pense que cela ressemble en fait à la façon dont fonctionne Agent de récupération Windows .
- Les mots de passe sont stockés cryptés
- Les gens peuvent se connecter sans déchiffrer en texte brut
- 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'abandonne 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 attribué à leurs clients un mécanisme légal de non-répudiation et ils peuvent répudier toute transaction dépendant de ce mot de passe car il n’existe aucun moyen pour le fournisseur de prouver que ils n'ont pas reconstruit le mot de passe et ont mis la transaction par eux-mêmes. Si les mots de passe sont correctement stockés sous forme de résumé plutôt que de texte chiffré, cela est impossible, que le client final ait exécuté la transaction lui-même ou ait manqué à son devoir de vigilance. le mot de passe. Dans les deux cas, la responsabilité lui incombe carrément. 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 éthiquement des mots de passe pour une récupération ultérieure du texte en clair. C'est aussi simple que ça. Même Jon Skeet ne peut pas éthiquement stocker des 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 informatique susceptible de détecter une faille de sécurité dans votre code peut le faire également. 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érables est contraire à la loi. En tout état de cause, ici au Royaume-Uni, la loi sur la protection des données de 1998 (en particulier l’annexe 1 de la partie II du paragraphe 1 de l’annexe 1) oblige les responsables du traitement des données à utiliser les mesures techniques appropriées pour protéger leurs données à caractère personnel préjudice pouvant être causé si les données étaient compromises - ce qui pourrait être considérable pour les utilisateurs qui partagent des mots de passe entre sites. S'ils ont toujours du mal à comprendre que c'est un problème, montrez-leur des exemples concrets, tels que celui-ci .
Le moyen le plus simple de permettre aux utilisateurs de récupérer une connexion consiste à leur envoyer par courrier électronique un lien unique leur permettant de se connecter automatiquement et de les diriger directement vers une page où ils peuvent choisir un nouveau mot de passe. Créez un prototype et montrez-le 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 à voir des poursuites judiciaires et des poursuites à l'encontre des entreprises qui ne parviennent pas à sécuriser correctement les mots de passe de leurs utilisateurs. Exemple: LinkedIn victime d’un recours collectif de 5 millions de dollars ; Sony condamné à une amende de 250 000 £ sur le piratage de données PlayStation . Si je me souviens bien, LinkedIn cryptait en réalité les mots de passe de ses utilisateurs, mais le cryptage utilisé était trop faible pour être efficace.
Après avoir lu cette partie:
Dans une note ci-dessous, j'ai souligné le fait que les sites Web principalement destinés aux personnes âgées, aux personnes ayant une déficience intellectuelle ou aux très jeunes enfants peuvent devenir source de confusion pour les utilisateurs qui leur demandent d'effectuer une routine de récupération de mot de passe sécurisé. Bien que cela puisse sembler simple et banal dans certains cas, certains utilisateurs ont besoin de l’aide supplémentaire d’un technicien de service pour les intégrer au système ou de leur envoyer un message directement par courrier électronique.
Dans de tels systèmes, le taux d'attrition lié à 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 en gardant à l'esprit une telle configuration.
Je me demande si l’une de ces exigences requiert 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 service client "laisse-moi vérifier quelques détails, puis je te donnerai un nouveau mot de passe . La prochaine fois que tu te connecteras vous demandera si vous souhaitez conserver ce mot de passe ou le modifier pour quelque chose dont vous vous souviendrez plus facilement. "
Ensuite, le système est configuré pour savoir quand une réinitialisation de mot de passe a eu lieu et pour afficher un message "Souhaitez-vous conserver le nouveau mot de passe ou en choisir un nouveau".
En quoi est-ce pire pour les moins avertis en informatique que de se faire dire leur ancien mot de passe? Et même si la personne du service clientèle peut avoir des ennuis, la base de données elle-même est beaucoup plus sûre en cas de violation.
Commentez ce qui ne va pas avec ma suggestion et je suggérerai une solution qui fait ce que vous vouliez au départ.
Michael Brooks a parlé plutôt de CWE-257 - du fait que quelle que soit la méthode utilisée, vous (l'administrateur) pouvez toujours récupérer le mot de passe. Alors que diriez-vous de ces options:
- Crypter le mot de passe avec quelqu'un d'autre Clé publique - une autorité externe. De cette façon, vous ne pourrez pas le reconstruire personnellement, et l'utilisateur devra contacter cette autorité externe et demander la récupération de son mot de passe.
- Cryptez le mot de passe à l'aide d'une clé générée à partir d'une seconde phrase secrète. Effectuez ce chiffrement côté client et ne le transmettez jamais en clair au serveur. Ensuite, pour récupérer, effectuez à nouveau le décryptage côté client en régénérant la clé à partir de leur entrée. Certes, cette approche utilise essentiellement un deuxième mot de passe, mais vous pouvez toujours leur dire de l'écrire ou d'utiliser l'ancienne approche de question 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 la stockent avec les instructions dans un coffre-fort, etc. Vous pouvez même renforcer la sécurité en choisissant uniquement de crypter et de fournir certains caractères du mot de passe à la tierce partie interne, de manière à ce qu'ils aient à déchiffrer le mot de passe pour le deviner. il. En fournissant ces caractères à l'utilisateur, ils se souviendront probablement de ce que c'était!
En réponse à cette question, il a été beaucoup question des problèmes de sécurité rencontrés par l'utilisateur, mais je voudrais ajouter une mention des avantages. Jusqu'à présent, je n'ai pas vu n avantage légitime mentionné pour avoir un mot de passe récupérable stocké sur le système. Considère ceci:
- L'utilisateur bénéficie-t-il de recevoir son mot de passe par courrier électronique? Non. Ils bénéficient davantage d'un lien de réinitialisation de mot de passe à usage unique, ce qui leur permettrait, espérons-le, de choisir un mot de passe dont ils se souviendront va.
- Est-ce que l'utilisateur a le droit de voir son mot de passe affiché à l'écran? Non, pour la même raison que ci-dessus; ils devraient choisir un nouveau mot de passe.
- L’utilisateur at-il intérêt à ce qu’une personne de l’assistance communique le mot de passe à l’utilisateur? Non; de nouveau, si la personne de l'assistance considère que la demande de l'utilisateur pour son mot de passe est correctement authentifiée, il est plus dans l'intérêt de l'utilisateur de se voir attribuer un nouveau mot de passe et la possibilité de le modifier. De plus, l'assistance téléphonique est plus coûteuse que la réinitialisation automatique du mot de passe. Par conséquent, la société n'en tire aucun avantage.
Il semble que les seuls à pouvoir bénéficier de mots de passe récupérables sont ceux qui ont une intention malveillante ou ceux qui supportent des API médiocres qui nécessitent un échange de mot de passe tiers (veuillez ne jamais utiliser lesdites API!). Vous pouvez peut-être gagner votre argument en déclarant honnêtement à vos clients que la société 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 s'intéressent même pas à la gestion des mots de passe. Ce qu'ils veulent vraiment, c'est un système d'authentification qui n'est pas si difficile pour leurs utilisateurs. Donc, en plus de leur dire comment ils ne veulent pas de mots de passe récupérables, vous devriez leur proposer des moyens de rendre le processus d'authentification moins pénible, en particulier si vous n'avez pas besoin des niveaux de sécurité élevés d'une banque, par exemple:
- Autoriser l'utilisateur à utiliser son adresse électronique pour son nom d'utilisateur. J'ai vu d'innombrables cas où l'utilisateur oublie son nom d'utilisateur, mais peu oublient leur adresse électronique.
- Offrez OpenID et laissez un tiers payer les frais d’oubli de l’utilisateur.
- Alléger les restrictions de mot de passe. Je suis sûr que nous avons tous été incroyablement ennuyés lorsqu'un site Web n'autorise pas votre mot de passe préféré en raison d'exigences inutiles telles que "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. " De plus, si la facilité d'utilisation est un problème plus important que la force du mot de passe, vous pouvez même assouplir les exigences non-stupides en autorisant des mots de passe plus courts ou en n'exigeant 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.
- Ne pas expirer les mots de passe.
- Autoriser l'utilisateur à réutiliser un ancien mot de passe.
- Permettre à l'utilisateur de choisir sa propre question de réinitialisation de mot de passe.
Mais si, pour une raison quelconque (et s'il vous plaît, indiquez-nous la raison) vraiment, vraiment, vraiment devez pouvoir disposer d'un mot de passe récupérable, vous pouvez empêcher l'utilisateur de compromettre potentiellement ses autres comptes en ligne en: en leur donnant un système d'authentification sans mot de passe. Étant donné que les systèmes de nom d'utilisateur/mot de passe sont déjà familiers et qu'ils constituent une solution bien utilisée, il s'agirait d'un dernier recours, mais il existe sûrement de nombreuses 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.
- Demandez à l'utilisateur de choisir une question avec une réponse courte à laquelle il seul sait la réponse, qui ne changera jamais, qui s'en souviendra toujours et qui ne craint pas que les autres le découvrent.
- Demandez à l’utilisateur de saisir un nom d’utilisateur, puis dessinez une forme facile à mémoriser avec suffisamment de permutation pour vous protéger des suppositions (voir cette photo géniale comment 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 lui attribuer un nom secret. Ils peuvent ensuite être invités à entrer le nom secret de la créature pour se connecter.
Conformément au commentaire que j'ai fait sur la question:
Un point important a été passé sous silence par presque tout le monde ... Ma réaction initiale était très similaire à @Michael Brooks, jusqu’à ce que j’ai réalisé, comme @stefanw, que le problème ici est de répondre aux exigences non satisfaites, mais c’est ce que elles sont.
Mais alors, il m'est venu à l'esprit que cela pourrait même ne pas être le cas! Le point manquant ici est le non-dit valeur 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 excessif et le choix de sécurité incorrect .
Évidemment, pour une banque, les "meilleures pratiques" sont indispensables et il n’ya aucun moyen de violer éthiquement CWE-257. Mais il est facile de penser aux systèmes de faible valeur où cela ne vaut tout simplement pas la peine (mais un simple mot de passe est toujours requis).
Il est important de rappeler que la véritable expertise en matière de sécurité consiste à trouver des compromis appropriés, et non à formuler 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 a une valeur appropriée, sans élément "coûteux" (l'identité lui-même, inclus), ET, il existe des exigences commerciales valables qui rendent impossible un processus approprié (ou suffisamment difficile/coûteux), ET le client est informé de toutes les mises en garde ...
Ensuite, il pourrait être approprié de simplement autoriser un cryptage réversible, sans aucun cerceau particulier à franchir.
Je m'arrête un peu avant de dire de ne pas se soucier du tout du cryptage, car il est très simple/peu coûteux à 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 mise en œuvre il). En outre, il est intéressant de voir comment fournir à l'utilisateur le mot de passe d'origine, que ce soit par courrier électronique, affiché à l'écran, etc.
Puisque l’hypothèse retenue ici est que la valeur du mot de passe volé (même globalement) est assez faible, l’une de ces solutions peut être valide.
Puisqu'il y a une discussion animée, en réalité PLUSIEURS discussions animées, dans les différents messages et dans différents fils de commentaires, je vais ajouter quelques précisions et répondre à 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 en général, une mauvaise idée. Ce n'est pas du tout contesté ...
En outre, je soulignerai que dans beaucoup, et même la plupart des situations - c’est vraiment faux, même grossier, méchant, et laid .
Cependant, le nœud de la question se situe autour de principe, EST-IL NÉCESSAIRE de ne pas être obligé d'interdire cela , et si oui, comment le faire de la manière la plus correcte qui soit adaptée à la situation .
Maintenant, comme @Thomas, @sfussenegger et quelques autres l'ont mentionné, le seul moyen approprié de répondre à cette question est de procéder à une analyse approfondie analyse de risque d'une situation donnée (ou hypothétique), afin de comprendre les enjeux. , 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 les professionnels de la sécurité. Les meilleures pratiques sont bonnes jusqu'à un certain point (généralement en tant que directives pour les inexpérimentés et les hacks), après quoi une analyse de risque réfléchie prend le relais.
C'est drôle, je me suis toujours considéré comme un fanatique de la sécurité, et je suis en quelque sorte de l'autre côté de ces soi-disant "experts en sécurité" ... La vérité c'est - parce que je suis un fanatique, et un véritable expert en sécurité dans la vie réelle - je ne crois pas à la formulation du dogme de la "meilleure pratique" (ou CWE) SANS cela de la plus haute importance analyse de risque.
"Méfiez-vous des zélés de la sécurité qui appliquent rapidement tout ce qui se trouve dans leur ceinture à outils sans savoir à quoi ils s’attaquent. Une sécurité accrue ne veut pas nécessairement dire une bonne sécurité."
L’analyse des risques et les vrais fanatiques de la sécurité indiqueraient un compromis plus intelligent, fondé sur la valeur/le risque, fondé sur le risque, la perte potentielle, les menaces éventuelles, les mesures d’atténuation complémentaires, etc. une analyse des risques solide servant de base à leurs recommandations, ou soutenant des compromis logiques, mais préférant préférer crier dogme et CWE sans même savoir comment effectuer une analyse de risque, ne sont rien d'autre que Security Hacks, et leur expertise ne vaut pas le papier toilette imprimé sur.
En effet, c'est ainsi que nous obtenons le ridicule de la sécurité dans les aéroports.
Mais avant de parler des compromis appropriés à faire dans CETTE SITUATION, jetons un regard sur les risques apparents (apparents, car nous ne disposons pas de toutes les informations de base sur cette situation, nous émettons tous des hypothèses - car la question est de savoir ce que il pourrait y avoir une situation ...)
Supposons un système LOW-VALUE, mais pas aussi important que son accès public - le propriétaire du système veut empêcher l'usurpation d'identité accidentelle, mais une sécurité "élevée" n'est pas aussi importante qu'une facilité d'utilisation. (Oui, c’est un compromis légitime pour ACCEPTER le risque qu’un script-kiddie expérimenté puisse pirater le site ... Attendez, _ n'est pas APT en vogue maintenant??)
À titre d’exemple, disons que j’organise un site simple pour une grande réunion de famille, ce qui permet à tout le monde de réfléchir à la destination de notre voyage de camping cette année. Je suis moins inquiet qu'un pirate informatique anonyme, ou même que notre cousin Fred, répète ses suggestions pour revenir au lac Wantanamanabikiliki, car je crains que tante Erma ne puisse pas se connecter quand 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 souhaite donc supprimer toute friction possible pour elle. Encore une fois, je ne m'inquiète pas des piratages, je ne veux tout simplement pas d'erreurs stupides de connexion erronée - 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 à sens unique?
- Usurper l'identité des utilisateurs? Non, j'ai déjà accepté ce risque, pas intéressant.
- Mauvais administrateur? Eh bien, peut-être ... Mais encore une fois, je ne me soucie pas de savoir si quelqu'un peut usurper l'identité d'un autre utilisateur, INTERNE ou non ... et de toute façon, un administrateur malveillant va obtenir votre mot de passe peu importe ce que vous faites - Si votre administrateur a mal tourné, son jeu est terminé 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! C'est un risque très intéressant, qui nécessite un examen plus approfondi.
Permettez-moi de commencer par affirmer que ce n'est pas le identité qui est partagé, mais plutôt le preuve, ou le justificatif d'authentification. D'accord, puisqu'un mot de passe partagé me permet effectivement d'accéder à un autre système (mon compte bancaire ou gmail, par exemple), il s'agit en fait de la même identité, il s'agit donc d'une simple sémantique ... Sauf que ce n'est pas . L’identité est gérée séparément par chaque système, dans ce scénario (bien qu’il puisse exister des systèmes d’identificateurs tiers, tels que OAuth - mais toujours distincts de l’identité de ce système - pour plus de détails à ce sujet plus tard).
En tant que tel, le principal point de risque ici est que l’utilisateur entrera volontiers son (même) mot de passe dans plusieurs systèmes différents - et maintenant, moi (l’administrateur) ou tout autre pirate informatique de mon site aura accès aux mots de passe de tante Erma pour le site de missile nucléaire.
Hmmm.
Est-ce que quelque chose ici vous semble?
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 incombe la responsabilitéIS? Umm ... Que diriez-vous du système de missiles nucléaires? Duh.
Deuxièmement, si je voulais voler le mot de passe d'une personne (une personne connue pour utiliser de manière répétée le même mot de passe entre des sites sécurisés et des sites moins sécurisés), pourquoi m'ennuierais-je de pirater votre site? Ou aux prises avec votre cryptage symétrique? Goshdarnitall, je peux simplement mettre en place mon propre site Web simple , inviter les utilisateurs à s'inscrire pour recevoir des NOUVELLES TRÈS IMPORTANTES à propos de ce qu'ils veulent ... Puffo Presto, j'ai "volé" leurs mots de passe.
Oui, la formation des utilisateurs revient toujours nous mordre dans la hienie, n'est-ce pas?
Et vous ne pouvez rien y faire. Même si vous DEVEZ hacher leurs mots de passe sur votre site et que vous faites tout ce que la TSA peut penser, vous avez ajouté une protection à leur mot de passe PAS UN. WHIT, s’ils vont continuer à coller leurs mots de passe dans tous les sites où ils se rendent. Ne même pas la peine d'essayer.
En d'autres termes, Vous ne possédez pas leurs mots de passe, alors arrêtez d'essayer d'agir comme vous le faites.
Alors, mes chers experts en sécurité, comme une vieille dame demandait Wendy: "Où 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. C’est 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 représenté) par les opposants ici. Il s’agit de partager l’identité en soi (!), PAS de casser les mots de passe sur des systèmes à faible valeur. Si vous partagez un mot de passe entre un système à faible valeur et un système à valeur élevée, le problème est déjà là!
- Par le point précédent, le point précédent pointerait CONTRE en utilisant OAuth et similaires pour ces deux systèmes de faible valeur, et les systèmes bancaires de grande 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. Pas tout à fait comme les serveurs du blog de votre chat, mais ils ne surpassent 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 ceci de la part de tous les marchands. ce n'est plus vraiment si loin (si la valeur le justifie).
- Pour tous ceux qui se plaignent de ce genre de questions, c'est ce qui fait que la profession de développeur a l'air si mauvaise: ce sont des réponses comme celles-là qui font que la profession de la sécurité semble encore pire. Encore une fois, une analyse des risques centrée sur l'entreprise est nécessaire, sinon vous vous rendez inutile. En plus d'avoir tort.
- J'imagine que c'est la raison pour laquelle ce n'est pas une bonne idée de prendre un développeur régulier et de lui laisser plus de responsabilités en matière de sécurité, sans avoir la formation nécessaire pour penser différemment et pour rechercher les bons compromis. Sans vouloir offenser vos adversaires, je suis tout à fait d'accord, mais davantage d'entraînement est nécessaire.
Ouf. Quel long post ...
Mais pour répondre à votre question initiale, @Shane:
- Expliquez au client la bonne façon de faire les choses.
- S'il persiste, expliquez-en davantage, insistez, discutez. Lancer une crise, si nécessaire.
- Expliquez-lui le risque commercial. Les détails sont bons, les chiffres sont meilleurs, une démonstration en direct est généralement préférable.
- SI IL ENTRAÎNE TOUJOURS, ET présente des raisons commerciales valables - il est temps pour vous de faire appel à votre jugement:
Ce site at-il une valeur faible à nulle? Est-ce vraiment une affaire valable? Est-ce suffisant pour vous? N'y a-t-il aucun autre risque à prendre en compte qui l'emporterait sur les raisons commerciales valables? (Et bien sûr, le client n'est pas un site malveillant, mais c'est duh).
Si c'est le cas, continuez tout droit. Cela ne vaut pas la peine, les frictions et l'utilisation perdue (dans cette situation hypothétique) de mettre en place le processus nécessaire. Toute autre décision (encore une fois, dans cette situation) est un mauvais compromis.
Donc, le résultat final et une réponse concrète - chiffrez-le avec un simple algorithme symétrique, protégez la clé de chiffrement avec des ACL fortes et, de préférence, DPAPI ou similaire, documentez-la et faites signer le client (une personne suffisamment expérimentée pour prendre cette décision). 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 (à modifier dès la première ouverture de session). Laissez ensuite l'utilisateur changer le mot de passe qu'il souhaite (le précédent, s'il le souhaite).
Vous pouvez "vendre" ceci en tant que mécanisme sécurisé pour réinitialiser les mots de passe.
Le seul moyen de permettre à un utilisateur de récupérer son mot de passe d'origine est de le chiffrer avec la clé publique de l'utilisateur. Seul cet utilisateur peut ensuite déchiffrer son mot de passe.
Les étapes seraient donc les suivantes:
- L'utilisateur s'inscrit sur votre site (via SSL bien sûr) sans encore définir de mot de passe. Connectez-les automatiquement ou fournissez un mot de passe temporaire.
- Vous proposez de stocker leur clé publique PGP pour une récupération ultérieure du mot de passe.
- Ils téléchargent leur clé publique PGP.
- Vous leur demandez de définir un nouveau mot de passe.
- Ils soumettent leur mot de passe.
- Vous hachez le mot de passe en utilisant le meilleur algorithme de hachage de mot de passe disponible (par exemple, bcrypt). Utilisez ceci lors de la validation de la prochaine connexion.
- Vous chiffrez le mot de passe avec la clé publique et vous 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 plus pouvoir récupérer son mot de passe à l'avenir (il ne pourra que le réinitialiser avec un mot de passe généré par le service), les étapes 3 et 7 peuvent être ignorées.
Je pense que la vraie question que vous devriez vous poser est la suivante: "Comment puis-je être plus capable de 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, lorsque je dois créer un site Web qui doit stocker des informations confidentielles récupérables, comme une carte de crédit ou un mot de passe, je fais ce qui suit:
- chiffrer avec: openssl_encrypt (chaîne $ data, méthode $ chaîne, chaîne $ mot_passe)
- données arg :
- les informations sensibles (par exemple, le mot de passe de l'utilisateur)
- sérialiser si nécessaire, par ex. si l'information est un tableau de données comme de multiples informations sensibles
- password arg : utilise 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 mère de l'utilisateur
- une chaîne aléatoire envoyée par e-mail et/ou par sms au moment de l'inscription
- méthode arg :
- choisissez une méthode de chiffrement, comme "aes-256-cbc"
- JAMAIS stocke les informations utilisées dans l'argument "mot de passe" dans la base de données (ou à un autre endroit du système)
Lorsque cela est nécessaire pour récupérer ces données, utilisez simplement la fonction "openssl_decrypt ()" et demandez à l'utilisateur de vous répondre. 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 des données stockées dans une 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 encoder 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 à la mémoire). Ce mot de passe en clair ne reste jamais dans la base de données, en effet il reste toujours en mémoire, détruit à la fin de la 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 tel que facebook, Twitter, etc., alors je demande à nouveau le mot de passe au moment de l'achat (ok, ce n'est pas un clic complet) ou j'utilise certaines données du service que cet utilisateur utilisait 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é concerne l’évaluation des risques et se mesure sur un continuum. Les fanatiques de la sécurité détestent penser de cette façon, mais la vérité est que rien n’est parfaitement sécurisé. Les mots de passe hachés avec des exigences strictes en matière de mot de passe, les échantillons d'ADN et les analyses de la rétine sont plus sécurisés, mais au détriment du développement et de l'expérience utilisateur. Les mots de passe en texte brut sont beaucoup moins sécurisés mais sont moins coûteux à mettre en œuvre (mais devraient être évités). En fin de compte, il s’agit d’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 fournit des options à ses clients et, en matière de sécurité, expose les avantages et les risques de toute implémentation. Cela est d'autant plus vrai si le client demande quelque chose qui pourrait le mettre en danger du fait qu'il ne respecte pas les normes de l'industrie. Si un client demande spécifiquement un cryptage bidirectionnel, je vous assurerais de documenter vos objections, mais cela ne devrait pas vous empêcher de mettre en œuvre la solution de la meilleure façon possible. En fin de compte, c'est l'argent du client. Oui, vous devriez faire pression pour utiliser des hachages unidirectionnels, mais dire que c'est absolument le seul choix et que tout ce qui est contraire à l'éthique est un non-sens total.
Si vous stockez des mots de passe avec un cryptage bidirectionnel, la sécurité est au cœur de la gestion des clés. Windows fournit des mécanismes pour limiter l'accès aux clés privées des certificats aux comptes administratifs et aux mots de passe. Si vous hébergez sur d'autres plates-formes, vous devez voir quelles options sont disponibles sur celles-ci. Comme d'autres l'ont suggéré, vous pouvez utiliser le cryptage asymétrique.
À ma connaissance, il n'existe aucune loi (ni la loi sur la protection des données au Royaume-Uni) qui stipule spécifiquement que les mots de passe doivent être stockés à l'aide de hachages unidirectionnels. La seule exigence dans aucune de ces lois est simplement que raisonnable des mesures sont prises pour la sécurité. Si l'accès à la base de données est restreint, même les mots de passe en clair peuvent être qualifiés légalement dans le cadre d'une telle restriction.
Cela met toutefois en lumière un autre aspect: la préséance juridique. Si la priorité légale suggère que vous deviez utiliser des hachages unidirectionnels en fonction du secteur dans lequel votre système est construit, la situation est totalement différente. Ce sont les munitions que vous utilisez pour convaincre votre client. À moins que cela ne soit la meilleure suggestion pour fournir une évaluation des risques raisonnable, documentez vos objections et mettez en œuvre le système de la manière la plus sécurisée possible, compte tenu des exigences du client.
Faites en sorte que la réponse à la question de sécurité de l'utilisateur fasse partie de la clé de chiffrement et ne stockez pas la réponse à la question de sécurité sous forme de texte brut (hash à la place)
J'implémente des systèmes d'authentification à plusieurs facteurs pour gagner ma vie. Il est donc naturel pour moi de penser que vous pouvez réinitialiser ou reconstituer le mot de passe, tout en utilisant temporairement un facteur de moins pour authentifier l'utilisateur uniquement pour le processus de réinitialisation/récréation. L'utilisation de mots de passe à usage unique (mots de passe à usage unique) en tant que facteurs supplémentaires atténue en grande partie le risque si la fenêtre temporelle est courte pour le flux de travail suggéré. Nous avons implémenté des générateurs de logiciels OTP pour smartphones (que la plupart des utilisateurs ont déjà avec eux toute la journée) avec beaucoup de succès. Avant de se plaindre d'une fiche commerciale, ce que je dis, c'est que nous pouvons réduire les risques inhérents à la possibilité de 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. Je concède que pour la réutilisation des mots de passe entre les sites, la situation n’est toujours pas satisfaisante, car l’utilisateur insiste pour conserver le mot de passe original car il/elle souhaite ouvrir les autres sites également, mais vous pouvez essayer de fournir le mot de passe reconstitué. le moyen le plus sûr possible (htpps et apparence discrète sur le code HTML).
Je viens de tomber sur cette discussion intéressante et animée. Ce qui m'a le plus surpris, cependant, est le peu d’attention accordée à la question fondamentale suivante:
- Q1. Quelles sont les raisons pour lesquelles l'utilisateur insiste pour avoir accès à un mot de passe stocké en texte brut? Pourquoi a-t-il tant de valeur?
Les informations selon lesquelles les utilisateurs sont âgés ou jeunes ne répondent pas vraiment à cette question. Mais comment une décision commerciale peut-elle être prise sans comprendre correctement 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 terriblement difficile à utiliser, alors peut-être que le fait de remédier à la cause exacte résoudrait le problème?
Comme je n’ai pas cette information et que je ne peux pas parler à ces clients, je ne peux que deviner: c’est une question 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 la réponse possible. Si vous avez un chat appelé "miaumiau" et que vous avez utilisé son nom comme mot de passe mais que vous l'avez oublié, préféreriez-vous qu'on lui rappelle ce que c'était ou plutôt que quelque chose comme "# zy * RW (ew") lui soit envoyé?
Une autre raison possible est que l'utilisateur considère qu'il est difficile de trouver un nouveau mot de passe! Ainsi, le retour de l'ancien mot de passe donne l'illusion de la sauver de ce travail pénible.
J'essaie juste de comprendre la raison. Mais quelle que soit la raison, c'est la raison et non la cause à laquelle il faut s'attaquer.
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 des journaux, je souhaite taper 1111 comme mot de passe et être connecté !!!
Je sais que cela n'est pas sûr, mais qu'en est-il 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 sur un utilisateur authentifié? Alors ne le montre pas en premier lieu!
Ceci est juste pour démontrer l'attitude de l'utilisateur vis-à-vis du problème.
Donc, pour résumer, je ne pense pas que le problème soit de savoir comment stocker "en toute sécurité" les mots de passe en texte brut (ce qui est impossible, à notre connaissance), mais plutôt de répondre aux préoccupations réelles des clients.
Désolé, mais tant que vous avez un moyen de déchiffrer leur mot de passe, il est impossible que ce soit sécurisé. Combattez-le amèrement, et si vous perdez, CYA.
Traitement des mots de passe perdus/oubliés:
Personne ne devrait jamais être capable de récupérer des mots de passe.
Si les utilisateurs ont oublié leur mot de passe, ils doivent au moins connaître leur nom d'utilisateur ou leur adresse électronique. Sur demande, générez un GUID dans la table Utilisateurs et envoyez un courrier électronique contenant un lien contenant le GU en tant que paramètre de l'adresse de messagerie de l'utilisateur.
La page située derrière le lien vérifie que le paramètre guid existe vraiment (probablement avec une logique de délai d'attente) et demande à l'utilisateur un nouveau mot de passe.
Si vous avez besoin d'aide pour les utilisateurs de la hotline, ajoutez des rôles à votre modèle d'attribution et laissez le rôle de hotline se connecter temporairement en tant qu'utilisateur identifié. Connectez-vous à toutes ces connexions hotline. Par exemple, Bugzilla offre une telle fonctionnalité d'emprunt d'identité aux administrateurs.
Si vous ne pouvez pas simplement rejeter l'obligation de stocker des mots de passe récupérables, pourquoi ne pas en faire 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 électronique pour définir les préférences de l'utilisateur, mais c'est à peu près tout. Utilisez un cookie pour extraire automatiquement vos préférences lors de vos prochaines visites et jetez les données après un délai raisonnable.
La seule option souvent négligée dans la stratégie de mot de passe consiste à déterminer si un mot de passe est vraiment nécessaire. Si votre stratégie de mot de passe ne fait que provoquer des appels au service clientèle, vous pouvez peut-être vous en débarrasser.
Qu'en est-il d'envoyer par courrier électronique le mot de passe en texte brut au moment de l'enregistrement, avant qu'il ne soit crypté et perdu? J'ai vu beaucoup de sites Web le faire, et obtenir le mot de passe de la messagerie de l'utilisateur est plus sécurisé que de le laisser sur votre serveur/comp.
Les utilisateurs vraiment doivent-ils récupérer (par exemple, le mot de passe) 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 la connexion, pourquoi ne pas créer une routine qui remplace simplement l’ancien mot de passe (quel qu’il soit) par 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 l'assistance 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 consignées quelque part et la bonne pratique consiste à envoyer un courrier électronique à l'utilisateur pour l'informer que le mot de passe a été réinitialisé.
Une autre possibilité consiste à avoir deux mots de passe simultanés permettant l'accès à un compte. Le premier est le mot de passe "normal" géré par l'utilisateur et l'autre ressemble à un squelette/clé principale connu uniquement par le support technique et identique pour tous les utilisateurs. Ainsi, lorsqu'un utilisateur a un problème, le service d'assistance peut se connecter au compte avec la clé principale et l'aider à changer son mot de passe. Il va sans dire que toutes les connexions avec la clé principale doivent également être enregistrées par le système. En guise de mesure supplémentaire, chaque fois que la clé principale est utilisée, vous pouvez également valider les informations d'identification du support.
-EDIT- En réponse aux commentaires sur le fait de ne pas avoir de clé principale: je conviens que c'est mauvais tout comme je crois qu'il est mauvais de permettre à une personne autre que l'utilisateur d'avoir accès au compte de l'utilisateur. Si vous examinez la question, le principe est que le client a imposé un environnement de sécurité hautement compromis.
Une clé principale n'a pas besoin d'être aussi mauvaise qu'il y paraît. J'avais l'habitude de travailler dans une usine de défense où ils percevaient 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 ignorait), il a fallu ouvrir l'enveloppe. À chaque changement de quart, l’un des emplois du superviseur de quart consistait à vérifier si l’enveloppe avait été ouverte et, le cas échéant, de changer immédiatement le mot de passe (par un autre service) et de placer le nouveau mot de passe dans une nouvelle enveloppe. à nouveau. L'opérateur serait interrogé sur les raisons pour lesquelles il l'avait ouvert et l'incident serait consigné au dossier.
Bien que ce ne soit pas une procédure que je concevrais, elle fonctionnait et permettait une excellente responsabilisation. Tout était enregistré et examiné, plus tous les opérateurs avaient des autorisations secrètes du DOD et nous n'avions 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 étaient immédiatement licenciés et passibles de poursuites pénales.
Donc, je suppose que la vraie réponse est que si l'on veut bien faire les choses, on recrute des personnes en qui ils peuvent avoir confiance, on vérifie les antécédents et on exerce une surveillance et une responsabilisation appropriées de la direction.
Mais encore une fois si le client de ce pauvre type avait une bonne gestion, ils n'auraient pas demandé une telle solution de sécurité compromise en premier lieu, le feraient-ils maintenant?
D'après le peu que je comprends à ce sujet, je pense que si vous construisez un site Web avec un code d'accès/mot de passe, vous ne devriez même pas voir le mot de passe en texte brut sur votre serveur. Le mot de passe doit être haché et probablement salé avant même de quitter le client.
Si vous ne voyez jamais le mot de passe en texte en clair, la question de la récupération ne se pose pas.
De plus, je suppose (à partir du 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.
Salez et hachez le mot de passe de l'utilisateur comme d'habitude. Lors de la connexion de l'utilisateur, autorisez le mot de passe de l'utilisateur (après le salage/le hachage), mais autorisez également ce que l'utilisateur a littéralement entré pour qu'il corresponde.
Cela permet à l'utilisateur de saisir son mot de passe secret, mais également la version corrigée/hachée de son mot de passe, ce que quelqu'un lirait dans la base de données.
Fondamentalement, faites en sorte que le mot de passe salted/hashed soit également un mot de passe "texte brut".
Une autre option que vous n'avez peut-être pas envisagée consiste à autoriser des actions par courrier électronique. C’est un peu lourd, mais j’ai implémenté cela pour un client qui avait besoin d’utilisateurs "extérieurs" à son système pour visualiser (lire seulement) certaines parties du système. Par exemple:
- Une fois qu'un utilisateur est enregistré, il dispose d'un accès complet (comme un site Web classique). L'inscription doit inclure un email.
- 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 exécuter l'action en cliquant sur un bouton spécial "écrivez-moi pour obtenir l'autorisation", juste à côté du bouton "- soumettre "bouton".
- 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 de courrier électronique de réinitialisation de mot de passe, mais au lieu de réinitialiser le mot de passe, il exécute action unique.
- L'utilisateur clique ensuite sur "Oui" et 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 le courrier électronique est compromis, mais cela répond au commentaire de @joachim sur le fait de ne pas vouloir réinitialiser le mot de passe. Finalement, ils devront utiliser la réinitialisation du mot de passe, mais ils pourront le faire à un moment plus opportun, ou avec l'assistance d'un administrateur ou d'un ami, si nécessaire.
Une variante de cette solution consisterait à envoyer la demande d'action à un administrateur de confiance tiers. Cela fonctionnerait mieux dans les cas avec des utilisateurs âgés, ayant une déficience intellectuelle, des utilisateurs très jeunes ou confus. Bien entendu, cela nécessite un administrateur de confiance pour que ces personnes prennent en charge leurs actions.
ouvrez une base de données sur un serveur autonome et établissez une connexion distante chiffrée avec chaque serveur Web nécessitant 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.
Si vous le pouvez, accordez aux serveurs Web des autorisations en écriture seulement.
Stockez le cryptage non récupérable du mot de passe dans la base de données du site (appelons-le "pass-a") comme le font les gens normaux :)
sur chaque nouvel utilisateur (ou changement de mot de passe) stocke une copie brute du mot de passe dans la base de données distante. utilisez l'identifiant du serveur, l'identifiant de l'utilisateur et le mot de passe "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 puisse obtenir à la fois le mot de passe et son contexte (identifiant de site + identifiant d'utilisateur + "pass-a"), il doit:
- pirater la base de données du site Web pour obtenir une ou plusieurs paires ("pass-a", identifiant utilisateur).
- récupère l'identifiant du site à partir d'un fichier de configuration
- trouver et pirater les mots de passe distants DB.
vous pouvez contrôler l’accessibilité du service de récupération de mot de passe (exposez-le uniquement en tant que service Web sécurisé, autorisez uniquement un certain nombre de récupérations de mots de passe par jour, faites-le manuellement, etc.), et même facturez un supplément pour cet "accord de sécurité spécial".
La base de données de récupération des mots de passe est assez cachée car elle ne sert pas à beaucoup de fonctions et peut être mieux sécurisée (vous pouvez personnaliser les autorisations, les processus et les services).
dans l’ensemble, vous simplifiez le travail du pirate informatique. le risque de violation de la sécurité sur un seul serveur est toujours le même, mais des données significatives (une correspondance de compte et de mot de passe) seront difficiles à assembler.