Question:
Y a-t-il une raison de ne pas afficher les mots de passe mal saisis aux utilisateurs après une connexion réussie?
RaunakS
2016-09-09 23:35:54 UTC
view on stackexchange narkive permalink

Notre client a émis l'exigence que si le nom d'utilisateur en question a eu plusieurs tentatives de connexion infructueuses, le ou les mots de passe mal saisis doivent être affichés une fois la connexion réussie. Les informations correctement saisies, y compris les mots de passe précédents, ne seront pas affichées dans tous les cas.

Notre développeur principal nous a dit que c'était techniquement possible en ne hachant pas les entrées incorrectes, mais elle est extrêmement mal à l'aise avec la fonctionnalité et donc elle a été mise en attente pendant que nous réfléchissons.

Le site Web en question est une large application de cartographie / SIG qui ne comporte aucune transaction monétaire quoi que ce soit. Les autres options de connexion / authentification incluent Google / LinkedIn / Twitter / Facebook, donc évidemment aucun mot de passe à y stocker et la gestion qui est principalement un problème UX.

Quelles vulnérabilités de sécurité viennent avec la mise en œuvre d'une telle fonctionnalité? Notre client n'est pas entièrement dépourvu de connaissances techniques, donc une explication générale suffit.

Mes excuses si la question est trop large ou la réponse très évidente.

Demandez au client pourquoi.Puis demandez pourquoi à propos de tout ce qu'ils disent.Ils peuvent avoir une idée, mais ils ne veulent sûrement pas faire cela.
énorme responsabilité juridique - ne pas mettre en œuvre à moins que le client ne supprime toutes les obligations légales de votre entreprise
Ce que dit @timpone.Parce que, comme n'importe qui dans l'infosec le sait parfaitement, les humains ont souvent 100 comptes (j'en ai 154) et aucun humain ne peut se souvenir de tout cela, la réutilisation se produit.Même si votre site a peu à perdre, et même si l'utilisateur partage son mot de passe avec d'autres sites avec peu de choses à perdre (par exemple FooFlix, que va-t-il faire, streamer des films?) Imaginez sa surprise lorsqu'un hacker * trouve un moyen * (par exemple, l'achat de milliers de dollars d'adhésions cadeaux).
(Convainquez votre client et) allez simplement avec les informations standard de l'économiseur d'écran: * "Il y avait eu X tentatives de connexion infructueuses" *.
Montrez-leur un journal SSH d'un serveur public, montrez comment il enregistre en permanence les échecs de connexion du monde entier.Le contenu le plus probable de ce journal sera 100 Mo de tentatives de "mot de passe", "1234", etc. - pas utile pour quelqu'un de voir * chaque connexion *.Si vous effacez le journal après une connexion réussie, quelqu'un ne saura jamais si quelqu'un d'autre s'est connecté en tant que lui après avoir deviné le mot de passe à plusieurs reprises.Si vous ne le faites pas, vous verrez toujours des fautes de frappe précédentes que vous connaissez et dont vous ne vous souciez pas.Et si vous voyez deux échecs de connexion, à quoi cela sert-il de toute façon?A qui profite cette «fonctionnalité»?
Tricky ... Pour ma part, j'ai un (grand) ensemble de mots de passe que j'utilise sur divers sites, donc même si un mot de passe peut être incorrect sur un site, il le serait toujours sur plusieurs autres sites.Par la suite, je préférerais qu'un site ne semble pas stocker mes mots de passe "incorrects", ni me les renvoyer ** en clair ** pour que quiconque puisse les lire!
Au lieu de cela, fournissez un bouton sur lequel l'utilisateur peut cliquer pour masquer / démasquer le champ de mot de passe.Les mots de passe ne doivent pas être affichés sauf si l'utilisateur s'y attend.
Un stockage sécurisé des mots de passe incorrects est possible.Mais les réponses fournies jusqu'à présent vous donnent déjà des raisons suffisantes pour lesquelles vous ne devriez pas le faire.Je ne vais donc pas vous donner l'algorithme.Au lieu de cela, je vais vous dire que les mots de passe appartiennent aux utilisateurs.Les mots de passe n'appartiennent pas à votre client.Ce que votre client vous demande de faire, c'est l'abus de ces mots de passe.Vous devez vous demander si vous voulez vraiment aider votre client à abuser de ses utilisateurs.Ce dont vous avez vraiment besoin, c'est du meilleur argument possible pour convaincre votre client d'opter pour une solution appropriée à la place.
Peut-être que votre client voulait afficher le nombre de mots de passe mal saisis au lieu des mots de passe réellement incorrects.Le premier est ce que SAP fait aussi.Ce dernier est inouï.
C'est une idée terrible.Le problème de hachage et le problème d'exposition du nom d'utilisateur / mot de passe de compte croisé devraient exclure cette idée.Je cherche toujours des réponses à des problèmes comme celui-ci et je pense que si c'était un bon modèle, des endroits comme Google, etc. l'utiliseraient.Faites-le remarquer à votre client avec tous les points déjà mentionnés.Rappelez toujours aux clients que la roue a rarement besoin d'être réinventée.
** Mauvais mauvais mauvais: ** `hunter3`,` junter2`, `hunrer2` et maintenant vous connaissez mon mot de passe.
Je connais un site Web qui fait cela (ou du moins, utilisé).Et j'ai profité de cette «fonctionnalité» pour contourner les conditions de service de ce site Web concernant le non-partage des informations de contact avec d'autres utilisateurs.
High five au développeur principal qui a exprimé son inconfort et provoqué ce problème!
Si vous pouviez mesurer à quel point il était différent du mot de passe d'origine, vous pourriez afficher des fautes de frappe, mais vous devrez alors stocker vos mots de passe sans hachage.
en ajoutant simplement des ingrédients aux réponses déjà excellentes ci-dessus, utilisez ce site pour voir https://haveibeenpwned.com/
En général, si je trouvais un projet Open Source faisant cela, je lui attribuerais probablement un identifiant CVE car cela serait généralement considéré comme une vulnérabilité de sécurité.
en tant qu'administrateur système, il est utile de caractériser d'une manière ou d'une autre les tentatives infructueuses, de faire la distinction entre un utilisateur essayant de se souvenir et de taper son propre mot de passe, et une sorte d'attaque.Si c'est le premier, proposez de l'aide à l'utilisateur.Dans ce dernier cas, lancez des mesures défensives.
votre développeur principal est intelligent, ne la laissez pas partir
Deux mots: erreurs de transposition.
Si je rencontrais un système qui me présentait mes mots de passe en clair et mal saisis, je fermerais mon compte et arrêterais d'utiliser ce système et recommanderais à mes amis et à ma famille d'éviter ce service.Il est pratiquement garanti que si j'ai mal tapé mon mot de passe, il est soit désactivé d'un caractère, soit j'ai tapé l'un de mes mots de passe à partir d'un autre compte.Quoi qu'il en soit, il est négligent pour toute entreprise de garder une liste de mes mots de passe mal saisis.C'est juste une très mauvaise idée.
Treize réponses:
PwdRsch
2016-09-10 00:08:45 UTC
view on stackexchange narkive permalink

Le principal problème est que les mots de passe incorrects doivent être stockés de manière à pouvoir être affichés ultérieurement aux utilisateurs. Ce qui, comme votre développeur l'a souligné, signifie qu'ils ne peuvent pas être d'abord hachés cryptographiquement. Le résultat est que vous les stockez sous forme de texte brut (mauvais) ou chiffré (mieux mais normalement pas recommandé).

Le plus grand risque est si cette base de données de mots de passe invalides devient accessible aux attaquants. Soit ils compromettent le serveur, effectuent une injection SQL ou le récupèrent d'une autre manière. Plutôt que de déchiffrer les mots de passe principaux, qui, espérons-le, sont fortement hachés et donc des cibles plus difficiles, ils pourraient décider de compromettre les comptes en utilisant les informations de l'historique des mots de passe invalides. Soit ils accèdent facilement aux mots de passe en texte brut, soit ils tentent de trouver la clé de chiffrement qui leur permet de déchiffrer les mots de passe en texte brut.

Une source courante d'échecs de connexion est les fautes de frappe mineures lors du processus de saisie du mot de passe. Donc mon mot de passe est Muffins16 mais je tape mUFFINS16 car mon verrouillage des majuscules est activé. Ou Muffins166 parce que j'ai appuyé deux fois sur la même touche. Ou Muffina16 parce que mon doigt a frappé la mauvaise touche. Comme vous pouvez le voir, ces variantes sont suffisamment proches de l'original pour que les attaquants puissent probablement déterminer le mot de passe valide à partir de mots de passe non valides en essayant quelques modifications mineures ou en comparant des mots de passe incorrects à des mots ou des noms probables du dictionnaire.

Ce problème est exacerbée parce que la plupart des gens utilisent des choix de mot de passe similaires à ces formats et non des chaînes aléatoires. Il est plus difficile pour un attaquant d'identifier la faute de frappe si votre mot de passe invalide est V8Az $ p4 / fA, bien qu'il soit encore beaucoup plus facile d'essayer des variantes de cela, puis de le deviner sans aucune information.

Un autre risque est que les utilisateurs ne se souviennent pas lequel de leurs mots de passe ils ont utilisé sur ce site afin d'essayer les mots de passe courants. Maintenant, ce site est soudainement une cible plus importante car un attaquant pourrait être en mesure non seulement de compromettre le compte d'un utilisateur là-bas, mais aussi sur d'autres sites avec la liste pratique de mots de passe "invalides".

Vous pouvez atténuer certains de ces risques en effaçant le stockage des mots de passe invalides immédiatement après leur affichage après une connexion valide. Cela devrait limiter la fenêtre d'opportunité pour un attaquant d'accéder aux données et d'en profiter.

La question que vous devriez probablement poser à votre client est de savoir comment il prévoit que les utilisateurs bénéficieront de voir leurs mots de passe invalides. Est-ce pour que les utilisateurs puissent identifier comment ils ont mal saisi leur mot de passe? Les fautes de frappe ne sont pas intentionnelles, il est donc peu probable que leur montrer leur erreur améliore les futures tentatives de connexion. Ainsi, les utilisateurs peuvent identifier un attaquant essayant de deviner leurs mots de passe? Des commentaires similaires peuvent être fournis en indiquant la date, l'heure, l'adresse IP / la géolocalisation ou d'autres informations pour les tentatives non valides sans le mot de passe tenté. Ainsi, les utilisateurs savent-ils qu'ils ont foiré lors de la saisie du mot de passe et ne blâment pas le système de connexion du site? Cela semble être le seul à avoir du mérite et je ne suis pas sûr qu'il fournisse suffisamment de valeur pour justifier le risque.

Je suppose qu'une fois que vous aurez mieux compris ce qu'ils essaient d'accomplir avec cette fonctionnalité, vous pouvez suggèrent probablement des alternatives plus sûres.

Quelle est votre adresse e-mail pour que je puisse essayer le mot de passe Muffins16 dessus?Je veux dire, discuter de ce sujet important avec vous davantage?
C'est évidemment une astuce, le vrai mot de passe * est * mUFFINS16.
Cracker la base de données serait * extrêmement * facile - essayez simplement 1000 tentatives de mot de passe incorrect sur plusieurs dizaines de comptes avant de voler la base de données chiffrée.Voila, vous avez maintenant plusieurs milliers de mots de passe erronés "connus en clair" dans la base de données à partir desquels vous pouvez trouver la clé de chiffrement.
@Wildcard euh, quoi?Pourquoi le texte brut connu aiderait-il à déchiffrer la clé d'un algorithme de cryptage moderne?
Au moins un mot de passe root du système a été compromis à partir de la liste de mots de passe incorrects.
@Ben Je pense que son point est de craquer les mauvais mots de passe qui sont stockés dans la base de données.En supposant que ceux-ci sont stockés cryptés.Si un attaquant a ou aura accès aux données de la base de données, le fait d'avoir une très grande plage d'entrées connues aidera à inverser la sortie, révélant ainsi le cryptage utilisé, ce qui signifie que vous aurez alors un accès facile à tout mot de passe erroné.stocké dans la base de données.
Un vote favorable ne suffisait pas pour cette réponse incroyable.J'apprécie vraiment votre contribution.
@vlaz, le fait est que la crypto moderne n'est pas vulnérable à une [attaque en texte brut connu] (https://en.wikipedia.org/wiki/Known-plaintext_attack) donc avoir un certain nombre de textes en clair connus ne vous aidera pas à déchiffrer les mots de passe cryptés.
Le surf sur l'épaule est un autre problème assez important.Je n'ai pas besoin de casser votre serveur si le simple fait de regarder l'écran de quelqu'un permet d'obtenir la même chose.Et, bien sûr, si le PDG a lésiné sur un certificat SSL, vous avez des problèmes beaucoup plus importants que cela, vous pourriez donc aussi bien ne pas les exacerber encore plus.
Mis à part le fait que l'idée générale n'est pas si géniale;le risque principal identifié ici pourrait-il être atténué en accumulant des tentatives de mot de passe incorrectes dans un cookie plutôt qu'en les stockant de manière persistante côté serveur, ou même en le faisant entièrement côté client avec un stockage local?Vous perdriez la possibilité de voir les échecs de connexion d'autres machines ... mais il n'est pas vraiment clair que ce soit une exigence de la description de l'OP.
Si l'intention est de montrer comment les utilisateurs saisissent mal leurs mots de passe, l'option la plus sûre serait de fournir un bouton pour afficher leur mot de passe au fur et à mesure de leur saisie.Et il serait préférable de ne pas soumettre la valeur visible;c'est-à-dire que la valeur `
@JasonC:, malheureusement, stocker des mots de passe dans des cookies présente le même risque car ils peuvent être utilisés pour deviner votre mot de passe à partir de vos tentatives infructueuses.Même si les cookies sont cryptés, la clé doit être stockée quelque part.Si cette clé est compromise, la partie est terminée (accéder aux cookies est très facile si vous avez un accès physique à l'appareil, et relativement facile si vous pouvez injecter du code dans le système).
@lepe Vous n'avez pas besoin d'un cookie pour cela.Lorsque le serveur répond par une tentative de connexion infructueuse, le client ne peut-il pas stocker ces valeurs localement, en mémoire?Ensuite, une fois que le serveur répond enfin avec un Login OK, le client peut afficher tous les mots de passe qu'il a en mémoire.Rien de tout cela ne nécessite de stocker des mots de passe non hachés côté serveur ou dans un cookie, et cela n'introduit pas plus de risque que celui impliqué dans la collecte et la soumission des informations de connexion en premier lieu.
Un autre problème serait que les gens oublient le mot de passe qu'ils ont utilisé pour votre connexion.J'imagine qu'un nombre important d'utilisateurs utilisent une poignée de mots de passe sur tous les comptes.Si l'un d'entre eux ne fonctionne pas, ils parcourent simplement leur liste jusqu'à ce que l'un d'eux fonctionne.Enregistrer leurs tentatives infructueuses signifie enregistrer les mots de passe réels sur d'autres sites.
@Andonaeus: oui c'est une possibilité.Je ne sais toujours pas quelle est leur intention derrière cette demande.S'ils veulent montrer une tentative de connexion (ce que je pense que ce pourrait être le cas), alors ce dont nous discutons ici est un animal totalement différent.
Quoi que vous fassiez, le mot de passe incorrect sera temporairement stocké quelque part en mémoire.Normalement, pour conserver cela plus longtemps, vous stockez simplement le mot de passe dans une session, ce qui est temporaire et normalement uniquement en mémoire, et non dans un stockage persistant.Franchement, quel est le risque supplémentaire réel que les mauvais mots de passe soient stockés pendant une période plus longue (minutes?) Pendant que l'utilisateur se connecte?Pour même effectuer le hachage, vous devez évidemment avoir le mot de passe en mémoire, de sorte que vous n'obtiendrez jamais la perfection de toute façon.
@corsiKa Mes enfants me disent que si le mot de passe est Muffins16, alors l'adresse e-mail doit être derpy.hooves@ponyville.eq
TTT
2016-09-10 00:03:16 UTC
view on stackexchange narkive permalink

tldr; c'est encore pire que de ne pas hacher vos mots de passe et de les stocker sous forme de texte brut.

Je suis d'accord avec les préoccupations de votre développeur principal. Pour afficher les tentatives de mot de passe incorrectes, vous devez les stocker de manière réversible, ce qui signifie qu'elles ne peuvent pas être hachées. Si quelqu'un compromettait le système, il aurait alors accès à toutes les mauvaises tentatives et pourrait probablement reconstituer les vrais mots de passe de certains utilisateurs. Par exemple, si vous pouvez voir que certaines de mes mauvaises tentatives ont été: 

  agrafe de batterie horrible correcte, agrafe de batterie de cheval correcte

Ce serait assez facile à comprendre mon mot de passe actuel.

Je suis également d'accord avec la réponse de drewbenn: si je saisis mon nom d'utilisateur incorrectement mais avec mon mot de passe correct, et que le nom d'utilisateur incorrect se trouve être le nom d'utilisateur de quelqu'un d'autre, maintenant cet utilisateur peut voir mon vrai mot de passe.

Autre vulnérabilité: une fois que vous vous êtes connecté avec succès, toute personne qui regarde également votre écran peut voir les mauvaises tentatives _ sans même avoir à accéder à la base de données_.
De plus, vous ne pouvez pas supprimer le mot de passe correct (horse battery staple) une fois qu'il a été haché;il faut attendre qu'il ait été vérifié pour savoir s'il faut le conserver ou le purger.
@GhillieDhu C'est une fenêtre de temps très courte et le mot de passe ne serait que dans la RAM.(Et le mot de passe était * déjà * dans la RAM pour que vous puissiez le hacher, le garder là pendant quelques millisecondes de plus ne fera rien de significatif)
Le paragraphe du bas de cette réponse est à peu près le plus accablant des exemples montrant que cela ne devrait ** JAMAIS ** être fait.
Ne devrait-il pas dire tsdr ;?
user15392
2016-09-09 23:38:27 UTC
view on stackexchange narkive permalink

Une fois, j'ai essayé de me connecter à un système en utilisant mon mot de passe mais le nom d'utilisateur de mon collègue.

Ensuite, j'ai utilisé le mauvais mot de passe à chaque fois en essayant de me connecter à un compte partagé.

Et je sais que beaucoup d'administrateurs ont accès au compte de leur patron afin qu'ils puissent faire avancer les choses. Je serais assez choqué si leurs patrons n'avaient jamais entré le mauvais mot de passe, puis étaient distraits par un visiteur avant de se connecter correctement pour effacer l'erreur.

Plus toutes les fautes de frappe lorsque quelqu'un se tient au-dessus de mon épaule pendant que je ' m connexion.

Et dans tous ces cas, j'ai parfois entré mon mot de passe gmail ou lastpass dans l'invite de mot de passe au travail, et vice versa.

Et le temps J'ai recherché mon mot de passe sur Google parce que je ne regardais pas l'écran et je pensais simplement qu'il était verrouillé. Ce n’est pas que cela ait quoi que ce soit à voir avec votre proposition, mais j’aime partager cette anecdote car elle rappelle aux gens que tout le monde peut parfois faire une erreur et taper la mauvaise chose.

Le la seule chose que fait cette fonction hUnt3r2 est de transformer de petites erreurs (entrer le mauvais mot de passe ou le saisir par erreur) en expositions accidentelles à un public plus large.

Si je veux cracker votre compte drewbenn, tout ce que j'ai à faire est de configurer quelques types courants de votre nom d'utilisateur: drewben / derwbenn / ... et attendez que vous ayez mal saisi votre nom d'utilisateur et m'envoyez votre mot de passe: -o
@Falco, vous devriez ajouter cela comme réponse.C'est un bon moyen d'attaquer activement les utilisateurs sur un système comme celui-ci (et quelque chose qui serait invisible pour la cible, en supposant la mesure de sécurité commune (et bonne) où «mauvais mot de passe» renvoie le même code d'erreur que «utilisateur invalide»).
John Wu
2016-09-10 02:39:07 UTC
view on stackexchange narkive permalink

Perte de réputation

La mise en place d'un tel mécanisme entraînerait une perte de réputation immédiate, étant donné qu'il y a eu des cas très médiatisés où des tentatives de connexion infructueuses ont été utilisées pour attaquer d'autres sites. Voici un exemple:

Mark (Zuckerberg) a utilisé son site, TheFacebook.com, pour rechercher les membres du site qui se sont identifiés comme membres du Crimson. Puis il a examiné un journal des échecs de connexion pour voir si l'un des membres de Crimson avait déjà entré un mot de passe incorrect dans TheFacebook.com. Si les cas dans lesquels ils avaient entré des connexions échouaient, Mark a essayé de les utiliser pour accéder aux comptes de messagerie des membres de Crimson à Harvard. Il a réussi à accéder à deux d'entre eux.

En d'autres termes, Mark semble avoir utilisé les données de connexion privées de TheFacebook pour pirater les comptes de messagerie séparés de certains utilisateurs de TheFacebook.

Source: Comment Mark Zuckerberg a piraté le Harvard Crimson

Une alternative

Si votre client est déterminé à se montrer a échoué tentatives de connexion lors de la prochaine connexion réussie, comme une sorte de mesure de bien-être, puis-je suggérer une alternative? Au lieu d'afficher les mots de passe ayant échoué, affichez l'adresse IP et les informations de géolocalisation du navigateur qui a soumis le mauvais mot de passe. Cela devrait être assez facile à faire, ne poserait pas de problème de sécurité et fournirait des informations beaucoup plus utiles en cas d'activité malveillante réelle.

Belle alternative!Il pourrait être étendu pour inclure également des informations statistiques sur la proximité des mots de passe défectueux par rapport au mot de passe réel, comme «4% de différence».Ainsi, l'utilisateur peut encore mieux juger quelles étaient ses propres tentatives de connexion infructueuses et quelles étaient les tentatives de piratage.Difficile à mettre en œuvre cependant, car nous ne pouvons accéder en toute sécurité qu'à un mot de passe échoué ou au mot de passe réel en texte clair (lors de la connexion avant le hachage) et ne pouvons pas les stocker.Peut-être possible avec le [cryptage fonctionnel] (https://en.wikipedia.org/wiki/Functional_encryption)?
@tanius non, le site ne devrait ** pas ** pouvoir calculer cette différence!
Votre alternative mentionnée est ce qui se passe sur Steam lorsque votre compte a été compromis mais que l'attaquant n'a pas accès à votre deuxième facteur d'autorisation.Vous verrez quel appareil tente d'accéder afin que vous puissiez vérifier si vous avez foiré quelque chose ou si vous êtes attaqué.Cela fonctionne plutôt bien et est bien meilleur que ce que le client d'OP a proposé.
@guntbert, au moment où les mots de passe incorrects * seraient * affichés, le mot de passe correct est disponible pour comparaison même s'il est correctement haché, car l'utilisateur vient de le saisir.
@Ben C'est vrai, mais le stockage des mots de passe incorrects est le problème (pas de hachage possible).
Pourquoi faisons-nous confiance à Mark avec la date de milliards de personnes alors qu'il s'est avéré être une personne peu fiable qui tente activement de pirater les gens?
Joshua Hunter
2016-09-14 02:30:19 UTC
view on stackexchange narkive permalink

Une raison non liée à la sécurité pour ne pas faire cela: un spam de connexion incorrect.

Je lance ma liste d'e-mails / noms d'utilisateur sur votre application. J'essaye de me connecter à chaque compte avec le même «mot de passe». Peut-être une phrase offensante; slogan politique, ou simplement une annonce pour un site Web.

Ensuite, chacun de vos utilisateurs se connecte, ceux avec les noms d'utilisateur / e-mails que j'ai devinés sont obligés de regarder tout ce que j'ai entré.

Cela donne à chaque personne anonyme un vecteur pour afficher le contenu à vos utilisateurs.

Dans le cas de collègues qui utilisent chacun le service et qui peuvent probablement deviner les noms de connexion de l'autre, cela peut même entraîner du harcèlement ou d'autres problèmes de ressources humaines sur le lieu de travail.

C'est une question très importante qui, à mon avis, n'a pas reçu suffisamment d'attention.
Je n'y avais pas pensé avant, mais c'est en fait un problème de sécurité.
sixtyfootersdude
2016-09-10 02:22:18 UTC
view on stackexchange narkive permalink

Que se passe-t-il lorsque je souhaite me connecter à votre application et que je suis assis avec mon collègue? Supposons que je saisis mal mon mot de passe. Dois-je maintenant le renvoyer pendant que je me connecte pour qu'il ne voie pas ma tentative de mot de passe?

"Que se passe-t-il lorsque je veux me connecter à votre application et que je suis assis avec mon collègue?"- Je connais quelqu'un dont tout le laboratoire, en tant que doctorants, s'est formé à lire les mots de passe des uns et des autres en se regardant les taper.Aide à le voir plusieurs fois, apparemment.Ça a dû être un rire une minute là-bas, et si vous faites cela, vous enlevez tout le plaisir.Règle de sécurité numéro un: ne soyez pas un killjoy, gardez le défi pour les attaquants.
webbster
2016-09-11 03:53:22 UTC
view on stackexchange narkive permalink

S'il y a des utilisateurs avec des noms d'utilisateur / adresses e-mail similaires, ils peuvent accidentellement tenter de se connecter au compte d'un autre utilisateur.

Un utilisateur malveillant pourrait alors utiliser sa liste de tentatives de mots de passe "incorrects" pour pénétrer dans des comptes avec des noms d'utilisateur / adresses e-mail similaires (par exemple, bill11, bill1, etc.).

Je pense il serait préférable de simplement lister les tentatives de connexion incorrectes et réussies avec l'heure et l'adresse IP pertinente.

Cela me semble être un risque bien plus grand que le risque accepté du «et si la DB tombe entre de mauvaises mains».Il existe un certain nombre de systèmes sur lesquels j'essaie de m'inscrire, de trouver mon nom d'utilisateur préféré et de parcourir les autres.Après un certain temps, j'ai oublié ce que j'ai utilisé pour un site particulier, je dois donc les parcourir en essayant de me connecter après une absence.Mais mon mot de passe est toujours calculé à partir du nom du site plus l'année et d'autres détails, il est donc inchangé.Ainsi, alors que la base de données PEUT tomber entre de mauvaises mains, il y aura des utilisateurs qui verront les mots de passe corrects des autres.
Seth R
2016-09-10 03:17:24 UTC
view on stackexchange narkive permalink

Je suis d'accord avec d'autres réponses en soulignant qu'il est facile de deviner le mot de passe d'un utilisateur si un attaquant a mis la main sur la liste des tentatives infructueuses.

Cela étant le cas, peu importe que votre système ne contienne aucune information sur les transactions monétaires. Il est courant que les utilisateurs utilisent le même mot de passe, ou des variantes du même mot de passe, sur plusieurs sites. On leur conseillera peut-être de ne pas le faire, mais cela arrive quand même. Donc, ce n'est pas parce que vous ne pensez pas que votre système expose des informations sensibles lui-même que les informations sensibles de vos utilisateurs ne sont pas mises en danger si votre système est compromis.

Si Joe User utilise le même mot de passe sur votre système comme il l'utilise pour sa banque, si un attaquant était capable de deviner son mot de passe sur votre système et de déterminer quelle banque Joe utilisait, l'attaquant pourrait avoir accès au compte bancaire de Joe. Ou les dossiers médicaux, ou tout autre système sur lequel Joe a utilisé ce mot de passe.

Vous ne protégez pas simplement les mots de passe de votre système.

Et si je saisis par erreur mon mot de passe bancaire top secret pour votre système, il sera également mémorisé.
Damian Yerrick
2016-09-12 04:20:09 UTC
view on stackexchange narkive permalink

Je soupçonne que votre client souffre d'un problème XY. Cela signifie prendre du recul et essayer de comprendre ce que votre client veut vraiment. Il est souvent utile de savoir que quelqu'un a essayé un mot de passe incorrect et comment ce mot de passe a été saisi, pas nécessairement quel ce mot de passe. Peut-être que le client veut juste assez d'informations pour distinguer les menaces bénignes, telles que le gros doigt sur votre propre mot de passe, des menaces plus suspectes, comme deviner les mots de passe à l'autre bout du pays sur un appareil qui ne s'est jamais connecté auparavant.

Alors interrogez votre client sur le modèle de menace et voyez si les informations suivantes sont suffisantes:

  • ID utilisateur pour lequel l'authentification a échoué (afin que vous sachiez à qui avertir pour chaque échec)
  • date et heure
  • adresse IP du client, agent utilisateur et géolocalisation approximative
  • si le client exécute JavaScript (les attaquants ne dérangent souvent pas)
  • si le client a présenté un cookie pour s'être connecté avec succès dans le passé

Ensuite, présentez une boîte d'avertissement basée sur ces informations lorsqu'un utilisateur se connecte avec succès après un ou plusieurs échecs.

Une boîte d'avertissement peut ne pas être suffisante s'il y a eu plusieurs tentatives.En outre, l'utilisateur devrait pouvoir revenir à la liste s'il le souhaite
La meilleure raison de ne pas montrer les anciens mots de passe est en effet que ** il n'est pas nécessaire ** de faire quelque chose d'aussi délicat.- Ma première réflexion sur les raisons pour lesquelles les gens voudraient cela, c'est qu'ils ne croient pas avoir de gros doigts, auquel cas vous pouvez simplement utiliser quelque chose comme «insérer un clic pour afficher le mot de passe», comme cela est implémenté dans les principales solutions logicielles.
v7d8dpo4
2016-09-10 11:44:06 UTC
view on stackexchange narkive permalink

Une solution possible: puisque le problème ici est de stocker des tentatives de mot de passe incorrectes en texte brut, évitez-le. Lorsque le mot de passe d'un utilisateur est défini, générez une clé publique et une paire de clés privées. Stockez la clé publique et la clé privée cryptées avec le mot de passe. Lors de la journalisation de mots de passe incorrects, cryptez-les avec la clé publique (et ajoutez du sel). De cette façon, seul l'utilisateur qui connaît le mot de passe correct peut voir les mots de passe incorrects.

Cela semble être une solution viable à la préoccupation majeure.Cela ne permet toujours pas de voir le mot de passe d'autres personnes en raison d'une connexion accidentelle avec votre nom d'utilisateur.Et bien sûr, la solution échoue lorsque vous modifiez votre mot de passe.Mais bonne idée.+1 de moi.
Cela n'empêche pas les attaques qui reposent sur [le nom d'utilisateur_ mal saisi.] (Http://security.stackexchange.com/a/136483/56961)
Parmi toutes les autres raisons, je pense que c'est une mauvaise idée, crypter et décrypter des données avec des clés asymétriques est littéralement des ordres de grandeur plus lent que le cryptage symétrique.La charge supplémentaire sur vos serveurs serait tout simplement ridicule.
@Craig SSL ne nécessite-t-il pas à peu près la même charge sinon plus que le chiffrement avec un chiffrement asymétrique?
SSL utilise un cryptage asymétrique pour générer et partager en toute sécurité une clé de cryptage symétrique, qui est ensuite utilisée pour crypter toutes les données en transit.
Il est tout à fait possible qu'il soit très tard lorsque j'ai rédigé ce commentaire et l'ai formulé plus sévèrement que je n'aurais pu le faire autrement.:)
Viktor Toth
2016-09-11 09:53:30 UTC
view on stackexchange narkive permalink

J'hésite à ajouter ici des réponses déjà excellentes, mais il y a un autre point important. À moins d'être absolument certain que les utilisateurs se connectent uniquement au site via HTTPS (et honnêtement, même pas dans ce cas), vous ne devriez même jamais avoir la possibilité d'afficher les mots de passe incorrects ... car ils ne devraient jamais être transmis (cryptés ou non) dans le première place.

Et peu importe que le site ne traite pas de transactions financières. Vous ne voulez toujours pas qu'il devienne le maillon le plus faible d'une chaîne.

Je suis donc entièrement avec votre développeur principal sur celui-ci. Je me battrais bec et ongles contre cette "fonctionnalité".

Pour que le serveur doive stocker, quoi, le hachage salé généré par le client?En quoi cela diffère-t-il du simple fait d'envoyer le mot de passe sur un canal sécurisé et de laisser le serveur le hacher à l'aide d'un véritable algorithme de résumé de mot de passe comme pbkdf2, bcrypt ou scrypt, dont aucun n'est implémenté dans les navigateurs Web (a) et (b) si lele client envoie un hachage, tout ce qu'il fait est de prouver qu'il connaît le hachage, non qu'il connaît le mot de passe réel, ce qui est finalement moins sûr que d'envoyer le mot de passe et de faire de la vraie cryptographie sur le serveur.
Il existe des implémentations bscrypt / scrypt en JavaScript.Et le double hachage peut garantir que ce que le client envoie ne devienne pas le mot de passe (ne peut pas être réutilisé).Ma préoccupation avec toute implémentation serait la manière dont un sel non prévisible pour le deuxième hachage est créé, stocké et envoyé au client.
Si le serveur envoie JavaScript au client pour hacher le mot de passe, vous étendez toujours le même niveau de confiance au propriétaire du serveur, et vous offrez la possibilité à un homme du milieu de vous envoyer un script modifié, en plus de supprimer la possibilité pour le serveur de version, de mettre à niveau et de contrôler facilement le protocole cryptographique utilisé, en plus d'exposer à tout attaquant potentiel le protocole que vous utilisez et le nombre de tours, etc. Je vois toujours plus de problèmes que d'avantages, avec respect.
Si je comprends bien votre point de vue, vous dites que parce que le JS lui-même vient du serveur, un homme du milieu a la même opportunité de voler le mot de passe que s'il avait été envoyé sans hachage / cryptage.Un canal sécurisé est donc nécessaire et un canal sécurisé atténue les problèmes associés à l'envoi d'un mot de passe non chiffré.Ai-je bien digéré votre point?
Essentiellement, mais ce n'est qu'un de mes points.Ce canal sécurisé est HTTPS avec secret de transmission et existe déjà.Si un serveur vous envoie un script pour traiter votre mot de passe, le serveur peut tout aussi bien traiter votre mot de passe en supposant que le canal est sécurisé.Il n'y a pas de gain net de hachage sur le client, mais il existe de nombreux problèmes potentiels de hachage sur le client.
Qu'en est-il des préoccupations suivantes: 1) au lieu d'un processeur, deux processeurs ont maintenant le mot de passe en texte clair, au moins temporairement;2) Et si le canal n'est pas sécurisé après tout?N’est-il pas utile d’établir une «norme d’or» d’authentification sécurisée, même sur http?Mes priorités sont-elles mal placées ici?
Si le canal n'est pas sécurisé, le hachage sur le client ne vous sert à rien car un homme du milieu peut facilement capturer le hachage et le rejouer.Si vous allez développer un protocole de poignée de main qui fait un petit va-et-vient défi / réponse pour établir un échange sécurisé, puis-je suggérer HTTPS?:-) Le CPU ne retient pas les informations (enfin, à part le cache CPU, qui peut ou non être vidé lors des changements de contexte, mais ne nous confondons pas avec ça).Les caches de RAM et de disque sont cependant une question différente sur le serveur * et * le client.
Je suis respectueusement en désaccord avec la première partie, car si le serveur envoie un sel unique et que le client hache avec ce sel (c'est le point sur le double hachage; premier hachage avec sel fixe qui a été utilisé pour stocker le mot de passe sur le serveur,deuxièmement, le hachage avec sel unique; hachages de serveur avec le même sel unique à comparer), le hachage n'est pas réutilisable via la relecture.Mais je comprends vos points sur les attaques de l'homme du milieu.Matière à réflexion, merci.
Nous avons reçu l'avertissement "chat".Mais ce que vous suggérez exige que le serveur transmette les deux sels au client, car on ne peut certainement pas compter sur le client pour se souvenir du sel d'origine.Lorsque le hachage du mot de passe a été initialement stocké sur le serveur, le mot de passe en texte brut devait être transmis au serveur, ou le hachage salé d'origine devait être envoyé, et il était interceptable.Et comme je l'ai mentionné précédemment, cela rend des choses comme la gestion des versions de l'algorithme de hachage de mot de passe plus difficiles et sujettes aux erreurs.Je vois juste une tonne de trous là-dedans.;-)
gnasher729
2016-09-10 20:21:29 UTC
view on stackexchange narkive permalink

Votre système aura une grande base de données déchiffrable de mots de passe. En recherchant les mots de passe incorrects pour l'utilisateur X, vous obtiendrez des mots de passe presque mais pas tout à fait corrects pour le compte de X, des mots de passe corrects pour différents comptes de l'utilisateur X, ainsi que des mots de passe corrects pour les comptes d'utilisateurs avec presque le même nom d'utilisateur que X.

Avec l'hypothèse raisonnable qu'un hacker pourrait s'introduire dans votre système et obtenir une copie déchiffrée de la base de données, ce serait désastreux. Même en supposant que l'accès à votre système par la mauvaise personne n'est pas trop critique, cette base de données contiendra les mots de passe de vos utilisateurs pour différents systèmes, ce qui pourrait être beaucoup plus critique.

ddyer
2016-09-15 23:03:12 UTC
view on stackexchange narkive permalink

Il me semble que dans une authentification correctement construite, le mot de passe saisi par l'utilisateur n'est même pas transmis au site hôte, donc la question du stockage des tentatives incorrectes est sans objet.

Il pourrait être acceptable de avoir une case à cocher «voir le mot de passe» dans l'interface, qui est strictement une fonction locale, et peut être utilisée soit lorsque le mot de passe est saisi, soit après une tentative infructueuse. Les informations enregistrées devraient probablement être effacées après un court laps de temps pour éviter de récolter les mots de passe des consoles abandonnées.

Hein?Le mot de passe que vous saisissez sur un site Web est toujours transmis au serveur hôte afin d'être vérifié.Impossible de faire confiance au client pour s'authentifier contre lui-même, et le hachage / obfuscation côté client est assez inutile.Le mot de passe est _ j'espère_ transmis en utilisant SSL / TLS, donc il est chiffré en transit, mais il _ est_ envoyé au serveur malgré tout.
Non, une variation de;le serveur vous donne une chaîne aléatoire, vous hachez le mot de passe avec la chaîne aléatoire et le renvoyez au serveur, le serveur compare ce que vous avez envoyé avec le résultat attendu, prouvant que vous connaissez le mot de passe.
_Et_ prouvant que le serveur stocke tous les mots de passe en texte brut.Sinon, il ne peut pas faire le hachage.C'est donc une solution bien pire.
Pas nécessairement, cela dépend du protocole de hachage exact.Par exemple, hachez le mot de passe avec une méthode fixe connue, qui reproduit théoriquement ce que le serveur stocke.Ensuite, hachez le résultat avec l'aléa nouvellement présenté (en évitant les attaques de relecture).
@ddyer comment proposez-vous que le serveur connaisse le résultat attendu, à moins que le serveur ne hache le mot de passe en utilisant le même algorithme pour effectuer la comparaison?Une poignée de main bien vérifiée pour établir un canal sécurisé est ce qu'est HTTPS.Il est difficile de faire correctement le chiffrement roll-your-own.
Ainsi, le serveur a eu le mot de passe en clair à un moment donné, afin de faire le premier hachage et de le stocker.Ou, le client l'a envoyé pré-haché, même la première fois.Mais dans ce cas, le hachage _ est_ le texte en clair, donc c'est inutile.Mais supposons que le serveur ait effectué le premier hachage à partir du vrai texte brut et que le client ait fait de même.Lors de la connexion, chacun fait un 2e tour en utilisant un nonce convenu et compare ses résultats.Mais ensuite, le client doit connaître l'ensemble de la stratégie de hachage du serveur.Le serveur ne peut pas garder pour lui des sels, des secrets ou des algorithmes;toute tentative de connexion devrait tout divulguer
Vous avez raison de dire que le mot de passe haché est effectivement le mot de passe, mais la question est de savoir ce qui est pire;en supposant que le mot de passe stocké du serveur est compromis, ou en supposant que l'accès momentané du serveur au mot de passe en clair (et aux mots de passe échoués) est un risque.Par exemple, les hacks SSL récents auraient révélé que les mots de passe étaient transmis "en toute sécurité" au serveur, mais n'auraient révélé que des hachages inutiles si le protocole n'avait jamais transmis de vrais mots de passe.En fin de compte, tout dépend de votre modèle de menace.


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