Question:
"Nom d'utilisateur et / ou mot de passe invalides" - Pourquoi les sites Web affichent-ils ce type de message au lieu d'informer l'utilisateur lequel est erroné?
bobble14988
2012-07-30 13:40:00 UTC
view on stackexchange narkive permalink

Disons qu'un utilisateur se connecte à un site typique, saisit son nom d'utilisateur et son mot de passe, et saisit une de ses entrées par erreur. J'ai remarqué que la plupart des sites, sinon tous, affichent le même message (quelque chose du genre "Nom d'utilisateur ou mot de passe invalide") malgré une seule entrée erronée.

Pour moi, cela semble assez facile pour informer l'utilisateur de quelle entrée était erronée et cela m'a fait me demander pourquoi les sites ne le font pas. Alors, y a-t-il une raison de sécurité à cela ou est-ce simplement quelque chose qui est devenu la norme?

For websites which offer a different way to see if a user exists, there is no security gain. They're just being annoying.
Non security reason: If the database contains salted and hashed passwords, determining that the password matches an existing one would require hashing the password provided with every salt (1 per user, we hope) in the database.
One totally non-security related reason is that it's possible the provider doesn't know which was wrong. E.g. if bob1AilidqjtvzCMT.com mistypes his user name as bob2AilidqjtvzCMT.com and there really is another user bob2AilidqjtvzCMT.com.
@MarkBeadles ... l'entité de connexion ne saura pas si le nom d'utilisateur est valide? Vous devrez peut-être expliquer cela de plus ...
1. BOB1@PROVIDER.COM mistypes id as "BOB2@PROVIDER.COM" and types his (own) password correctly2. A user BOB2 exists in the user store3. logon entity thinks that BOB2 mistypes his password, when in reality BOB1 mistyped his username.
I would agree that it is for security reasons. **I don't know any website where the username is supposed to be secret.** As an example: Google does the "Username and/or Password Invalid" thing but you can still find out if a username exists (by trying to register it).
@JoãoPortela, mais l'écran de création est gardé par captcha. C'est la différence.
Le rasoir d'Occam dit: Les programmeurs sont paresseux. :)
AilicnlmpvCMTãoPortela not all systems allow you to self-register automatically.
Parce que les pirates peuvent facilement pirater les comptes s'ils savent quelque chose correctement
AilindrnzuCMT fair point (I had forgotten about that). Still: your username is your email, which makes it very much public.
AiligtlpkoCMT yes, but you still see this behavior in systems with public usernames where the "it's for security" reasoning does not apply. As such there must be another reason... Maybe it's just because everyone else is doing it.
Même si le système permet de vérifier si le compte existe d'une autre manière, cela ralentirait toujours le renforcement brutal du nombre de ces demandes.
AiliedcccqCMTãoPortela, consider this: If gmail allowed you to figure out if a userid exists without captcha, they'd allow spammers a way to harvest legit email accounts. And you're right, if there are cases where userid's are completely public, then it's likely by convention. Why should your website code not support both occurrences?
@user606723 En attendant, j'ai lu [ExpectoPatronum] (http://security.stackexchange.com/a/17857/2304) et d'autres similaires et cela a beaucoup plus de sens. Je n'achetais tout simplement pas le tout: "après qu'ils connaissent le nom d'utilisateur, ils doivent juste deviner le mot de passe".
AiliezlywbCMT In the case of Google, the captcha is there for signing up (like submitting the form), the validation is done via AJAX. You can see the URL, and the POST parameters, and the headers, so the hidden usernames are not the issue.
@MarkBeadles La possibilité que l'utilisateur saisisse mal le nom d'utilisateur et soumette est extrêmement rare. Divisez-le par un milliard et obtenez la possibilité que le nom d'utilisateur mal saisi corresponde à celui d'un autre utilisateur. Cependant, lorsque la base d'utilisateurs est énorme (comme celle de Google ou de Yahoo), la possibilité que cela se produise est plus élevée. Mais même dans ce cas, lorsque bob1 fait une erreur de frappe sur bob2, sans savoir qu'il est réellement bob1, le site pourrait dire "Mot de passe invalide pour bob2" et l'utilisateur aura le problème.
Certains sites vous diront si l'adresse e-mail que vous avez fournie existe déjà dans leur système lors de l'inscription (vous indiquant parfois la fonction de réinitialisation du mot de passe). Quelqu'un peut-il expliquer en quoi cela ne donne pas à un utilisateur malveillant un autre moyen de découvrir des noms d'utilisateur valides? (Je ne parle pas d'invites JavaScript informatives, etc. uniquement ici)
Juste ajouter plus au feu: Facebook vous dit en fait quand le nom d'utilisateur n'existe pas. :)
Microsoft: "* Ce compte Microsoft n'existe pas. Entrez une autre adresse e-mail ou créez un nouveau compte. *" / "* Ce mot de passe est incorrect. Assurez-vous que vous utilisez le mot de passe de votre compte Microsoft. *"
Onze réponses:
user10211
2012-07-30 13:44:08 UTC
view on stackexchange narkive permalink

Si un utilisateur malveillant commence à attaquer un site Web en devinant des combinaisons nom d'utilisateur / mot de passe courantes comme admin / admin, l'attaquant saurait que le nom d'utilisateur est valide s'il renvoie un message "Password invalid" au lieu de "Username or password invalid" .

Si un attaquant sait que le nom d'utilisateur est valide, il pourrait concentrer ses efforts sur ce compte particulier en utilisant des techniques comme les injections SQL ou le renforcement brutal du mot de passe.

Cela ne suppose-t-il pas que trouver le nom d'utilisateur par d'autres moyens est aussi difficile que de deviner le mot de passe? Comme le souligne @CodesInChaos, si vous pouvez valider le nom d'utilisateur par d'autres moyens, il est vraiment inutile de le masquer dans cette seule interface.
@kojiro Oui, cela suppose. Mais ce n'est pas une mauvaise hypothèse.
AilipjbctqCMT I think it's not uncommon that accounts that can be used to administer the website are not published in any publicly viewable username list.
AilirrjjbqCMT I disagree, for most widely known websites (gmail, facebook, twitter...) the username is very much public.
Ne serait-il pas logique qu'un site Web déclare que chaque identifiant possible est valide et offre également une adresse e-mail de récupération inventée? Cela aiderait-il à contrecarrer les comportements malveillants en faisant perdre du temps aux pirates sur des userids qui en fait n'existent pas et n'ont aucun mot de passe à craquer?
AilinaqahlCMT but then you could just show the usual "username or password wrong" message and call it a day, it's pretty much the same.
@lazfish, non, car tout utilisateur intelligent serait capable de dire que c'est un faux message. Je suis d'accord avec Mahn.
Ce serait effectivement la même chose mais cela fonctionnerait dans des environnements avec une validation sur chaque élément également.
AiliegrddfCMTãoPortela I did not say that it is a valid assumption for all cases, I said that it is not a bad assumption. Of course some sites have very public usernames, and in that case, if you know a valid username, all you need to do is to guess the password, but as a general case for a designer, it is better to assume that the username is not known.
He can just attack the sign up page, silly.
Il suffit de voir cela dans une autre perspective, disons que le pirate informatique ne force que les mots de passe car il y a des gens qui ont des mots de passe assez faibles. Il trouverait un mot de passe valide, le système a par exemple 1000 utilisateurs, il écrit un script simple pour supprimer les noms d'utilisateur du site Web et ensuite il suffit d'essayer tous les noms d'utilisateur, soit 1000 tentatives dans ce cas. Cette méthode est plus rapide car l'attaquant utilise le mot de passe * le plus simple *.
Un utilisateur malveillant peut savoir si le nom d'utilisateur est pris dans le cadre de l'enregistrement. Vous ne permettriez pas à deux utilisateurs de s'inscrire avec le même nom d'utilisateur. Par conséquent, masquer le message d'échec de connexion n'a pas de sens.
@Gajus tous les sites Web ne fournissent pas de formulaires d'inscription.Dans certains sites Web SaaS, l'administrateur doit ajouter des utilisateurs.
ROFLwTIME
2012-07-30 18:12:28 UTC
view on stackexchange narkive permalink

Comme d’autres l’ont mentionné, nous ne voulons pas que vous sachiez si c’était le nom d’utilisateur ou le mot de passe qui était erroné afin que nous ne soyons pas aussi sensibles à la force brute ou attaques de dictionnaire..

Si certains sites Web voulaient que leurs utilisateurs sachent lequel a échoué tout en restant dans le vert du point de vue de la sécurité, ils pourraient mettre en œuvre " honeypot" les noms d'utilisateur (tels que l'administrateur, l'administrateur, etc.) qui alerteraient les administrateurs du site Web que quelqu'un fouine sur leur site Web. Vous pouvez même configurer une logique pour interdire leur adresse IP s'ils tentaient de se connecter avec l'un de ces noms d'utilisateur "honeypot". Je connais une personne qui avait en fait un site Web et a mis dans son code source un commentaire HTML tel que "Depuis que vous oubliez sans cesse Richard: Nom d'utilisateur: fromage Mot de passe: Burger123" près de la boîte de connexion dans le but de surveiller toute adresse IP qui a tenté d'utiliser ce nom d'utilisateur / mot de passe. Ajouter une logique de surveillance comme celle-ci est très amusant lorsque vous développez un site Web.

Bien sûr, la journalisation des tentatives de connexion non valides et l'ajout d'une logique appropriée pour gérer ces adresses IP fonctionnent également. Je sais que certains seraient en désaccord avec moi, mais selon le type de site Web, je ne pense pas que ce soit trop gros pour informer l'utilisateur tant que vous ajoutez des mesures de sécurité supplémentaires pour empêcher différents types d'attaques.

