"Nom d'utilisateur et / ou mot de passe non valide" - Pourquoi les sites Web affichent-ils ce type de message au lieu d'indiquer à l'utilisateur lequel s'est trompé?
Supposons qu'un utilisateur se connecte à un site typique, saisisse son nom d'utilisateur et son mot de passe, et qu'il tape mal l'une de ses entrées. J'ai remarqué que la plupart, sinon la totalité, des sites affichent le même message (quelque chose du genre "Nom d'utilisateur ou mot de passe invalide") malgré qu'une seule entrée soit erronée.
Pour moi, il semble assez facile d'avertir l'utilisateur de la saisie incorrecte, ce qui m'a amené à me demander pourquoi les sites ne le font pas. Alors, y a-t-il une raison de sécurité ou est-ce simplement quelque chose qui est devenu la norme?
Si un utilisateur malveillant commence à attaquer un site Web en devinant les combinaisons username/mot de passe courantes comme admin/admin, l'attaquant saurait que le nom d'utilisateur est valide s'il renvoie un message "Mot de passe invalide" au lieu de "Nom d'utilisateur ou mot de passe invalide".
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.
Comme d'autres l'ont mentionné, nous ne voulons pas que vous sachiez si c'est le nom d'utilisateur ou le mot de passe qui était faux afin que nous ne soyons pas aussi sensibles à force brute ou dictionnaire attaques ..
Si certains sites Web voulaient faire savoir à leurs utilisateurs lequel a échoué tout en étant dans le domaine de la sécurité verte, ils pourraient implémenter des noms d'utilisateur " honeypot " (tels que Administrateur, administrateur, etc.) qui alerteraient le site Web admins que quelqu'un fouine autour de leur site Web. Vous pourriez même configurer une logique pour interdire leur adresse IP s'ils tentaient de se connecter avec l'un de ces noms d'utilisateur "pot de miel". Je connais une personne qui avait en fait un site Web et a mis dans son code source un commentaire HTML tel que "puisque vous oubliez toujours Richard: nom d'utilisateur: fromage mot de passe: Burger123" près de la boîte de connexion avec l'intention de surveiller toute adresse IP qui a tenté d'utiliser ce nom d'utilisateur/mot de passe. L'ajout d'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 de la 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 important de le faire savoir à l'utilisateur tant que vous ajoutez des mesures de sécurité supplémentaires pour empêcher différents types d'attaques.
Mon implémentation sécurisée préférée est effectuée par une banque que j'utilise. Si je saisis correctement mon nom d'utilisateur, il dit "Bienvenue Jimbob!" puis m'invite à répondre aux questions de sécurité (si je ne me suis jamais connecté depuis ce navigateur sur cet ordinateur), attendez que je réponde correctement aux questions de sécurité, puis me laissera voir mon image/légende de sécurité et saisira mon mot de passe. Si je tape le mauvais nom d'utilisateur, je verrai quelque chose comme "Bienvenue Bessie/Kareem/Randal!" où le nom affiché est très rare - bien que vous ayez 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 constamment Frenshelia). Je suppose qu'il est implémenté comme une sorte de hachage non cryptographique appliqué à tout nom d'utilisateur entré qui mappe 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 mappe à 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 à la limite du théâtre de la sécurité. Un attaquant sophistiqué faisant une attaque man-in-the-middle (MITM) (par exemple, après avoir installé de faux certificats dans votre navigateur Web et usurpation DNS/ARP pour pointer yourbank.com vers leur adresse IP) pourrait attendre que vous essayiez de vous connecter sur le site, puis connectez un script automatisé sur votre ordinateur au site réel, récupérez les questions de sécurité, affichez les questions de sécurité choisies, renvoyez les réponses au site elles-mêmes depuis leur navigateur, attendez d'obtenir la sécurité image, vous restituez l'image de sécurité, puis attendez que vous saisissiez le mot de passe de leur côté, auquel cas ils utilisent le mot de passe pour se connecter en tant que vous et faire des choses malveillantes. Accordé aux questions + 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'utilisateurs attaqués en le transformant en une attaque qui doit être effectuée en temps réel et laisse éventuellement une signature suspecte .
D'autres réponses fournissent un bon aperçu des raisons de sécurité derrière ce comportement. Bien qu'ils soient corrects, je suis quasiment sûr qu'au moins certains sites Web ont juste la routine d'autorisation programmée de la façon dont il est impossible de dire ce qui n'allait pas - connexion ou mot de passe.
Exemple de requête:
SELECT COUNT(*) FROM users WHERE login = 'john' AND hash = '2bbfcdf3f09ae8d700402f36913515cd'
Cela renverra 1 si la tentative de connexion réussit et s'il n'y a aucun utilisateur avec un tel 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 qu'il n'est pas vraiment sûr de ce que c'est exactement.
Personnellement, j'ai vu des requêtes similaires dans quelques sites Web basés sur PHP, donc je suis presque sûr qu'une partie de la raison vient de la façon dont le processus d'authentification est vraiment codé.
Il existe cependant une autre technique intéressante qui peut être appliquée pour effectuer un user enumeration attack (et plus). Cela s'appelle un Timing attack. L'attaquant mesure simplement le temps de réponse à la demande d'authentification et la différence entre une connexion valide et une connexion non valide.
Attaques à distance à l'échelle nanoseconde sur PHP Applications: 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-serfully/Une leçon sur le timing des attaques
http://codahale.com/a-lesson-in-timing-attacks/Comparaison de chaînes de temps constant en PHP pour empêcher les attaques de synchronisation
https://codereview.stackexchange.com/questions/13512/constant-time-string-comparision-in-php-to-prevent-timing-attacks
Mon point étant qu'un tel message n'est pas suffisant si vous voulez sécuriser votre application contre ce type de menace.
La raison de la sécurité est que sinon il devient beaucoup plus facile de trouver des noms d'utilisateur valides.
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 "vos données d'authentification ne sont pas valides" ou 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 "utile" - voir Padding Oracle attack . C'est donc une bonne idée de toujours opter pour la plus petite information possible divulguée à l'entité non autorisée - c'est-à-dire, 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 divulguez plus jamais 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.
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 ensuite.
Fournir une réponse ambiguë est utile pour empêcher énumération des utilisateurs attaque.
Dans certains cas, l'attaquant n'a pas besoin de compromettre le compte utilisateur. Les informations que l'utilisateur possède sont suffisantes sans autre action. Par exemple, ce sont des informations précieuses pour le commerce que leur client possède sur une boutique en ligne compétitive.
J'apprécie les diverses réponses ci-dessus car elles en disent le plus, mais parfois, les applications ne savent pas non plus ce qui est un mauvais nom d'utilisateur ou mot de passe. Dans le cas d'une authentification basée sur des jetons spécialement pour implémenter SSO (Single Sign On), par ex. IBM Tivoli Access Manager votre application reçoit un jeton réussi ou récupère une erreur.
si la connexion est une adresse e-mail, il est facile de savoir qu'une personne est inscrite sur un site Web - je ne le veux peut-être pas >> Parfois, les gens utilisent le mot de passe du compte de messagerie pour les sites Web qu'ils enregistrent lorsqu'ils utilisent l'identifiant de messagerie comme identifiant de connexion :)