Comment dois-je aborder sur le plan éthique de stockage de mot de passe utilisateur pour la récupération de texte en clair plus tard?

https://stackoverflow.com/questions/2283937

21-09-2019
|

Question

Alors que je continue à construire de plus en plus de sites Web et les applications Web que je suis souvent demandé aux mots de passe de l'utilisateur de stocker d'une manière qu'ils peuvent être récupérés si / lorsque l'utilisateur a un problème (soit par courriel un lien mot de passe oublié, marcher les à travers au téléphone, etc.) Quand je peux je me bats amèrement contre cette pratique et je fais beaucoup de programmation « extra » pour faire des réinitialisations de mots de passe et l'assistance administrative possible sans enregistrer leur mot de passe réel.

Quand je ne peux pas combattre (ou ne peut pas gagner) alors j'encoder toujours le mot de passe d'une certaine façon à ce que, au moins, ne sont pas stockées comme dans la base de données plaintext-même si je suis conscient que si mon DB est piraté, il ne prendrait pas beaucoup pour le coupable à se fissurer les mots de passe, ce qui me rend mal à l'aise.

Dans les gens du monde parfait serait de mettre à jour les mots de passe fréquemment et ne pas les reproduire dans de nombreux sites, malheureusement, je connais des gens beaucoup qui ont le même travail / home / email / mot de passe bancaire, et ont même donné librement à moi quand ils ont besoin assistance. 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.

vue moral et éthique, je me sens responsable de la protection que peut-être, pour certains utilisateurs, leur gagne-pain, même s'ils traitent avec respect beaucoup moins. Je suis certain qu'il existe de nombreuses possibilités d'aborder et des arguments à faire pour le salage hash et différentes options d'encodage, mais est-il un « meilleures pratiques » lorsque vous devez les stocker? Dans presque tous les cas, je suis en utilisant PHP et MySQL si cela fait une différence dans 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 voulez avoir à faire et que, dans la plupart des cas où le refus de le faire est le meilleur. Je suis, cependant, pas à la recherche d'une conférence sur le bien-fondé de cette approche que je cherche les meilleures mesures à prendre si vous ne prenez cette approche.

Dans une note ci-dessous j'ai fait remarquer que les sites Web orientés vers les personnes âgées en grande partie, des difficultés mentales, ou très jeune peut devenir source de confusion pour les gens quand ils sont invités à effectuer une routine de récupération de mot de passe sécurisé. Bien que nous puissions le trouver simple et banal dans ces cas, certains utilisateurs ont besoin de l'aide supplémentaire soit avoir une aide technique de service les dans le système ou l'avoir envoyé par courrier électronique / affiché directement.

Dans de tels systèmes, le taux d'attrition de ces données démographiques pourrait entraver l'application si les utilisateurs n'ont pas eu ce niveau d'aide d'accès, donc s'il vous plaît répondre à une telle configuration à l'esprit.

Merci à tous

Cela a été une question amusante avec beaucoup de débat et je l'ai apprécié. En fin de compte, je choisi une réponse à la fois conserve la sécurité par mot de passe (je ne veux pas garder les mots de passe du texte ou récupérables ordinaire), mais permet également à la base d'utilisateurs que j'ai spécifié pour se connecter à un système sans les inconvénients majeurs que j'ai trouvé de récupération normale de mot de passe.

Comme toujours il y avait environ 5 réponses que je voudrais avoir marqué comme correct pour des raisons différentes, mais je devais choisir le meilleur - tout le reste a un +1. Merci à tous!

En outre, grâce à tout le monde dans la communauté Stack qui ont voté pour cette question et / ou il a marqué en tant que favori. Je prends frapper 100 des votes comme un compliment et nous espérons que cette discussion a aidé quelqu'un d'autre avec le même souci que moi.

La solution