J'adore l'idée du faux nom d'utilisateur / mot de passe codé pour identifier plus rapidement les adresses IP de piratage.
+1 for the mention of honeypot usernames, though you should make absolutely sure legitimate users cannot create accounts with the same name as the honeypots!
Eh; some legitimate users may look at the html code for legitimate reasons (how's the form implemented; or is that an image?); and be like serious; there's a password in the page and just try it out.
Je ne vois pas la valeur des deuxième et troisième paragraphes par rapport à la question posée.
dr jimbob
2012-07-31 00:48:25 UTC
view on stackexchange narkive permalink

Ma mise en œuvre sécurisée préférée est effectuée par une banque que j'utilise. Si je saisis correctement mon nom d'utilisateur, le message "Welcome Jimbob!" puis me demande de répondre aux questions de sécurité (si je ne me suis jamais connecté à partir de ce navigateur sur cet ordinateur), attendez que je réponde correctement aux questions de sécurité, puis me permettra de voir mon image / légende de sécurité et d'entrer mon mot de passe. Si je tape le mauvais nom d'utilisateur, je vois quelque chose comme "Welcome Bessie / Kareem / Randal!" où le nom affiché est très rare - même si vous serez toujours le même nom pour un même nom d'utilisateur (je ne suis généralement pas sûr entre un ou deux noms d'utilisateur; et le mauvais m'appelle systématiquement Frenshelia). Je suppose qu'il est mis en œuvre comme une sorte de hachage non cryptographique appliqué à tout nom d'utilisateur entré qui correspond de manière unique à un nom d'utilisateur sur une longue liste de noms assez rares. Cela permet aux utilisateurs légitimes de savoir s'ils ont tapé le mauvais nom d'utilisateur (comme même si vous avez un nom inhabituel comme Bessie; il est très peu probable que le mauvais nom d'utilisateur que vous avez deviné au hasard renvoie à votre nom inhabituel spécifique), sans le rendre évident pour les personnes qui essaient pour trouver des comptes aléatoires dont le nom d'utilisateur n'existe pas.

En passant: je n'aime pas particulièrement la partie questions de sécurité / image de sécurité, qui semble se rapprocher du théâtre de sécurité. Un attaquant sophistiqué effectuant une attaque de type `` man-in-the-middle '' (MITM) (par exemple, après avoir installé de faux certificats dans votre navigateur Web; et une usurpation DNS / ARP pour pointer yourbank.com vers leur adresse IP) pourrait attendre que vous essayiez de vous connecter dans le site, puis demandez à un script automatisé de vous connecter sur leur ordinateur au site réel, obtenez les questions de sécurité, affichez les questions de sécurité choisies, renvoyez les réponses au site eux-mêmes à partir de leur navigateur, attendez d'obtenir la sécurité image, vous renvoyer l'image de sécurité, puis attendre que vous saisissiez le mot de passe de leur extrémité, auquel cas ils l'utilisent pour se connecter en tant que vous et faire des choses malveillantes. Accorder les questions + l'image rend le processus plus difficile que d'avoir tout le temps du monde pour collecter toutes les images de sécurité pour une variété de noms d'utilisateur attaqués en le transformant en une attaque qui doit être effectuée en temps réel et laisse éventuellement une signature suspecte .

Oui, mais s'ils ne le font pas, comment les pirates sont-ils censés accéder aux autres comptes des gens sans avoir besoin du mot de passe? (Ces questions de sécurité me dérangent aussi, surtout lorsqu'elles sont obligatoires, à partir d'une liste fixe, et y répondre ne se contente pas de recevoir un lien. Une personne qui ne connaissait pas le livre préféré de l'utilisateur en troisième année le sait maintenant, et parce que certains administrateurs sont des idiots, ces informations sont bien plus utiles que le mot de passe parfaitement sécurisé ...)
Parfois, les mots de passe sont hachés sur le fil. Le serveur envoie un sel, vous combinez votre mot de passe avec le sel puis vous le hachez, vous envoyez ensuite votre hachage au serveur. L'attaquant peut accéder à cette session particulière, mais il ne connaîtra pas votre mot de passe pour les sessions futures. S'il y a un schéma plus intelligent, j'aimerais l'entendre.
Dyppl
2012-07-31 00:54:17 UTC
view on stackexchange narkive permalink

D'autres réponses donnent un bon aperçu des raisons de sécurité derrière ce comportement. Bien qu'ils soient corrects, je suis presque sûr qu'au moins certains sites Web ont juste programmé la routine d'autorisation de la façon dont il est impossible de dire ce qui ne va pas - login ou mot de passe.

Exemple query: 

  SELECT COUNT (*) FROM users WHERE login = 'john' AND hash = '2bbfcdf3f09ae8d700402f36913515cd'

Cela renverra 1 en cas de tentative de connexion réussie et 0 s'il n'y a pas d'utilisateur avec ce nom ou cet utilisateur a un mot de passe différent. Il n'y a aucun moyen de savoir quelle partie de la condition a échoué. Donc, quand il s'agit d'afficher un message d'erreur, le programmeur vous dit honnêtement que quelque chose ne va pas et il n'est pas vraiment sûr de ce que c'est exactement.

J'ai personnellement vu des requêtes similaires dans quelques sites Web basés sur PHP, donc je ' Je suis presque sûr qu'une partie de la raison vient de la façon dont le processus d'authentification est vraiment codé.

I have made login prompts that responded with the phrase for this exact reason!
@monoceres Dans ce cas, vous vous trompez probablement. Soit vos mots de passe ne sont pas salés, soit ils sont tous salés avec la même valeur.
And to continue kba's point, using the same salt on all values, sometimes called a pepper is basically equivalent to using no salt at all; as all accounts can be attacked in parallel. Furthermore, you always should be careful to do constant time comparison of strings, which SQL will not do; even if they are hashed (especially if the hashing is being done client-side). Otherwise timing attacks can be used.
Oui, mais cela a été dans les projets scolaires et les projets de loisirs, donc pas besoin de s'inquiéter :)
Pour être clair, je dis que cette pratique existe. Bien sûr, c'est une mauvaise.
@kba Que faire si votre requête est quelque chose comme: "SELECT COUNT (*) FROM users WHERE username = '_USER_' AND hash = HASHFUNC (_PEPPER_ + _PASSWORD_ + salt);". Ne serait-ce pas une requête parfaitement légitime qui ne vous permettrait pas de savoir ce qui ne va pas?
@ZetaTwo: il le ferait, mais cela nécessite que des fonctions de hachage soient construites dans le dialecte SQL particulier
Je pense que cela est venu * après * la réalisation / le consensus de l'erreur de connexion ambiguë. Je ne pense pas que cet œuf soit venu avant ce poulet. Certains développeurs coupent les coins ronds ici parce qu'ils savent qu'ils ne sont pas tenus (et ne devraient pas) dire à l'utilisateur si c'était le courriel ou le mot de passe qui était incorrect.
Charlie Rudenstål
2012-07-31 04:36:44 UTC
view on stackexchange narkive permalink

Il existe cependant une autre technique intéressante qui peut être appliquée pour effectuer une attaque d'énumération d'utilisateurs (et plus). C'est ce qu'on appelle une Timing attack . L'attaquant mesure simplement le temps de réponse pour la demande d'authentification et en quoi il diffère entre une connexion valide et une connexion invalide.

  1. Attaques à distance à l'échelle nanoseconde sur les applications PHP: il est temps de les prendre au sérieux ?
    http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-timing-attacks-on-php-applications-time-to-take-them-serously/

  2. Une leçon sur le chronométrage des attaques
    http://codahale.com/a-lesson-in-timing-attacks/

  3. Comparaison de chaînes à temps constant en PHP pour éviter les attaques de synchronisation
    https://codereview.stackexchange.com/questions/13512/constant-time-string- comparaison-en-php-pour-prévenir-les-attaques-chronométrées

Mon point étant qu'un tel message n'est pas suffisant si vous voulez sécuriser votre application contre ce genre de menace.

Lucas Kauffman
2012-07-30 13:42:53 UTC
view on stackexchange narkive permalink

La raison de sécurité derrière cela est sinon il devient beaucoup plus facile de trouver des noms d'utilisateur valides.

StasM
2012-07-31 04:41:44 UTC
view on stackexchange narkive permalink

En plus de toutes les bonnes réponses déjà données, il existe un principe de sécurité générique qui dit que vous ne devez pas fournir d'informations non sollicitées à des utilisateurs non autorisés. C'est à dire. si vous avez le choix de répondre soit "vos données d'authentification ne sont pas valides", soit d'expliquer quelle partie n'est pas valide - vous devez toujours choisir la première. Certaines attaques cryptographiques très désagréables sont basées sur la plus petite quantité d'informations d'erreur fournies par l'implémentation essayant d'être "utiles" - voir Attaque d'oracle de remplissage. C'est donc une bonne idée de toujours opter pour la moindre information possible divulguée à l'entité non autorisée - c'est-à-dire que si son combo nom d'utilisateur / mot de passe n'est pas bon, vous répondez toujours "nom d'utilisateur / mot de passe pas bon", et ne le divulguez plus Les données. Même si dans un cas spécifique (comme gmail où le nom d'utilisateur est public) ce n'est pas important, c'est une bonne pratique à adopter par défaut.

aayush anand
2012-07-30 19:20:02 UTC
view on stackexchange narkive permalink

Disons que vous entrez un nom d'utilisateur aléatoire et un mot de passe tout aussi aléatoire (notez simplement le mot de passe que vous entrez). Désormais, les mots de passe peuvent être communs aux n utilisateurs. Donc, si le site Web dit que le mot de passe est correct ... alors vous savez ce qui suit ... le chaos parmi les utilisateurs authentiques car obtenir des noms de connexion est assez facile.

Jakub Šturc
2012-07-31 00:02:37 UTC
view on stackexchange narkive permalink

Fournir une réponse ambiguë est utile pour éviter les attaques énumération d'utilisateurs.

Dans certains cas, l'attaquant n'a pas besoin de compromettre le compte utilisateur. Les informations que l'utilisateur a un compte sont suffisantes sans aucune autre action. Par exemple, il s'agit d'informations précieuses pour le commerce que leur client a un compte sur une boutique en ligne concurrentielle.

Niks
2012-07-31 04:31:25 UTC
view on stackexchange narkive permalink

J'apprécie les diverses réponses ci-dessus, car elles le disent le plus, mais parfois les applications ne savent pas non plus ce qui ne va pas. Dans le cas d'une authentification basée sur un jeton spécialement pour implémenter SSO (Single Sign On), par exemple IBM Tivoli Access Manager, votre application reçoit un jeton réussi ou récupère une erreur.

Verena Haunschmid
2012-07-31 00:22:43 UTC
view on stackexchange narkive permalink

si la connexion est une adresse e-mail, il est facile de découvrir qu'une personne est enregistrée sur un site Web - je ne veux peut-être pas cela id :)



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