Question:
Comment puis-je savoir que les développeurs seront éthiques et n'enregistreront pas mon mot de passe en texte clair
poush
2015-06-07 10:03:38 UTC
view on stackexchange narkive permalink

Je ne demande pas pourquoi le hachage devrait être fait. Au lieu de cela, je veux savoir comment empêcher que les développeurs enregistrent les mots de passe des utilisateurs pour pirater les autres comptes de leurs utilisateurs, en particulier leur messagerie.

Ne pourraient-ils pas stocker les mots de passe de leurs utilisateurs en texte clair à l'insu des utilisateurs?

Un utilisateur peut-il détecter / empêcher cela?

Vous ne pouvez pas, c'est pourquoi il est important d'utiliser différents mots de passe sur différents sites. Du moins, lorsque la sécurité compte pour vous (les forums aléatoires ou les sites de commerce électronique peuvent ne pas avoir d'importance). Si vous avez du mal à vous souvenir de tous ces mots de passe, utilisez un gestionnaire de mots de passe.
@paj28 C'est * une des raisons * que c'est important. Il y en a d'autres.
Un site qui fait cela est Mint.com. Je ne sais pas s'ils stockent mes mots de passe bancaires en texte brut, mais ils doivent au moins pouvoir reconstruire mes mots de passe en texte brut car la plupart des banques ne disposent pas d'API authentifiées appropriées pour accéder à leurs données. Cela étant dit, j'utilise toujours Mint malgré cette faille de sécurité majeure. La convivialité du site Web / de l'application Android de ma propre banque est tellement horrible que j'ai pratiquement abandonné une bonne sécurité au profit d'une utilisation réelle.
Bien qu'il n'y ait aucun risque que cela donne des faux positifs, cela donnera certainement beaucoup de faux faux: demandez aux sites Web votre mot de passe, s'ils vous le rendent en texte clair au lieu de forcer un nouveau mot de passe, vous pouvez dire avec certitude qu'il est stocké en texte clair. Évidemment, ils pourraient le stocker en texte brut, mais vous obligeraient toujours à en créer un nouveau. C'est plus susceptible de trouver un développeur naïf qu'un sinistre.
Pourquoi n'y a-t-il pas encore de méthode standardisée d'authentification par clé publique? (Demandez au navigateur de générer une paire de clés et d'envoyer uniquement la clé publique au serveur, puis d'enregistrer la clé privée localement, éventuellement avec un mot de passe)
À moins que vous ne puissiez examiner complètement le matériel et les logiciels du site au moment où vous entrez votre mot de passe, vous ne pouvez pas être «sûr».
N'oubliez pas qu'il ne s'agit pas * seulement * des mots de passe - l'une des raisons pour lesquelles je déteste les "questions de réinitialisation de mot de passe" est que vous êtes plus ou moins obligé d'utiliser les mêmes questions - très courantes). Bien sûr, les mots de passe sont la chose la plus abusée * automatiquement *, mais il y a d'autres informations qui peuvent également être utilisées contre vous (comme "les 4 derniers numéros de votre carte de crédit", etc.) - chacune d'elles est inoffensive en soi, mais ensemble ... Et je serais plus méfiant envers les développeurs naïfs, plutôt que carrément malveillant. Au moins tant que vous ne visitez pas beaucoup de sites Web `.ru`: D
Vous ne le savez jamais. J'ai moi-même créé un système interne qui stocke le mot de passe chaque fois qu'un utilisateur s'authentifie dans le système. Cela fonctionne bien pendant un certain temps jusqu'à ce que je me sente paresseux et que je le supprime du système.
@Luaan a un très bon point - c'est la raison pour laquelle j'utilise de fausses réponses à ces questions même sur les sites les plus importants (quoi que ce soit de financier) ... Je peux toujours aller à la banque si c'est absolument nécessaire pour prouver mon identité.
@user1801810 J'utilise de longues chaînes aléatoires comme réponses et je les stocke dans un endroit relativement sûr. Si je perds à la fois l'emplacement sûr et le mot de passe, eh bien, il y a des moyens plus directs de vérifier. C'est juste une autre chose à laquelle il faut faire attention: (Et ils appellent cela * améliorer * la sécurité ...
Vous ne pouvez pas savoir s'ils se comporteront de manière éthique (et compétente) avec vos données, mais vous pouvez parfois savoir quand ce n'est pas le cas. Dans le cas du stockage des mots de passe en texte brut, s'ils apparaissent dans [** Plain Text Offenders **] (http://plaintextoffenders.com/), alors c'est un gros drapeau rouge pour faire attention à ce que vous leur donnez.
@StephanBranczyk Je tiens à ajouter qu'après avoir travaillé pour plusieurs institutions bancaires dans leurs différents départements de «sécurité», vous feriez bien de ne pas leur faire confiance pour conserver votre mot de passe de manière sûre, irréversible et cryptée.
@immibis TLS permet de fournir au serveur des certificats clients qui peuvent être utilisés à des fins d'authentification, mais la génération est coûteuse (à la fois en termes de temps et d'entropie), ils sont généralement difficiles à déplacer d'un appareil à l'autre et l'interface utilisateur est normalement incohérente à travers les implémentations (et parfois des changements entre les versions). À l'exception des limitations imposées par le site Web telles que la longueur maximale du mot de passe (qui ne devrait pas être nécessaire si vous faites un hachage de mot de passe approprié, par exemple), les mots de passe peuvent être arbitrairement complexes. Les certificats clients TLS présentent également des problèmes pratiques d'utilisation.
Même si vous pouvez leur faire parfaitement confiance pour se comporter de manière éthique, vous ne pouvez pas leur faire confiance pour ne jamais faire d'erreur. Tout le monde fait des erreurs, et quelqu'un pourrait faire l'une de ses erreurs en codant la façon dont votre mot de passe est stocké.
"Code reviews"....
Vous ne pouvez pas, j'ai des sites Web que j'ai codés avant même d'entrer à l'université et oui, ils stockent toujours des mots de passe en texte brut ..: / Les développeurs sont paresseux, si le framework ne le prend pas en charge nativement, il y a unrisque de ne pas implémenter le hachage.Utilisez les gestionnaires de mots de passe!
Cinq réponses:
AviD
2015-06-07 14:24:28 UTC
view on stackexchange narkive permalink