Que diriez-vous de prendre une autre approche ou de l'angle à ce problème? Demandez pourquoi le mot de passe doit être clair: si elle est pour que l'utilisateur peut récupérer le mot de passe, à proprement parler, vous ne avez pas vraiment besoin de récupérer le mot de passe ils ont mis (ils ne se souviennent pas de ce qu'il est 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'ils ont oublié. Dans ce cas, un nouveau mot de passe est tout aussi bon que l'ancien. Mais, l'un des inconvénients des mécanismes de réinitialisation de mot de passe couramment utilisé aujourd'hui est que les mots de passe générés produites dans une opération de remise à zéro sont généralement un tas de caractères aléatoires, ils sont 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 les mots de passe générés automatiquement qui sont plus ou moins texte en langage naturel. Alors que les chaînes de langage naturel pourraient ne pas avoir l'entropie qu'une chaîne de caractères aléatoires de la même longueur a, il n'y a rien qui dit que votre mot de passe généré automatiquement doit avoir seulement 8 (ou 10 ou 12) caractères. Obtenir un mot de passe généré automatiquement à haute entropie en enchaînant plusieurs mots aléatoires (laisser un espace entre eux, donc ils sont encore reconnaissables et typable par tous ceux qui peuvent lire). Six mots aléatoires de longueur variable sont probablement plus faciles à taper correctement et avec confiance de 10 caractères aléatoires, et ils peuvent avoir une entropie plus aussi bien. Par exemple, l'entropie d'un mot de passe de 10 caractères choisis au hasard parmi les majuscules, minuscules, chiffres et signes de ponctuation 10 (pour un total de 72 symboles valides) aurait une entropie de 61,7 morceaux. L'utilisation d'un dictionnaire de mots 7776 (comme Diceware utilise) qui pourrait être choisi au hasard pour un mot de passe de six mots, le mot de passe aurait une entropie de 77,4 morceaux. Voir Diceware FAQ pour plus d'informations.

un mot de passe avec environ 77 bits d'entropie: "admettre la table évasé prose flair aigu"
un mot de passe avec environ 74 bits d'entropie: "K: & $ R ^ tt ~ QKD"

Je sais que je préfère taper la phrase, et l'expression est pas moins facile avec copie-n-pâte, d'utiliser le mot de passe que ce soit, donc pas de perte là. Bien sûr, si votre site Web (ou quel que soit l'actif protégé est) n'a pas besoin de 77 bits d'entropie pour un mot de passe généré automatiquement, générer moins de mots (dont je suis sûr que vos utilisateurs apprécieraient).

Je comprends les arguments qu'il ya un mot de passe actifs protégés qui n'ont pas vraiment un haut niveau de valeur, de sorte que la violation d'un mot de passe peut-être pas la fin du monde. Par exemple, je ne serais probablement pas de soins si 80% des mots de passe que j'utilise sur divers sites Web a été violé: tout ce qui pourrait arriver est une personne spamming ou l'affichage sous mon nom pendant un certain temps. Ce ne serait pas grand, mais il est pas comme ils seraient effraction dans mon compte bancaire. Cependant, compte tenu du fait que beaucoup de gens utilisent le même mot de passe pour leurs sites de forum web comme ils le font pour leurs comptes bancaires (et les bases de données de sécurité probablement nationales), je pense qu'il serait préférable de traiter même les mots de passe « faible valeur » comme non -recoverable.

Autres conseils

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 la capacité, vous aurez besoin du feu sort ici, ici et ici Client:. Non, c'est trop compliqué et coûteux à entretenir, je ne veux pas de portes latérales ou de portes arrière Architecte:. Monsieur, les sorties de secours ne sont pas facultatifs, ils sont obligatoires selon le code d'incendie de la ville Client: Je ne suis pas vous payer pour disputez. Il suffit de faire ce que je demandais.

L'architecte puis demander comment construire ce bâtiment éthique sans sorties de secours?

Dans le secteur de la construction et l'ingénierie, la conversation est le plus susceptible de mettre fin à ceci:

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

La programmation informatique ne peut pas être sous licence profession, mais les gens semblent souvent se demander pourquoi notre profession ne soit pas le même respect comme ingénieur civil ou mécanique - bien, ne cherchez pas plus loin. Ces professions, quand les déchets remis (ou carrément dangereux) les exigences, seront tout simplement refuser. Ils savent que ce n'est pas une excuse pour dire: « Eh bien, je l'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 oui ou non vous ou vos clients font partie de toute société cotée en bourse, mais le stockage des mots de passe sous quelque forme que recouvrable vous faire échouer plusieurs différents types d'audits de sécurité. La question est comment il serait difficile pour un « hacker » qui a 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. Ce que vous devez protéger contre certains est employé mécontent de marche profiter de toutes les mots de passe et de les vendre au plus offrant. En utilisant le chiffrement asymétrique et le stockage de la clé privée dans une base de données séparée ne fait rien pour empêcher ce scénario; il y a toujours d'être quelqu'un avec accès à la base de données privée, et c'est un sérieux risque de sécurité.

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

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

Je pense que cela est en fait assez similaire à la façon dont le agent Windows Recovery fonctionne.

Mots de passe sont stockés chiffrés
Les gens peuvent se connecter sans à déchiffrer PlainText
Les mots de passe peuvent être récupérés sur Plaintext, mais seulement avec une clé privée, qui peuvent être stockés en dehors du système (dans une banque sûre, si vous voulez).

Ne pas abandonner. L'arme que vous pouvez utiliser pour convaincre vos clients est non répudiabilité. Si vous pouvez reconstituer les mots de passe de l'utilisateur via un mécanisme, vous avez donné leurs clients un mécanisme non-répudiation juridique et ils peuvent rejeter toute transaction qui dépend de ce mot de passe, parce qu'il n'y a aucun moyen le fournisseur peut prouver que ils ne reconstituent le mot de passe et de mettre la transaction par eux-mêmes. Si les mots de passe sont correctement stockés en tant que digests plutôt cryptogramme, cela est impossible, ergo soit client final exécuté la transaction lui-même ou a manqué à son devoir de diligence w.r.t. le mot de passe. Dans les deux cas qui laisse la responsabilité carrément avec lui. J'ai travaillé sur les cas où cela équivaudrait à des centaines de millions de dollars. Pas quelque chose que vous voulez vous méprenez pas.

Vous ne pouvez pas les mots de passe sur le plan éthique de magasin pour la récupération plus tard plaintext. C'est aussi simple que ça. Même Jon Skeet peut pas les mots de passe sur le plan éthique de magasin pour la récupération plus tard plaintext. Si vos utilisateurs peuvent récupérer des mots de passe en texte brut ou d'autres, en quelque sorte alors potentiellement si un hacker peut aussi qui trouve une faille de sécurité dans votre code. Et ce n'est pas simplement le mot de passe de l'utilisateur d'un être compromis, mais tous.

Si vos clients ont un problème avec cela, dites-leur que le stockage des mots de passe est contraire à la loi récupérable. 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) exige que les contrôleurs de données à utiliser les mesures techniques appropriées pour conserver les données personnelles en sécurité, en tenant compte, entre autres, la des dommages qui pourraient être causés si les données ont été compromises - qui pourrait être considérable pour les utilisateurs qui partagent des mots de passe entre les sites. S'ils ont encore du mal grokking le fait qu'il est un problème, les pointer vers des exemples concrets, tels que celui-ci .

La façon la plus simple pour permettre aux utilisateurs de récupérer une connexion est de les envoyer par courriel un lien unique qui les enregistre automatiquement et les amène à une page droite où ils peuvent choisir un nouveau mot de passe. Créer un prototype et montrer en action pour eux.

Voici quelques messages de blog je l'ai écrit sur le sujet:

Mise à jour: nous commençons à voir des procès et des poursuites contre les entreprises qui ne parviennent pas à obtenir les mots de passe de leurs utilisateurs correctement. Exemple: LinkedIn a giflé avec procès d'action de classe 5 millions $ ; Sony condamné à une amende de £ 250,000 sur les données PlayStation pirater . Si je me souviens bien, LinkedIn a été en fait les mots de passe crypte de ses utilisateurs, mais le cryptage qu'il utilisait était trop faible pour être efficace.

Après avoir lu cette partie:

Dans une note ci-dessous, je fait le point   sites orientés principalement vers la   personnes âgées, handicapés mentaux, ou très   jeune peut devenir source de confusion pour les   quand ils sont invités à effectuer une   routine sécurisée de récupération de mot de passe.   Bien que nous puissions le trouver simple et   banal dans ces cas, certains utilisateurs ont besoin   l'aide supplémentaire soit ayant   les aider un technicien de service dans la   système ou de l'avoir envoyé / affichée   directement.

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

Je suis à me demander si l'une de ces exigences mandatent un système de mot de passe permettant la récupération. 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 de service à la clientèle « laissez-moi vérifier quelques détails et je vais vous donner un nouveau mot de passe . Lorsque votre prochaine connexion, il vous demandera si vous voulez garder ce mot de passe ou changer pour quelque chose que vous pouvez rappeler plus facilement. "

Ensuite, le système est mis en place pour savoir quand une réinitialisation de mot de passe est arrivé et affiche un « voulez-vous garder le nouveau mot de passe ou choisir un nouveau » message.

Comment est-ce pire pour les moins alphabétisés PC que d'être dit leur ancien mot de passe? Et alors que la personne de service à la clientèle peut se lever au mal, la base de données elle-même est beaucoup plus sûre dans le cas où il est violé.

Commentaire ce qui est mauvais sur ma suggestion et je vais vous proposer une solution qui ne fait ce que vous vouliez au départ.

Michael Brooks a été plutôt loquaces 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 ces options:

Chiffrer le mot de passe avec quelqu'un d'autre clé publique - une autorité extérieure. De cette façon, vous ne pouvez pas reconstruire personnellement, et l'utilisateur devra se rendre à cette autorité extérieure et demander que leur mot de passe récupéré.
Chiffrer le mot de passe à l'aide d'une clé générée à partir d'un deuxième mot de passe. Pour ce faire, le cryptage côté client et ne jamais transmettre en clair au serveur. Ensuite, pour récupérer, faire le nouveau décryptage côté client en re-générer la clé de leur entrée. Certes, cette approche utilise essentiellement un second mot de passe, mais vous pouvez toujours leur dire de l'écrire, ou utiliser l'ancienne approche 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 de tenir la clé privée. Assurez-vous qu'ils génèrent eux-mêmes la clé, et de le stocker avec des instructions dans un coffre-fort, etc. Vous pouvez même ajouter de la sécurité en choisissant de ne chiffrer et fournir certains caractères du mot de passe au tiers interne de sorte qu'ils auraient à craquer le mot de passe de deviner il. La fourniture de ces personnages à l'utilisateur, ils se souviendront sans doute ce qu'il était!

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

Est-ce que le bénéfice de l'utilisateur d'avoir leur mot de passe envoyé par courriel à eux? Non, ils reçoivent plus d'avantages d'un temps d'utilisation lien de réinitialisation de mot de passe, qui nous l'espérons leur permettre de choisir un mot de passe qu'ils rappelez-vous.
Est-ce que le bénéfice de l'utilisateur d'avoir leur mot de passe affiché sur l'écran? Non, pour la même raison que ci-dessus; ils doivent choisir un nouveau mot de passe.
L'avantage pour l'utilisateur d'avoir une personne de soutien parler le mot de passe à l'utilisateur? Non; à nouveau, si la personne de soutien estime pour leur mot de passe correctement authentifié la demande de l'utilisateur, il est plus à l'avantage de l'utilisateur à donner un nouveau mot de passe et la possibilité de le changer. De plus, l'assistance téléphonique est plus coûteux que les réinitialisations de mot de passe automatique, de sorte que la société ne bénéficie pas également.

Il semble que les seuls qui peuvent bénéficier de mots de passe sont récupérables ceux avec une intention malveillante ou les partisans de pauvres API nécessitant l'échange de mots de passe tiers (s'il vous plaît ne pas utiliser lesdites API jamais!). Peut-être que vous pouvez gagner votre argument en disant la vérité à vos clients que les gains de l'entreprise sans avantages et passifs seulement en stockant les 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 en fait même se soucient du tout sur la façon dont les mots de passe sont gérés. Ce qu'ils veulent vraiment est un système d'authentification ce n'est pas si difficile pour leurs utilisateurs. Donc, en plus de leur dire comment ils ne veulent pas réellement les mots de passe récupérables, vous devez leur offrir des moyens de rendre le processus d'authentification moins douloureux, surtout si vous ne avez pas besoin des niveaux de sécurité lourdes, par exemple, une banque:

