Comment devrais-je aborder de manière éthique le stockage des mots de passe de l'utilisateur pour une récupération ultérieure en texte brut ?

Question

En tant que je continue à construire de plus en plus de sites web et d'applications web, on me demande souvent de stocker les mots de passe des utilisateurs de manière à ce qu'ils puissent être récupérés si / quand l'utilisateur a un problème (soit pour envoyer un lien de mot de passe oublié par e-mail, les guider au téléphone, etc.) Quand je peux, je lutte amèrement contre cette pratique et je fais beaucoup de programmation « supplémentaire » pour rendre les réinitialisations de mot de passe et l'assistance administrative possibles sans stocker leur mot de passe réel.

Quand je ne peux pas lutter contre cela (ou ne pas gagner), alors j'encode toujours le mot de passe d'une manière ou d'une autre pour qu'il ne soit, au moins, pas stocké en texte brut dans la base de données—bien que je sache que si ma base de données est piratée, il ne serait pas difficile pour le coupable de craquer les mots de passe, ce qui me rend mal à l'aise.

Dans un monde parfait, les gens mettraient à jour leurs mots de passe régulièrement et ne les dupliqueraient pas sur de nombreux sites différents—malheureusement, je connais BEAUCOUP de personnes qui ont le même mot de passe pour le travail/la maison/l'e-mail/la banque, et qui me l'ont même donné librement quand ils ont besoin d'aide. Je ne veux pas être responsable de leur désastre financier si mes procédures de sécurité de base de données échouent pour une raison quelconque.

Moralement et éthiquement, je me sens responsable de protéger ce qui peut être, pour certains utilisateurs, leur gagne-pain même s'ils le traitent avec beaucoup moins de respect. Je suis sûr qu'il existe de nombreuses approches et arguments à faire pour saler les hachages et différentes options d'encodage, mais existe-t-il une seule « meilleure pratique » lorsque vous devez les stocker? Dans presque tous les cas, j'utilise PHP et MySQL si cela fait une différence dans la manière dont je dois gérer les détails.

Informations supplémentaires pour la prime

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, il est préférable de refuser de le faire. Cependant, je ne cherche pas une leçon sur les mérites de prendre cette approche, je cherche les meilleures étapes à suivre si vous décidez de prendre 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 des problèmes mentaux ou aux très jeunes peuvent devenir déroutants pour les gens lorsqu'ils sont invités à effectuer une procédure 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 de l'aide supplémentaire d'un technicien de service pour les aider à accéder au système ou de le recevoir par e-mail/affiché directement.

Dans de tels systèmes, le taux d'attrition de ces groupes démographiques pourrait entraver l'application si les utilisateurs ne disposaient pas de ce niveau d'assistance d'accès, donc veuillez répondre en gardant cela à l'esprit.

Merci à tous

Cette question a été amusante avec beaucoup de débat et j'ai apprécié. En fin de compte, j'ai sélectionné une réponse qui garantit la sécurité des mots de passe (je n'aurai pas à conserver de mots de passe en texte brut ou récupérables), mais qui rend également possible pour la base d'utilisateurs que j'ai spécifiée de se connecter à un système sans les inconvénients majeurs que j'ai constatés avec la récupération normale de mots de passe.

Comme toujours, il y avait environ 5 réponses que j'aurais aimé marquer comme correctes pour différentes raisons, mais j'ai dû en choisir une seule - toutes les autres ont obtenu un +1. Merci à tous!

Aussi, merci à tous dans la communauté Stack qui ont voté pour cette question et/ou l'ont marquée comme favorite. Atteindre 100 votes positifs est pour moi un compliment et j'espère que cette discussion a aidé quelqu'un d'autre avec la même préoccupation que j'avais.

Answer 1

Que diriez-vous d'adopter une approche ou un angle différent pour aborder ce problème? Demandez pourquoi le mot de passe doit être en texte brut: si c'est pour que l'utilisateur puisse récupérer le mot de passe, alors en réalité, vous n'avez pas vraiment besoin de récupérer le mot de passe qu'ils ont défini (ils ne se souviennent de toute façon pas de ce que c'est), vous devez être capable de leur fournir un mot de passe qu'ils peuvent utiliser.

Imaginez : 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 tout aussi bon que l'ancien. Cependant, l'un des inconvénients des mécanismes courants de réinitialisation de mot de passe utilisés aujourd'hui est que les mots de passe générés lors d'une opération de réinitialisation sont généralement une série de caractères aléatoires, donc difficile pour l'utilisateur à saisir correctement à moins de les copier-coller. Cela peut poser problème pour les utilisateurs moins expérimentés en informatique.

Une façon de contourner ce problème est de fournir des mots de passe auto-générés qui sont plus ou moins du texte en langage naturel. Bien que les chaînes de texte en langage naturel n'aient peut-être pas l'entropie qu'une chaîne de caractères aléatoires de même longueur, rien n'empêche que votre mot de passe auto-généré ait seulement 8 (ou 10 ou 12) caractères. Obtenez une phrase de passe auto-générée à haute entropie en enchaînant plusieurs mots aléatoires (laissez un espace entre eux, pour qu'ils restent reconnaissables et saisissables par quiconque peut les lire). Six mots aléatoires de longueurs différentes sont probablement plus faciles à saisir 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é aléatoirement parmi des majuscules, des minuscules, des 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 (comme le fait Diceware) qui pourraient être sélectionnés aléatoirement pour former une phrase de passe de six mots, la phrase de passe aurait une entropie de 77,4 bits. Consultez la FAQ de Diceware pour plus d'informations.

• une phrase de passe avec environ 77 bits d'entropie : "admettre prose flammes table aigu flair"

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

Personnellement, je préférerais taper la phrase, et avec le copier-coller, la phrase n'est pas moins facile à utiliser que le mot de passe, donc aucun inconvénient de ce côté-là. Bien entendu, si votre site web (ou quel que soit l'actif protégé) n'a pas besoin de 77 bits d'entropie pour une phrase de passe auto-générée, générez moins de mots (ce que vos utilisateurs apprécieraient sûrement).

Je comprends les arguments selon lesquels il existe des actifs protégés par mot de passe qui n'ont pas vraiment une grande valeur, donc la violation d'un mot de passe ne serait pas 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 compromis : tout ce qui pourrait se produire serait quelqu'un qui enverrait du spam ou posterait sous mon nom pendant un certain temps. Ce ne serait pas génial, mais ce n'est pas comme s'ils allaient entrer dans mon compte bancaire. Cependant, étant donné que de nombreuses personnes utilisent le même mot de passe pour leurs sites web de forums que pour leurs comptes bancaires (et probablement les bases de données de sécurité nationale), je pense qu'il serait préférable de traiter même ces mots de passe "de faible valeur" comme non récupérables.

Answer 2

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

Architecte: Pour un bâtiment de cette taille et de cette capacité, vous aurez besoin de sorties de secours ici, ici et ici.
Client: Non, c'est trop compliqué et 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 optionnelles, elles sont requises selon le code de feu de la ville.
Client: Je ne vous paie pas pour argumenter. Faites juste ce que j'ai demandé.

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

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

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

La programmation informatique n'est peut-être pas une profession agréée, mais les gens se demandent souvent pourquoi notre profession ne bénéficie pas du même respect qu'un ingénieur civil ou mécanique - eh bien, cherchez pas plus loin. Ces professions, lorsqu'elles reçoivent des exigences médiocres (ou carrément dangereuses), refusent tout simplement. Elles savent que dire "j'ai fait de mon mieux, mais il a insisté et je dois faire ce qu'il dit" n'est pas une excuse. Elles pourraient perdre leur licence pour cette excuse.

Je ne sais pas si vous ou vos clients font partie d'une société cotée en bourse, mais stocker des mots de passe sous une forme récupérable vous ferait échouer plusieurs types d'audits de sécurité. Le problème n'est pas de savoir à quel point cela serait difficile pour un "pirate" qui aurait accès à votre base de données de récupérer les mots de passe. La grande majorité des menaces de sécurité sont internes. Ce contre quoi vous devez vous protéger est un employé mécontent qui s'en va avec tous les mots de passe et les vend au plus offrant. Utiliser un cryptage asymétrique et stocker la clé privée dans une base de données séparée ne prévient en rien ce scénario ; il y aura toujours quelqu'un avec accès à la base de données privée, et c'est un risque sérieux pour la sécurité.

Il n'y a pas de manière éthique ou responsable de stocker des mots de passe sous une forme récupérable. Point final.

Answer 3

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

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

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

Answer 4

Ne baissez pas les bras. L'arme que vous pouvez utiliser pour convaincre vos clients est la non répudiation. Si vous pouvez reconstruire les mots de passe des utilisateurs via un quelconque mécanisme, vous avez donné à leurs clients un mécanisme de non répudiation légale et ils peuvent répudier toute transaction qui dépend de ce mot de passe, car il n'y a aucun moyen pour le fournisseur de prouver qu'ils n'ont pas reconstruit le mot de passe et traité la transaction eux-mêmes. Si les mots de passe sont correctement stockés sous forme de digest plutôt que de texte chiffré, cela est impossible, donc soit le client final a exécuté lui-même la transaction, soit il a manqué à son devoir de prudence concernant le mot de passe. Dans les deux cas, la responsabilité lui incombe entièrement. J'ai travaillé sur des cas où cela aurait pu s'élever à des centaines de millions de dollars. Ce n'est pas quelque chose que vous voulez rater.

Answer 5

Vous ne pouvez pas stocker de manière éthique des mots de passe pour une récupération en clair ultérieure. C'est aussi simple que ça. Même Jon Skeet ne peut pas stocker de manière éthique des mots de passe pour une récupération en clair ultérieure. Si vos utilisateurs peuvent récupérer des mots de passe en clair d'une manière ou d'une autre, alors potentiellement un hacker qui trouve une vulnérabilité de sécurité dans votre code le peut aussi. Et ce n'est pas juste le mot de passe d'un utilisateur qui est compromis, mais tous.

Si vos clients ont un problème avec cela, dites-leur que stocker des mots de passe de manière récupérable est contre la loi. Ici, au Royaume-Uni du moins, la Loi de protection des données de 1998 (en particulier, Annexes 1, Partie II, paragraphe 9) exige des controlleurs de données qu'ils utilisent les mesures techniques appropriées pour maintenir les données personnelles sécurisées, en tenant compte, entre autres, du préjudice qui pourrait être causé si les données étaient compromises - ce qui pourrait être considérable pour les utilisateurs qui partagent des mots de passe entre les sites. S'ils ont toujours du mal à comprendre que c'est un problème, dirigez-les vers quelques exemples concrets, comme celui-ci.

La manière la plus simple de permettre aux utilisateurs de récupérer une connexion est de leur envoyer un lien unique par e-mail qui les connecte automatiquement et les amène directement à 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 maintenant à voir des poursuites judiciaires et des poursuites contre les entreprises qui ne sécurisent pas correctement les mots de passe de leurs utilisateurs. Exemple : LinkedIn condamné à payer 5 millions de dollars dans un recours collectif; Sony condamné à 250 000 £ pour le piratage des données PlayStation. Si je me souviens bien, LinkedIn cryptait en réalité les mots de passe de ses utilisateurs, mais le cryptage qu'il utilisait était trop faible pour être efficace.