Bien sûr, ils le peuvent, mais ils peuvent également se contacter par e-mail chaque fois que vous modifiez votre mot de passe.

Maintenant, selon le type de système, il existe de nombreuses réglementations, audits, examens et processus qui pourraient être pertinents pour s'assurer que les développeurs ne le font pas, ou de nombreux autres types d'activités malveillantes . Cependant, en tant que consommateur, vous n'avez généralement pas beaucoup d'informations sur tout cela - sauf en cas de problème, par exemple s'ils vous envoient par courrier électronique votre mot de passe d'origine lorsque vous demandez à le réinitialiser.

Mais vous posez la mauvaise question ici.
Oui, il est important que les systèmes que vous utilisez soient développés de manière sécurisée, mais cela ne supprimera jamais l'élément de confiance implicite que vous aurez toujours dans le système lui-même - et, dans ce contexte, les développeurs sont équivalents au système lui-même.

La vraie question que vous devriez vous poser - et en fait vous semblez l’impliquer - est de savoir comment protéger vos autres comptes, sur d’autres systèmes, contre un développeur malveillant ou système .
La réponse est simple, vraiment - utilisez un mot de passe différent pour chaque système.

Permettez-moi de répéter cela, pour souligner:

NE JAMAIS RÉUTILISER LES MOTS DE PASSE SUR DIFFÉRENTS SYSTÈMES.

Créez un mot de passe unique (fort, aléatoire, etc.) pour chaque site, et ne saisissez jamais votre mot de passe pour SiteA sur SiteB.
Parce que, comme vous l'avez noté intuitivement, si SiteB a votre mot de passe pour SiteA sous quelque forme que ce soit, alors ce mot de passe n'est plus sécurisé de SiteB.

Juste pour le plaisir, voici un xkcd à ce sujet:

XKCD Password Reuse

Une dernière note, si vous commencez à vous inquiéter "Comment diable vais-je me souvenir d'un mot de passe fort indépendamment pour chaque site différent ?? !!?" - jetez un œil à cette question ici sur les mots de passe, et examinez également les gestionnaires de mots de passe (par exemple, Password Safe, Keepass, LastPass, 1Pass, etc.).

une alternative à avoir un mot de passe séparé pour chaque site est d'avoir une poignée de mots de passe que vous utilisez, et de basculer entre en fonction du niveau de sécurité d'un site et de votre confiance. C'EST À DIRE. un mot de passe pour votre email (qui contrôle la réinitialisation des mots de passe), un pour vos instituts bancaires, et un autre pour tous les sites de merde (forums / sites de jeux, sites qui vous obligent à créer un compte, etc.). tout comme vous avez un e-mail de spam (ou vous devriez), vous devriez avoir un mot de passe de spam.
Plutôt que des gestionnaires ** de mots de passe **, je recommanderais un ** générateur de mots de passe **. Il créera des mots de passe uniques à partir de l'adresse de site Web hachée + votre mot de passe principal. Cela vous évitera non seulement de vous souvenir des mots de passe, mais aussi de les inventer!
L'utilisation continue de générateurs de mots de passe comme vous le décrivez pose problème à @Agent_L. Ils n'acceptent pas très bien les modifications du mot de passe principal ou des mots de passe du site. Si quelqu'un est en mesure d'utiliser un gestionnaire de mots de passe à la place, il devrait probablement le faire.
n00b - donc si j'obtiens votre mot de passe suite à une attaque contre une banque qui fuit des informations, je peux obtenir tous vos comptes bancaires? Hmmm - pas votre meilleur plan!
@PwdRsch Comme tout, c'est une question de sécurité vs utilisabilité et comme à chaque fois, il s'agit de choisir le bon outil pour une tâche donnée. Bien sûr, pour la boîte aux lettres principale et la banque, il existe des mots de passe uniques qui ne doivent être stockés nulle part mais mémorisés. Mais la plupart d'entre nous ont des dizaines de comptes dont la sécurité ne signifie presque rien. Les générateurs sont parfaits pour cela, car les inconvénients que vous venez de décrire ne se matérialisent jamais.
@agent_l, chaque gestionnaire de mot de passe que j'ai examiné comprend un générateur de mot de passe lorsque vous avez besoin d'un nouveau mot de passe. je doute que quiconque crée ses propres mots de passe s'il utilise un gestionnaire.
Les générateurs ont l'air cool, mais si vous générez toujours vos mots de passe en utilisant le même nom de site + seed et ne sauvegardez jamais le résultat, comment réinitialiser votre mot de passe sur un site qui a été compromis? Non, les gestionnaires de mots de passe sont la solution. Chacun de mes comptes, qu'il soit vital ou trivial, est associé à un mot de passe aléatoire unique de 16 caractères.
@Mikkel 16 caractères? C'est l'école primaire ;-) Si vous n'avez pas besoin de vous en souvenir de toute façon, augmentez-la! 26 caractères, 32, facile ... (Bien que l'on puisse discuter de l'avantage supplémentaire que vous obtiendriez après, par exemple, 26 caractères ...)
@Agent_L comme sgroves l'a mentionné, tous les gestionnaires de mots de passe décents incluent la génération de mots de passe (qui fait partie de la gestion, ce n'est pas seulement "se souvenir"). Je n'étais pas explicite, mais cela est toujours supposé lorsque nous parlons de gestionnaires de mots de passe.
@sgroves, AviD, Mikkel - aucun de vous n'a abordé mon point principal: les mots de passe importants sont trop importants pour être enregistrés dans un gestionnaire. Les mots de passe triviaux sont trop simples pour être enregistrés dans un gestionnaire. C'est le point: je ne me soucie pas si mon mot de passe Stack a été compromis - il y a trop peu que je puisse perdre pour m'en soucier. Je n'utilise pas de gestionnaire pour enregistrer le mot de passe de mon poste de travail - il est trop important pour être enregistré n'importe où (en plus, je ne peux pas utiliser de gestionnaire pour la connexion Windows). Quoi qu'il en soit, cette discussion est grossièrement hors-sujet car même la réponse n'est pas sur le sujet.
@Agent_L mais je l'ai abordé. Les mots de passe importants doivent être forts - vraiment forts, trop forts pour être mémorisés. D'un autre côté, il existe des situations où vous devez réellement vous souvenir du mot de passe - et c'est là que les mots de passe entrent en jeu, comme je l'ai mentionné dans ma réponse.
"Mais vous posez la mauvaise question ici." Non, vous répondez à la mauvaise question. Le premier et le deuxième paragraphe sont ok, le reste ne fait que gonfler.
@ChristianStrempfer pourquoi pensez-vous que c'est la mauvaise question? L'OP a clairement indiqué qu'il s'inquiétait du fait que les développeurs utilisent son mot de passe pour accéder à son compte de messagerie. J'ai clarifié pourquoi "comment empêcher que les développeurs enregistrent les mots de passe des utilisateurs" est la mauvaise solution, et d'ailleurs le point. Il était clair qu'il s'agissait d'un cas de problème XY; Je l'ai concentré sur la cause profonde et lui ai indiqué des solutions réelles à son vrai problème.
@agent_l quels mots de passe sont trop importants pour être enregistrés dans un gestionnaire? peut-être quelque chose pour le travail, mais vous pouvez utiliser un compte séparé pour cela. Je serai heureux de stocker tous les mots de passe dans un gestionnaire, cependant ... tout est stocké localement.
@AviD: Ce n'est pas clairement un problème XY pour moi. L'OP est conscient que la connaissance du mot de passe simple, pourrait être utilisé pour «pirater» un autre site. C'est une question courte et précise.
@AviD: Ne vous méprenez pas. Ce n'est pas un problème que vous mentionniez les dangers de la réutilisation des mots de passe, mais cela représente 90% de la hauteur des réponses à l'écran, alors que cela ne devrait être qu'une note latérale.
@ChristianStrempfer l'OP fonde son évaluation des risques de la menace du «développeur contraire à l'éthique ne hachant pas le mot de passe», sur l'hypothèse d'une réutilisation du mot de passe. Pour moi, cela semblait être le cœur, d'où la raison pour laquelle j'ai dit que c'était un problème XY, l'OMI. C'est pourquoi j'ai concentré l'essentiel de la réponse sur la réponse au problème de réutilisation des mots de passe.
Grizzled
2015-06-07 15:48:17 UTC
view on stackexchange narkive permalink

Vous ne pouvez pas savoir que quelqu'un se comportera de manière éthique ou judicieuse, donc:

  1. Ne réutilisez jamais les mots de passe sur les sites.
  2. Décidez de la quantité d'informations à partager.
  3. Ne divulguez pas les informations qui ne sont pas nécessaires et soupçonnez tout site Web qui demande plus d'informations que ce qui est nécessaire pour vous fournir un service particulier.

J'ai peur que certains développeurs ne le soient pas Ce n’est pas assez avant-gardiste pour comprendre les implications d’une fuite d’informations pour leurs utilisateurs, alors protégez-vous plutôt que de vous fier aux autres.

+1 "ou à bon escient", car il y a peu de différence pratique pour moi entre un programmeur qui vole intentionnellement mon mot de passe, et un administrateur système qui prépare l'installation Linux, le serveur s'enracine et un pirate vole mon mot de passe. Si quelque chose que je préfère * légèrement *, c'est le programmeur, puisque l'entreprise impliquée a au moins une adresse à donner aux flics.
... a une adresse à donner aux flics: je suis un pigiste travaillant en Asie, et presque personne ne me demande mon adresse. Mais les développeurs et les administrateurs système ont la plus grande confiance dans la chaîne.
fotijr
2015-06-08 18:22:12 UTC
view on stackexchange narkive permalink

Comme d'autres l'ont dit, vous ne pouvez pas savoir ce que les développeurs font de vos données une fois que vous les avez transmises. Cela peut vous donner une certaine confiance pour examiner le fonctionnement du site pour voir s'il suit les meilleures pratiques de sécurité sur les éléments du système visibles par vous.

  • Utilisent-ils HTTPS sur les pages contenant des informations sensibles (y compris la connexion)?
  • Est-ce qu'ils évitent de transmettre la phrase secrète n'importe où, y compris les e-mails (même pas à vous)?
  • Permettent-ils une authentification à deux facteurs?

Cocher ces cases ne garantit pas qu'ils ne font pas quelque chose de louche ailleurs, mais cela vous donne une meilleure idée de la façon dont le les développeurs ont configuré le site.

Comme mentionné, éviter la réutilisation des mots de passe est la pratique de sécurité la plus importante que vous puissiez suivre pour vous protéger.

J'ajouterais une case supplémentaire pour vérifier: "Est-ce qu'ils restreignent inutilement les caractères que vous pouvez utiliser dans votre mot de passe?" Un mot de passe correctement haché est difficile à distinguer des données binaires aléatoires, et donc tout ce qui stocke un tel hachage doit pouvoir prendre en compte toute séquence possible (par exemple, en codant en hexadécimal le hachage pour le stockage, puis en le décodant lorsque vous devez comparer quelque chose au hachage). Si le site restreint les caractères que vous pouvez utiliser dans votre mot de passe, cela peut être dû au fait que quelqu'un ne le stocke pas correctement.
@TheSpooniest: Le code requis pour mapper les chaînes ASCII en séquences d'octets de telle sorte que les chaînes qui se comparent égales produiront toujours la même séquence d'octets est trivial. Le code requis pour faire de même avec toutes les chaînes Unicode possibles est extrêmement compliqué et comporte de nombreux coins étranges, surtout si l'on considère les possibilités de caractères mixtes de gauche à droite et de droite à gauche. On pourrait autoriser beaucoup de caractères non ASCII sans difficulté, mais il est plus facile de fournir une petite liste de caractères autorisés que d'expliquer quels caractères sont et ne sont pas autorisés.
@supercat: Cela ne tient que si vous essayez d'afficher les mots de passe aux utilisateurs, et j'espère vraiment que vous ne le faites pas. Si ce n'est pas le cas, choisissez simplement un encodage à utiliser en interne, encodez le mot de passe en conséquence, exécutez-le via votre algorithme de hachage et encodez en Base64 ou hexadécimal. Après cela, il s'agit simplement de vous assurer que vos champs de mot de passe utilisent cet encodage, ou que vous pouvez détecter l'encodage qu'ils utilisent si, pour une raison quelconque, ils doivent en utiliser un autre.
@TheSpooniest: Avec ASCII, on peut assez bien garantir que si quelqu'un tape "Fred123" comme mot de passe, chaque caractère ASCII générera un point de code; si quelqu'un tape un mot de passe avec des signes diacritiques ou un mélange de caractères de droite à gauche ou de gauche à droite, la séquence exacte des points de code reçus peut être différente sur différents navigateurs. Si quelqu'un tape un accent de combinaison suivi d'une lettre et que la combinaison se trouve dans les tableaux de certains navigateurs mais pas dans d'autres, alors certains navigateurs peuvent signaler cela comme un caractère et d'autres comme deux. Si l'on stockait du texte brut, ce serait possible ...
... dire accepter tout mot de passe dont la forme normalisée correspond à la forme normalisée de ce qui se trouve dans la base de données, et ne pas avoir à s'inquiéter de la possibilité qu'une table de normalisation incorrecte puisse amener la base de données à stocker un hachage qui ne correspondra à aucun correctement - mots de passe normalisés après la fixation de la table.
Andrew Smith
2015-06-07 13:14:35 UTC
view on stackexchange narkive permalink

Une façon dont vous pouvez savoir qu'ils sont en mesure d'obtenir votre mot de passe est de savoir si le système de mot de passe oublié est capable de vous envoyer votre ancien mot de passe par e-mail. Si cela vous oblige à en générer ou en définir un nouveau, il est toujours possible qu'ils aient été stockés en texte brut / cryptage bidirectionnel.

L'autre façon dont vous pouvez le savoir est de vous inscrire à un compte hotmail gratuit et en vous inscrivant à quelques sites (de confiance) avec le même mot de passe, voyez si quelque chose se passe.

À part cela, vous ne pouvez pas vraiment le dire.

Agent_L
2015-06-08 22:25:48 UTC
view on stackexchange narkive permalink

La seule façon pour un site Web de prouver qu'il ne stocke PAS votre mot de passe en texte clair est de ne jamais le recevoir en texte clair. Cela ne peut être réalisé que via un script de hachage côté client. À moins que vous ne puissiez analyser le code du site Web et / ou détecter le trafic, vous devez supposer que l'administrateur connaît parfaitement votre mot de passe en texte clair.

Voir cette question d'un administrateur qui le souhaitait donner à ses utilisateurs la tranquillité d'esprit que vous recherchez. il a de nombreuses réponses intéressantes, même si la plupart d'entre elles se concentrent sur la sécurité plutôt que sur la preuve de ne pas stocker de texte en clair.

@cHao: cela a été discuté dans la question http://security.stackexchange.com/questions/23006/client-side-password-hashing et l'OP est arrivé à la conclusion que la meilleure façon de faire les choses était de hacher à la fois du côté clientet au serveur.Le hachage côté serveur résout le problème de relecture de mot de passe que vous mentionnez et le hachage côté client empêche le site Web de déterminer le type de types de mot de passe que l'utilisateur utilise (mots de passe utilisateur similaires entre les sites et / ou entre les changements de mot de passe).
@MarkRipley: Cela semble être une bonne idée.Malheureusement, je ne me souviens pas exactement à quel commentaire vous répondez, car il ne semble plus exister.: P Mais en regardant la réponse, je peux réinventer ce que j'aurais dit ...
@cHao AFAIK vous avez suivi (ou obtenu un suivi) dans un problème complètement différent d'une attaque de relecture, tout comme la réponse liée.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...