Permettre à l'utilisateur d'utiliser leur adresse e-mail pour leur nom d'utilisateur. Je l'ai vu de nombreux cas où l'utilisateur oublie son nom d'utilisateur, mais peu oublier leur adresse e-mail.
Offre et laisser un qu'OpenID tiers à payer les coûts de l'oubli de l'utilisateur.
Facilité de restrictions sur les mots de passe. Je suis sûr que nous avons tous été très ennuyé quand un site web ne permet pas votre mot de passe préféré en raison des exigences inutiles comme « vous ne pouvez pas utiliser des 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 une plus grande préoccupation que la force de mot de passe, vous pouvez desserrez même les exigences non stupides en permettant des mots de passe plus ou moins ne nécessitant pas un mélange de classes de personnages. Avec les restrictions desserrés, les utilisateurs seront plus susceptibles d'utiliser un mot de passe qu'ils n'oublieront pas.
Ne pas expirer les mots de passe.
Permettre à l'utilisateur de réutiliser un ancien mot de passe.
Permettre à l'utilisateur de choisir leur propre question de réinitialisation du mot de passe.

Mais si vous, pour une raison quelconque (et s'il vous plaît nous dire la raison) vraiment, vraiment, vraiment doivent être en mesure d'avoir un mot de passe recouvrable, vous pouvez protéger l'utilisateur de potentiellement compromettre leur autre comptes en ligne en leur donnant un système d'authentification par mot de passe non. Parce que les gens sont déjà familiarisés avec les systèmes nom d'utilisateur / mot de passe et 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 de choisir une broche numérique, de préférence à 4 chiffres, et de préférence seulement si les tentatives de force brute sont protégés contre.
Demandez à l'utilisateur de choisir une question avec une réponse courte que seulement ils connaissent la réponse, ne changera jamais, ils se souviendront toujours, et ils ne me dérange pas d'autres personnes à trouver.
l'utilisateur à saisir un nom d'utilisateur, puis dessiner une forme facile à retenir avec suffisamment permutations de protection contre deviner (voir cette photo nifty de la façon dont le G1 fait pour déverrouiller le téléphone).
Pour un site Web pour les enfants, vous pouvez générer automatiquement une créature floue basée sur le nom d'utilisateur (un peu comme un Identicon) et demander à l'utilisateur de donner la créature un nom secret. Ils peuvent alors être invités à entrer le nom secret de la créature pour se connecter.

Aux termes du commentaire que je fait sur la question:
Un point important a été très passé sous silence par presque tout le monde ... Ma première réaction a été très similaire à Brooks @ Michael, jusqu'à ce que je pris conscience, comme @stefanw, que la question ici est exigences cassé, mais ce sont ce qu'ils sont.
Mais alors, il me est survenue à ce qui pourrait même ne pas être le cas! Le point manquant ici, est le non-dit valeur des actifs de l'application. Pour parler simplement, pour un système à faible valeur, un mécanisme d'authentification entièrement sécurisée, avec tout le processus en cause, serait exagéré, et le mauvais choix de sécurité.
Il est évident que, pour une banque, les « meilleures pratiques » sont un must, et il n'y a aucun moyen de violer le plan éthique CWE-257. Mais il est facile de penser à des systèmes à faible valeur où il est tout simplement pas la peine (mais un simple mot de passe est toujours nécessaire).

Il est important de se rappeler, une véritable expertise en matière de sécurité est de trouver des compromis appropriés, pas dans jaillissant dogmatiquement les « meilleures pratiques » que tout le monde peut lire en ligne.

En tant que tel, je propose une autre solution:
En fonction de la valeur du système, et SEULEMENT SI le système est suffisamment faible valeur sans atout « coûteux » (l'identité elle-même, inclus), il sont valables exigences commerciales qui rendent processus impossible dans (ou suffisamment difficile / coûteux), le client est informé de toutes les mises en garde ...
Ensuite, il pourrait être approprié de permettre simplement un cryptage réversible, sans cerceaux spéciaux pour sauter à travers.
J'arrête juste avant de dire de ne pas se soucier de cryptage du tout, car il est très simple / pas cher à mettre en œuvre (même compte tenu de la gestion des clés passible), et il offre une certaine protection (plus que le coût de mise en œuvre). En outre, la peine de regarder comment fournir à l'utilisateur le mot de passe d'origine, que ce soit par courrier électronique, l'affichage sur l'écran, etc.
Depuis l'hypothèse est que la valeur du mot de passe volé (même au total) est assez faible, l'une de ces solutions peuvent être valides.

Comme il y a une discussion animée en cours, en fait plusieurs discussions animées, dans les différents postes et les fils de commentaires séparés, je vais ajouter quelques éclaircissements et de répondre à quelques-uns 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 le mot de passe permettant origine de l'utilisateur à récupérer, est une mauvaise pratique, et généralement pas une bonne idée. Ce n'est pas du tout en litige ...
En outre, je souligne que, dans beaucoup, voire PLUPART, des situations - il est vraiment mauvais, même faute, méchant , ET laid.

Cependant, le point crucial de la question est autour de le principe , Y at-il une situation où il pourrait ne pas être nécessaire pour interdire cela, et si oui, comment faire donc de la manière la plus correcte approprié à la situation .

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

Tu sais, il est drôle - je me suis toujours considéré comme l'un des fanatiques de sécurité, et en quelque sorte, je suis sur le 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 expert de la sécurité de la vie réelle réelle - je ne crois pas en jaillissant dogme « Best Practice » (ou CWE) SANSque tous importants l'analyse des risques .
« Méfiez-vous le Zélote de sécurité qui est rapide à appliquer tout dans leur ceinture à outils sans savoir ce que la question réelle est qu'ils défendent contre. Plus de sécurité ne correspond pas nécessairement à une bonne sécurité. »
L'analyse des risques, et les vrais fanatiques de sécurité, se pointer vers une solution plus intelligente, la valeur / risque basé compromis entre, en fonction du risque, la perte potentielle, les menaces possibles, atténuations complémentaires, etc. Tous « Expert sécurité » qui ne peut pas pointer son analyse des risques comme base de leurs recommandations, ou soutenir des compromis logiques, mais serait plutôt préférer bec dogme et CWE sans même comprendre comment effectuer une analyse des risques, ne sont rien d'autre que la sécurité Hacks, et leur expertise ne vaut pas le papier toilette ils ont imprimé sur.

En effet, c'est la façon dont nous obtenons la sécurité qui est ridicule aéroport.

Mais avant de parler des compromis appropriés pour faire dans cette situation, nous allons jeter un regard sur les risques apparents (apparents, parce que nous n'avons pas toutes les informations de base sur cette situation, nous sommes tous d'hypothèses - puisque la question est ce que la situation hypothétique pourrait-il y avoir ...)
Supposons un système de faible valeur, mais pas si trival que c'est l'accès du public - le propriétaire du système veut éviter l'usurpation d'identité occasionnelle, mais la sécurité « haut » n'est pas aussi primordiale que la facilité d'utilisation. (Oui, il est un compromis légitime à courir le risque que tout script kiddie compétent peut pirater le site ... Attendez, n'est pas APT en vogue maintenant ...?)
Juste par exemple, disons que je suis arranger un site simple pour une grande réunion de famille, permettant à chacun de réfléchir à l'endroit où nous voulons aller sur notre voyage de camping cette année. Je suis moins inquiet pour un pirate, ou même cousin Fred serrant des suggestions répétées de revenir au lac Wantanamanabikiliki, comme je suis sur le point tante Erma ne pas être en mesure d'ouvrir une session anonyme quand elle a besoin. Maintenant, ma tante Erma, étant un physicien nucléaire, n'est pas très bon souvenir des mots de passe, ou même avec l'utilisation des ordinateurs du tout ... Je veux enlever toute friction possible pour elle. Encore une fois, je ne suis pas inquiet au sujet de hacks, je ne ne veux pas des erreurs stupides de connexion mal - je veux savoir qui vient, et ce qu'ils veulent.

Quoi qu'il en soit.
Alors, quels sont nos principaux risques ici, si nous chiffrons symétriquement les mots de passe, au lieu d'utiliser un hachage à sens unique?

les utilisateurs Usurpation de l'identité? Non, je l'ai déjà accepté que risque, pas intéressant.
administrateur du mal? Eh bien, peut-être ... Mais encore une fois, je ne me inquiète pas si quelqu'un peut usurper l'identité d'un autre utilisateur interne ou non ... et de toute façon un administrateur malveillant va se offrir votre mot de passe peu importe - si gone votre admin mauvais, son jeu sur de toute façon.
Une autre question qui a été soulevée, est l'identité est en fait partagée entre plusieurs systèmes. Ah! Ce risque est très intéressant, qui nécessite un examen plus approfondi.
Permettez-moi de commencer en affirmant que ce n'est pas réelle identité thats partagé, plutôt la preuve , ou les informations d'identification d'authentification. D'accord, car un mot de passe partagé sera effectivement me permettre l'entrée d'un autre système (par exemple, mon compte bancaire ou gmail), c'est effectivement la même identité, il est juste sémantique ... Sauf que il est pas . L'identité est gérée par chaque système séparément, dans ce scénario (bien qu'il pourrait y avoir des systèmes d'identification de tiers, tels que OAuth - encore, son séparé de l'identité dans ce système - plus tard).
A ce titre, le point de risque de base ici, est que l'utilisateur passe volontairement entrée son (même) dans plusieurs systèmes différents - et maintenant, je (l'administrateur) ou tout autre pirate de mon site aura accès aux mots de passe de tante Erma pour le site de missiles nucléaires.

Hmmm.

Est-ce que tout semble ici hors de vous?

Il devrait.

Commençons par le fait que la protection du système de missiles nucléaires est pas de ma responsabilité , je suis juste building un site de sortie en famille frakkin (pour ma famille). Alors qui est responsable? Umm ... Que diriez-vous du système de missiles nucléaires? Duh.
Deuxièmement, si je voulais voler le mot de passe de quelqu'un (de quelqu'un qui est connu d'utiliser à plusieurs reprises le même mot de passe entre les sites sécurisés, et les pas si sûrs) - pourquoi devrais-je donner la peine de piratage de votre site? Ou aux prises avec votre chiffrement symétrique? Goshdarnitall, je peux juste mettre mon propre site web simple , les utilisateurs ont vous inscrire pour recevoir NOUVELLES TRÈS IMPORTANT À propos de ce qu'ils veulent ... Puffo Presto, je « volé » leurs mots de passe.

Oui, l'éducation des utilisateurs ne reviennent toujours à nous mordre dans le hienie, ne pas
Et il n'y a rien que vous pouvez faire à ce sujet ... Même si vous deviez hachage des mots de passe sur votre site, et faire tout le reste de la TSA peut penser, vous avez ajouté une protection à leur mot de passe PAS UN PENTECOTE , si elles vont continuer de coller leurs mots de passe dans promiscuously chaque site, ils bousculent. Ne même pas la peine d'essayer.

En d'autres termes, Vous ne possédez pas leurs mots de passe , donc cesser d'essayer d'agir comme vous le faites.

Alors, mon cher experts sur la sécurité, comme une vieille dame utilisée pour demander Wendy, « Où est le risque? »

Encore quelques points en réponse à des questions soulevées ci-dessus:

CWE est pas une loi, un règlement ou même une norme. Il est une collection de faiblesses communes , à savoir 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 défaitistes ici. Il est une question de partage de l'identité et de lui-même (!), Pas au sujet de la fissuration des mots de passe sur les systèmes de faible valeur. Si vous partagez un mot de passe entre une faible valeur et un système de grande valeur, le problème est déjà là!
En passant, le point précédent serait en fait pointer CONTRE en utilisant OAuth et similaires pour ces deux systèmes de faible valeur, et les systèmes bancaires à haute valeur ajoutée.
Je sais que c'était juste un exemple, mais (malheureusement) les systèmes du FBI ne sont pas vraiment le plus fixé autour. Pas tout à fait comme les serveurs de blog de votre chat, mais ne dépassent-ils certaines des banques les plus sûres.
Fractionner les connaissances, ou un double contrôle, des clés de chiffrement ne se produisent pas seulement dans l'armée, en fait PCI-DSS maintenant nécessite cela de fondamentalement tous les commerçants, il est donc pas vraiment si loin plus là (si la valeur le justifie).
Pour tous ceux qui se plaignent que les questions comme celles-ci sont ce qui fait la profession de développeur l'air si mauvais: il est des réponses comme celles-ci, qui font la profession de sécurité semble encore pire. Encore une fois, l'analyse des risques axée sur les affaires est ce qui est nécessaire, sinon vous vous rendre inutile. En plus d'être mauvais.
Je suppose que c'est pourquoi ce n'est pas une bonne idée de simplement prendre un développeur régulier et déposer davantage de responsabilités en matière de sécurité sur lui, sans formation à penser différemment, et de rechercher les compromis appropriés. Aucune infraction, à ceux d'entre vous, je suis tout à fait - mais plus de formation est pour

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 insiste encore, expliquer un peu plus, insistent sur le fait, argumenter. Jetez un accès de colère, si nécessaire.
Expliquer le risque commercial lui. Les détails sont bons, les chiffres sont meilleurs, une démonstration en direct est généralement préférable.
S'IL insiste encore et présente des raisons commerciales valables - il est temps pour vous de faire un appel de jugement:
Est-ce site à faible ou pas de valeur? Est-ce vraiment un cas d'entreprise valide? Est-il assez bon pour vous? Y at-il pas d'autres risques que vous pouvez considérer, qui emporteraient des raisons commerciales valables? (Et bien sûr, le client est pas un site malveillant, mais c'est duh).
Si oui, allez-y. Il ne vaut pas l'effort, la friction, et a perdu l'usage (dans cette situation hypothétique)de mettre le processus nécessaire en place. Toute autre décision (encore une fois, dans cette situation) est un mauvais compromis.

Ainsi, la ligne de fond, et une réponse réelle - chiffrer avec un simple algorithme symétrique, protéger la clé de chiffrement avec ACLs forts et de préférence DPAPI ou similaires, le document et que le client (quelqu'un d'assez haut pour prendre cette décision) signer là-dessus.

Que diriez-vous d'une maison à mi-chemin?

Enregistrer les mots de passe avec un cryptage fort, et ne permettent pas réinitialisations.

Au lieu de réinitialiser les mots de passe, permet l'envoi d'un mot de passe unique (qui doit être changé dès la première ouverture de session se produit). Laissez l'utilisateur puis changer le mot de passe à tout ce qu'ils veulent (le précédent, si elles choisissent).

Vous pouvez « vendre » comme un mécanisme sécurisé pour la réinitialisation des mots de passe.

La seule façon de permettre à un utilisateur de récupérer leur mot de passe d'origine, est de chiffrer avec sa propre clé publique de l'utilisateur. Seulement que l'utilisateur peut alors décrypter leur mot de passe.

Ainsi, les étapes seront:

registres d'utilisateur sur votre site (via SSL bien sûr) sans mettre encore un mot de passe. Connectez-les automatiquement ou fournir un mot de passe temporaire.
Vous offrez pour stocker leur clé publique PGP pour la récupération future de mot de passe.
Ils télécharger leur clé publique PGP.
Vous leur demandez de définir un nouveau mot de passe.
Ils soumettent leur mot de passe.
Vous Hacher le mot de passe en utilisant le meilleur algorithme de hachage de mot de passe disponible (par exemple bcrypt). Utilisez ce lors de la validation de la prochaine ouverture de session.
Vous chiffrez le mot de passe avec la clé publique et magasin qui séparément.

Si l'utilisateur puis demander son mot de passe, vous répondez avec le crypté (non haché) mot de passe. Si l'utilisateur ne souhaite pas être en mesure de récupérer leur mot de passe à l'avenir (ils ne seraient en mesure de le remettre à un service généré un), les étapes 3 et 7 peuvent être sautées.

Je pense que la vraie question que vous devriez vous poser est la suivante: « Comment puis-je être mieux à convaincre les gens »

J'ai le même problème. Et de la même façon, je pense toujours que quelqu'un pirater mon système, il est pas une question de « si » mais « quand ».

Alors, quand je dois faire un site Web qui ont besoin de stocker une information confidentielle récupérable, comme une carte de crédit ou un mot de passe, ce que je fais est:

Chiffrer avec: openssl_encrypt (string $ data, chaîne méthode $, string $ password)
- manuel PHP .
données arg :
- les informations sensibles (par exemple le mot de passe de l'utilisateur)
- sérialiser si nécessaire, par exemple, si l'information est un réseau de données comme multiple des informations sensibles
Mot de passe arg : utiliser une information qui ne connaissent que l'utilisateur comme:
- la plaque d'immatriculation utilisateur
- numéro de sécurité sociale
- numéro de téléphone de l'utilisateur
- le nom de la mère utilisateur
- une chaîne aléatoire sended par e-mail et / ou par sms au moment du registre
méthode arg :
- choisir une méthode de chiffrement, comme "aes-256-cbc"
JAMAIS stocker les informations utilisées dans l'argument "mot de passe" à la base de données (ou tout autre endroit dans le système)

Si nécessaire retrive ces données il suffit d'utiliser la « openssl_decrypt () » fonction et demander à l'utilisateur la réponse. .: par exemple "Pour recevoir votre mot de passe répondre à la question: Quel est votre numéro de téléphone portable"

PS 1 : ne jamais utiliser comme un mot de passe de données stockées dans la base de données. Si vous devez enregistrer le numéro de téléphone de l'utilisateur, puis ne jamais utiliser ces informations pour coder les données. Toujours utiliser une information que seul l'utilisateur sait ou qu'il est difficile de savoir à quelqu'un non-parent.

PS 2 : pour les informations de carte de crédit, comme « un clic achat », ce que je fais est d'utiliser le mot de passe de connexion. Ce mot de passe est dans la base de données hachée (SHA1, md5, etc.), mais au moment de la connexion, je stocker le mot de passe en texte clair session ou dans un non-persistant (à savoir à la mémoire) cookies sécurisé. Ce mot de passe simple jamais dans la base de données, il est en effet restent toujours en mémoire, détruite à la fin de l'article. Quand l'utilisateur clique à bouton « un clic d'achat », le système utilise ce mot de passe. Si l'utilisateur a été connecté avec un service comme facebook, twitter, etc, je soufflerai le mot de passe au moment de l'achat (ok, ce n'est pas complètement « à clic ») ou utilise ensuite des données du service que l'utilisateur utilisé pour se connecter (comme l'identifiant de facebook).

Sécurisation des informations d'identification n'est pas une opération binaire: sécurisé / non sécurisé. La sécurité est tout au sujet de l'évaluation des risques et est mesurée sur un continuum. fanatiques de 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 avec des exigences de Hashed mot de passe rigoureux, des échantillons d'ADN et les analyses de la rétine sont plus sûrs, mais à un coût de développement et de l'expérience utilisateur. les mots de passe sont beaucoup moins plaintext sécurisé mais sont moins coûteux à mettre en œuvre (mais devrait être évitée). À la fin de la journée, il se résume à 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 sa valeur temporelle.

Quel est le coût du mot de passe de quelqu'un sortir dans la nature? Quel est le coût de l'usurpation d'identité dans le système donné? Pour les ordinateurs du FBI, le coût pourrait être énorme. Pour un hors site Web de cinq pages de Bob, le coût pourrait être négligeable. Un professionnel offre des options à leurs clients et, en matière de sécurité, expose les avantages et les risques de toute mise en œuvre. Ceci est doublement si le client demande quelque chose qui pourrait les mettre en danger en raison de ne pas tenir compte des normes de l'industrie. Si un client demande spécifiquement le chiffrement dans les deux sens, je vous assurer de documenter vos objections, mais cela ne devrait pas vous empêcher de mettre en œuvre la meilleure façon que vous savez. A la fin de la journée, il est l'argent du client. Oui, vous devez pousser pour l'utilisation de hash à sens unique, mais de dire qui est tout à fait le seul choix et toute autre chose est contraire à l'éthique est une absurdité totale.

Si vous stockez des mots de passe avec un cryptage à deux voies, la sécurité se résume à la gestion des clés. Windows fournit des mécanismes pour limiter l'accès aux certificats clés privées aux comptes administratifs et des mots de passe. Si vous hébergez sur d'autres que vous auriez besoin de voir sa plate-forme, quelles sont les options dont vous disposez sur ceux-ci. Comme d'autres l'ont suggéré, vous pouvez utiliser le chiffrement 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 que stipule expressément que les mots de passe doivent être enregistrés à l'aide hash à sens unique. La seule exigence dans l'une de ces lois est simplement que raisonnable sont les mesures prises pour la sécurité. Si l'accès à la base de données est limité, même les mots de passe peuvent se qualifier légalement plaintext en vertu d'une telle restriction.

Toutefois, cela ne met en lumière un autre aspect: priorité juridique. Si la priorité juridique suggère que vous devez utiliser hash à sens unique donné à l'industrie dans laquelle votre système est en cours de construction, alors c'est tout à fait différent. Ce sont les munitions que vous utilisez pour convaincre votre client. Sauf que, la meilleure suggestion de fournir une évaluation des risques raisonnable, documenter vos objections et mettre en œuvre le système de la manière la plus sûre, vous pouvez compte tenu des exigences du client.

Faire la réponse à une partie de la clé de chiffrement, et ne stocke pas la réponse de la question de sécurité sous forme de texte (hachage au lieu)

question de la sécurité de l'utilisateur

Je mets en œuvre des systèmes d'authentification à facteurs multiples pour gagner leur 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 moins pour authentifier l'utilisateur pour que le flux de travail remis à zéro / loisirs. En particulier, l'utilisation de mots de passe (OTPs une seule fois) que certains des facteurs supplémentaires, atténue une grande partie du risque si la fenêtre de temps est court pour le flux de travail proposé. Nous avons mis en place des générateurs logiciels OTP pour les smartphones (que la plupart des utilisateurs portent déjà avec eux-mêmes toute la journée) avec un grand succès. Avant de se plaint bouchon commercial apparaissent, ce que je veux dire est que nous pouvons réduire les risques inhérents à vos mots de passe facilement accessibles ou remis à zéro quand ils ne sont pas le seul facteur utilisé pour authentifier un utilisateur. Je reconnais que pour la réutilisation des mots de passe entre les scénarios des sites, la situation est toujours pas assez, car l'utilisateur insistera pour que le mot de passe original parce qu'il / elle veut ouvrir d'autres sites aussi, mais vous pouvez essayer de livrer le mot de passe reconstruit dans la plus sûre possible (HTPPS et l'apparence discrète sur le html).

Désolé, mais aussi longtemps que vous avez un moyen de décoder leur mot de passe, il n'y a aucun moyen que ça va être sécurisé. Combattez avec amertume, et si vous perdez, ACY.

Juste suis tombé sur cette discussion intéressante et chauffée. Ce qui m'a surpris le plus était que, peu d'attention a été portée à la question fondamentale suivante:

Q1. Quelles sont les raisons réelles de l'utilisateur insiste sur la nécessité d'avoir accès au texte simple mot de passe stocké? Pourquoi est-il de tant de valeur?

Les informations que les utilisateurs sont des personnes âgées ou jeunes ne répond pas vraiment à cette question. Mais comment peut-être une décision d'affaires sans souci du client une bonne compréhension?

Maintenant, pourquoi il importe? Parce que si la cause réelle de la demande des clients est le système qui est douloureusement difficile à utiliser, puis aborder peut-être la cause exacte résoudrait le problème réel?

Comme je n'ai pas ces informations et ne peut pas parler à ces clients, je ne peux que deviner. Il est sur la facilité d'utilisation, voir ci-dessus

Une autre question que j'ai vu demandé:

Q2. Si l'utilisateur ne se rappelle pas le mot de passe d'abord, pourquoi l'ancien mot de passe important?

Et voici réponse possible. Si vous avez appelé chat « miaumiau » et utilisé son nom comme mot de passe oublié, mais vous avez fait, préféreriez-vous être rappelé ce qu'il était ou plutôt envoyé quelque chose comme « # zy * RW (ew »?

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

J'essaie simplement de comprendre la raison. Mais quelle que soit la raison, il est la raison de ne pas la cause qui doit être pris en compte.

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

Si je me connecte à un site de nouvelles à lire les journaux, je veux taper 1111 comme mot de passe et être par !!!

Je sais qu'il est peu sûr, mais qu'est-ce que je me soucie de quelqu'un d'avoir accès à mon « compte »? Oui, il peut lire les nouvelles aussi!

Est-ce que le magasin du site mes informations « privé »? Les nouvelles que je lis aujourd'hui? Ensuite, il est le problème du site, pas le mien! Le site affiche des informations privées à l'utilisateur authentifié? Alors ne le montrent pas à la première place!

Ceci est juste pour démontrer l'attitude de l'utilisateur du problème.

Donc, pour résumer, je ne pense pas que ce soit un problème de la façon de stocker en toute sécurité « » mots de passe en clair (que nous connaissons est impossible), mais plutôt la façon de traiter les clients préoccupation réelle.

Manipulation perdu / mots de passe oubliés:

Personne ne devrait jamais être en mesure de récupérer les mots de passe.

Si les utilisateurs ont oublié leur mot de passe, ils doivent au moins connaître leurs noms d'utilisateur ou adresse e-mail. Sur demande, générer un GUID dans la table des utilisateurs et envoyé un e-mail contenant un lien contenant le guid 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 vraiment (probablement avec une certaine logique de délai d'attente), et demande à l'utilisateur un nouveau mot de passe.

Si vous avez besoin d'avoir aident les utilisateurs à la hotline, ajouter quelques rôles à votre modèle de subventions et de permettre le rôle de hotline pour se connecter temporairement utilisateur identifié. Connectez-vous toutes ces connexions hotline. Par exemple, Bugzilla offre une telle fonctionnalité d'emprunt d'identité aux admins.

Qu'en est-il envoyer le mot de passe en texte clair lors de l'enregistrement, avant de l'obtenir crypté et perdu? Je l'ai vu beaucoup de sites Web le font, et d'obtenir ce mot de passe de l'e-mail de l'utilisateur est plus sûr que de laisser autour de votre serveur / comp.

Si vous ne pouvez pas rejeter simplement l'obligation de stocker les mots de passe récupérables, que diriez-vous que votre contre-argument.

Nous pouvons soit correctement les mots de passe de hachage et de construire un mécanisme de remise à zéro pour les utilisateurs, ou nous pouvons supprimer toutes les informations personnelles du système. Vous pouvez utiliser une adresse e-mail pour configurer les préférences de l'utilisateur, mais c'est à ce sujet. Utilisez un cookie pour tirer automatiquement les préférences futures visites et jeter les données loin après un délai raisonnable.

L'option qui est souvent négligé avec la politique de mot de passe est de savoir si un mot de passe est vraiment nécessaire même. Si la seule chose que votre politique de mot de passe n'est la cause des appels de service à la clientèle, vous pouvez peut-être se débarrasser de lui.

Les usagers vraiment besoin de récupérer (par exemple être dit) ce que le mot de passe qu'ils ont oublié était, ou doivent-ils simplement être en mesure d'obtenir sur le système? Si ce qu'ils veulent vraiment est un mot de passe d'ouverture de session, pourquoi ne pas avoir une routine qui change simplement l'ancien mot de passe (quoi que ce soit) à un nouveau mot de passe que la personne de soutien peut donner à la personne qui a perdu son mot de passe?

Je travaille avec des systèmes qui font exactement cela. La personne de soutien n'a aucun moyen de savoir ce que le mot de passe actuel est, mais peut le remettre à une nouvelle valeur. Bien sûr, tous ces réinitialisations devraient être enregistrés quelque part et de bonnes pratiques serait de générer un courrier électronique à l'utilisateur en lui disant 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 une clé squelette / maître qui est connu par le personnel de soutien seulement et est la même pour tous les utilisateurs. De cette façon, lorsqu'un utilisateur a un problème de la personne de soutien peut se connecter au compte avec la clé maître et aider l'utilisateur à changer son mot de passe à tout. Inutile de dire que toutes les connexions avec la clé principale doit être enregistré par le système ainsi. À titre de mesure supplémentaire, chaque fois que la clé principale est utilisée, vous pouvez valider les personnes de soutien et des informations d'identification.

-Edit- En réponse aux commentaires de ne pas avoir une clé maîtresse: Je suis d'accord qu'il est mauvais tout comme je crois qu'il est mauvais pour permettre à une personne autre que l'utilisateur d'avoir accès au compte de l'utilisateur. Si vous regardez la question, la prémisse est que le client a mandaté un environnement de sécurité très compromis.

Une clé principale ne doit pas être aussi mauvais que serait d'abord sembler. Je travaillais dans une usine de défense où ils comprirent la nécessité pour l'opérateur de l'ordinateur central d'avoir « accès spécial » à certaines occasions. Ils ont simplement mis le mot de passe spécial dans une enveloppe scellée et collées au bureau de l'opérateur. Pour utiliser le mot de passe (que l'opérateur ne savait pas), il a dû ouvrir l'enveloppe. A chaque changement de quart de travail l'un des postes de chef de quart était de voir si l'enveloppe avait été ouverte et si oui immédiatement avoir le mot de passe changé (par un autre ministère) et le nouveau mot de passe a été mis dans une nouvelle enveloppe et le processus a commencé tous à nouveau. L'opérateur serait demandé pourquoi il avait ouvert et l'incident serait documenté pour l'enregistrement.

Bien que ce n'est pas une procédure que je conception, il a fait le travail et a fourni une excellente reddition de comptes. Tout a été enregistré et passé en revue, ainsi que tous les opérateurs avaient les autorisations secrets DOD et on n'a jamais eu des abus.

En raison de l'examen et de surveillance, tous les opérateurs savaient que s'ils mal utilisés le privilège d'ouvrir l'enveloppe, ils ont fait l'objet d'un licenciement et d'éventuelles poursuites pénales immédiatement.

Je suppose que la vraie réponse est que si l'on veut faire des choses un droit embauche des personnes qu'ils peuvent faire confiance, faire des vérifications d'antécédents et d'exercer le contrôle et la responsabilité de la bonne gestion.

Mais là encore, si ce pauvre client de camarade avait une bonne gestion, ils auraient pas demandé une telle solution comprimised de sécurité en premier lieu, maintenant ils?

Du peu que je comprends à ce sujet, je crois que si vous construisez un site Web avec un code d'accès / mot de passe, alors vous devriez même pas voir le mot de passe en texte clair sur votre serveur du tout. Le mot de passe doit être haché, et probablement salé, avant qu'il ne quitte même 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.

En outre, je crois (à partir du Web) qui (prétendument) certains algorithmes tels que MD5 ne sont plus considérés comme sûrs. Je n'ai aucun moyen de juger moi-même, mais il est quelque chose à considérer.

ouvrir un DB sur un serveur autonome et donner une connexion à distance crypté à chaque serveur Web qui requiert cette fonction.
il ne doit pas être un DB relationnelle, il peut être un système de fichiers avec un accès FTP, en utilisant des dossiers et des fichiers au lieu des tables et des lignes.
donner les serveurs Web permissions d'écriture seulement si vous le pouvez.

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

pour que quelqu'un pour obtenir à la fois le mot de passe et son contexte (id site + id utilisateur + « pass-un »), il doit:

pirater le DB du site Web pour obtenir un ( "pass-un", id utilisateur) ou les paires.
get id du site provenant d'un fichier de configuration
trouver et pirater les mots de passe à distance DB.

vous pouvez contrôler l'accessibilité du service de récupération de mot de passe (exposer uniquement en tant que service Web sécurisé, ne permettent certaine quantité de mots de passe récupérations par jour, faites-le manuellement, etc.), et la charge même supplémentaire pour cette « sécurité spéciale arrangement ».
Le serveur de récupération de mots de passe de DB est assez caché car il ne sert pas beaucoup de fonctions et peut être mieux sécurisé (vous pouvez personnaliser les autorisations, les processus et services étroitement).

Dans l'ensemble, vous faites le travail plus difficile pour le pirate. la possibilité d'une atteinte à la sécurité sur un seul serveur est toujours le même, mais les données significatives (une correspondance de compte et mot de passe) sera difficile à assembler.

Une autre option que vous ne pouvez pas avoir considéré permet à des actions par e-mail. Il est un peu lourd, mais je mis en œuvre ce pour un client qui avait besoin d'utilisateurs « en dehors » leur système pour voir (lecture seule) certaines parties du système. Par exemple:

Une fois qu'un utilisateur est enregistré, ils ont un accès complet (comme un régulier site Internet). L'inscription doit inclure un email.
Si les données ou une action est nécessaire et l'utilisateur ne dispose pas se souvenir de leur mot de passe, ils peuvent encore effectuer l'action par en cliquant sur un spécial " moi pour l'autorisation " bouton, juste à côté du régulier " Envoyer " bouton.
La demande est ensuite envoyé à l'e-mail avec un lien hypertexte demandant s'ils veulent l'action à effectuer. Ceci est similaire à une réinitialisation de mot de passe lien e-mail, mais au lieu de réinitialiser le mot de passe, il effectue le une action unique .
L'utilisateur clique alors « Oui », et il confirme que les données doivent être indiquées, ou l'action doit être effectuée, les données ont révélé, etc.

Comme vous l'avez mentionné dans les commentaires, cela ne fonctionnera pas si l'e-mail est compromise, mais il adresse commentaire de @joachim de ne pas vouloir réinitialiser le mot de passe. Finalement, ils devront utiliser le nouveau mot de passe, mais ils pourraient le faire à un moment plus opportun, ou avec l'aide d'un administrateur ou un ami, au besoin.

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

et sel hachage du mot de passe de l'utilisateur normal. Lorsque vous vous connectez l'utilisateur, permettent à la fois le mot de passe de l'utilisateur (après le salage / hash), mais aussi permettre ce que l'utilisateur est entré dans la lettre pour correspondre aussi.

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

En gros, faire le mot de passe salé / haché aussi être un mot de passe « simple texte ».

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow