Message d'erreur générique pour un mot de passe ou un nom d'utilisateur incorrect - est-ce vraiment utile?
Il est très courant (et je dirais que c'est une sorte de sécurité de base) de ne pas afficher sur la page de connexion si le nom d'utilisateur ou le mot de passe était incorrect lorsqu'un utilisateur essaie de se connecter. On devrait plutôt afficher un message générique, comme " Le mot de passe ou le nom d'utilisateur sont incorrects ".
La raison n'est pas de montrer aux attaquants potentiels quels noms d'utilisateur sont déjà utilisés, il sera donc plus difficile de pirater un compte existant.
Cela me semblait raisonnable, mais quelque chose de différent m'est venu à l'esprit.
Lorsque vous enregistrez votre compte, vous saisissez votre nom d'utilisateur. Et quand il est déjà pris, vous obtenez un message d'erreur - qui n'est pas générique!
Donc, fondamentalement, un attaquant pourrait simplement récupérer les noms d'utilisateurs "corrects" de la page d'enregistrement, ou je me trompe?
Quel est donc l'intérêt des messages génériques? Les messages non génériques conduiraient à une bien meilleure UX.
Non, vous avez raison de dire qu'à un moment donné au cours des efforts visant à empêcher les attaquants de déterminer des identités d'utilisateurs valides, vous devrez soit leur mentir, soit fournir des messages d'erreur exceptionnellement vagues.
Votre application pourrait indiquer à un utilisateur que "le nom d'utilisateur demandé n'est pas disponible" et ne pas préciser s'il était déjà utilisé ou s'il ne répondait tout simplement pas à vos autres exigences de nom d'utilisateur (longueur, utilisation des caractères, mots réservés, etc.). Bien sûr, si ces détails sont publics, un attaquant pourrait comprendre que leur supposition a échoué en raison de l'utilisation du compte et non en raison d'un format non valide.
Ensuite, vous avez également votre système de réinitialisation de mot de passe. Acceptez-vous un nom d'utilisateur/une adresse e-mail et dites-vous qu'un message a été envoyé même si ce compte n'était pas dans votre base de données? Qu'en est-il du verrouillage du compte (si vous l'utilisez)? Dites-vous simplement à l'utilisateur que ses informations d'identification n'étaient pas valides même si elles ne l'étaient pas, mais que leur compte a été verrouillé, en espérant qu'il contacte le service client qui peut identifier le problème?
Il est avantageux d'augmenter la difficulté pour les attaquants à rassembler des noms d'utilisateur valides, mais cela se traduit généralement par une frustration pour les utilisateurs. La plupart des sites à faible sécurité que j'ai vus utilisent des messages distincts identifiant si le nom d'utilisateur ou le mot de passe est faux simplement parce qu'ils préfèrent pécher par excès de satisfaction. Vous devrez déterminer si vos exigences de sécurité imposent de les hiérarchiser par rapport à l'expérience utilisateur.
Vous faites l'hypothèse que le système sait réellement quel champ a été entré incorrectement. Il y a plusieurs raisons pour lesquelles ce n'est pas nécessairement vrai.
Une possibilité est que c'est un effet secondaire de la mise en œuvre. Une méthode simpliste de recherche de connexions dans une base de données pourrait ressembler à quelque chose (en utilisant :n pour les paramètres fournis par l'utilisateur):
SELECT 1
FROM users
WHERE username=:1 AND
password=HASHING_FUNCTION(CONCAT(:2, salt))
Si vous obtenez un résultat vide, vous savez que la connexion doit échouer, mais vous ne savez pas pourquoi, sauf si vous faites quelque chose de plus compliqué ou faites une autre requête. Ainsi, il peut parfois s'agir simplement de paresse ou d'un désir d'aller doucement sur la base de données, plutôt que d'une décision de sécurité consciente.
Mais même si l'implémentation peut faire la distinction entre un utilisateur inexistant et des informations d'identification incorrectes, vous avez toujours la situation où un utilisateur saisit correctement son mot de passe, mais le mauvais nom d'utilisateur, et qui se trouve être un utilisateur qui existe (avec un mot de passe différent). Ensuite, si l'utilisateur recevait un message disant que son mot de passe était incorrect, ce serait faux. Donc, à moins que le nom d'utilisateur spécifié n'existe pas, le système ne peut pas savoir réellement si c'est le nom d'utilisateur ou le mot de passe qui était faux.
En général, il est plus difficile de forcer brutalement une page d'inscription que de forcer brutalement une page de connexion, nous bénéficions donc de ce coût supplémentaire. Mais, dans le concept, vous avez raison. Il existe d'autres façons d'énumérer les noms d'utilisateur que les messages de page de connexion.
Il est simplement "bonne pratique" (TM) de garder les messages d'échec génériques afin de rendre plus difficile pour les attaquants de glaner les bons comptes des mauvais. À l'aide d'un outil de force brute, il est trivial d'essayer des noms aléatoires, puis lorsque le message d'erreur change, pour commencer à forcer brutalement ce nom d'utilisateur.
Mais, comme toujours, vous devez équilibrer l'utilisabilité avec la réduction des menaces.
Tous les systèmes n'ont pas d'enregistrement de compte. Par exemple, la connexion de votre système d'exploitation ne fonctionne pas. Les sites Web cessent de temps à autre d'accepter de nouveaux membres.
C'est une question de séparation des préoccupations: la boîte de dialogue de connexion doit-elle interroger la configuration du système et personnaliser son comportement selon que le système est configuré pour accepter ou non des applications pour de nouveaux comptes? Ensuite, la boîte de dialogue de connexion est couplée à des informations qui ne sont pas vraiment pertinentes pour son travail.
Il semble plus facile de simplement implémenter le vague message d'erreur dans tous les cas (en supposant que le logiciel d'interface utilisateur sait même si c'est le mot de passe qui est mauvais ou le compte inexistant: que se passe-t-il s'il obtient une erreur d'authentification générique d'une API de niveau inférieur?)
Et aussi: la nouvelle interface utilisateur de l'application utilisateur peut implémenter un faux délai long comme "recherche de base d'utilisateurs ... [10 secondes] ... oups, le nom d'utilisateur est déjà pris!" Si cela est mis en œuvre, cela signifie que le fait de sonder l'espace des ID utilisateur via ce mécanisme est fortement limité en débit. Étant donné que la demande d'un nouveau compte est une opération rare et ponctuelle, les utilisateurs subiront le retard, alors qu'ils s'aggraveraient d'un délai de dix secondes dans la boîte de dialogue de connexion régulière.
Cela dépend du nom d'utilisateur. Il existe trois approches principales pour les noms d'utilisateur:
- Nom sélectionné par l'utilisateur
- Adresse électronique
- Nom d'utilisateur attribué - généralement une chaîne de chiffres
Vous avez raison de dire que pour les noms sélectionnés par les utilisateurs, un attaquant peut utiliser le processus d'enregistrement pour déduire les noms utilisés, il y a donc un avantage limité à la connexion renvoyant un message générique.
Cependant, pour les deux autres cas, il est beaucoup plus important que l'écran de connexion renvoie un message d'erreur générique. Considérons un site de recrutement, il pourrait être gênant pour [email protected] de faire découvrir à son patron qu'il existe un compte sur un site de recrutement. Et les noms d'utilisateur attribués sont les plus couramment utilisés sur les sites à haute sécurité comme les services bancaires en ligne.
Oui tu as raison. N'importe où sur votre site où il peut être confirmé qu'un nom d'utilisateur existe ou non peut conduire à énumération du nom d'utilisateur .
Cependant, ce problème peut être résol s'il est important pour votre système. Dans certains systèmes, l'énumération des noms d'utilisateur ne peut pas être évitée car elle est inhérente à la nature de l'application. Un exemple est un service de messagerie Web - ici, les adresses e-mail sont considérées comme potentiellement publiques. Empêcher les utilisateurs de connaître d'autres noms d'utilisateur est difficile sans obliger les utilisateurs à se connecter avec un identifiant différent de leur adresse e-mail hébergée et peut entraîner de la confusion et des difficultés à récupérer les informations d'identification perdues.
Cependant, avec la plupart des autres systèmes, cela peut être résolu en ayant l'adresse e-mail de l'utilisateur comme nom d'utilisateur de connexion. Vous résoudriez le problème en ayant le mot de passe oublié et le formulaire d'inscription aussi efficacement sur la même page. Pour vous inscrire, ce serait un formulaire en plusieurs étapes et la première étape demande simplement le nom d'utilisateur (e-mail) que l'utilisateur souhaite utiliser avec votre système. Pour la récupération du compte, ce serait la même forme, mais le titre dirait quelque chose comme Please enter your email address to generate a password recovery email.
Dans les deux cas, le formulaire enverra un e-mail à l'utilisateur. S'ils sont déjà inscrits, le contenu de cet e-mail contient un lien de réinitialisation de mot de passe. S'ils ne sont pas inscrits, le contenu de cet e-mail contient un lien vers la prochaine étape du processus d'inscription. Cela empêchera les noms d'utilisateur sur votre système d'être énumérés afin qu'un attaquant ne sache pas quels comptes cibler.
Bien sûr, cela implique que vous êtes prêt à autoriser la réinitialisation des mots de passe par courrier électronique, ce qui peut être inacceptable pour certaines applications telles que les applications bancaires. Cependant, comme ces types de comptes comportent généralement des contrôles de sécurité supplémentaires, ils ont généralement des noms d'utilisateur attribués à la banque plutôt que de permettre aux gens de choisir les leurs.
L'argument commun pour des messages vagues semble être d'empêcher les attaquants de deviner des noms d'utilisateur valides. Il existe en fait une solution simple qui n'affecte pas gravement les utilisateurs légitimes et qui devrait de toute façon être en place: limiter le nombre maximal de tentatives infructueuses dans une période de temps.
En restreignant les tentatives, vous empêchez toutes les attaques par force brute. Supposons que vous n'autorisez que 5 tentatives par 15 minutes (ce qui est courant sur les forums), ce qui rend une attaque par devination de nom d'utilisateur presque inutile. Il empêche également le forçage brutal des mots de passe (aussi lent que cela serait inutile sur un site distant de toute façon).
Bien sûr, un attaquant pourrait déjà avoir une base de données de noms d'utilisateurs, et souhaite simplement vérifier s'ils existent sur votre site. Et vous devrez considérer les implications de sécurité de cela, mais généralement ils ont déjà le mot de passe (ce qui rend cette discussion théorique) ou ils ne le feront pas (les tentatives restreintes empêchent de toute façon de deviner).
Pour éviter l'énumération du nom d'utilisateur sur la page d'enregistrement de l'utilisateur, une application peut attribuer automatiquement le nom d'utilisateur en fonction de l'adresse e-mail de l'utilisateur, plutôt que de demander à l'utilisateur d'en choisir un.
De cette façon, il est possible d'empêcher l'énumération de nom d'utilisateur ou la page d'inscription.
En outre, nous devons prendre en compte la fonctionnalité de mot de passe oublié, parfois cela devrait également révéler des détails d'utilisateur valides.
Un site Web intelligent aurait un captcha sur sa page d'inscription pour empêcher ce genre de chose.
Mais vous savez comment sont 99% des sites Web. Ils ruineront leur UX avec un message d'erreur générique, même si cela ne leur donne aucune sécurité supplémentaire. Personnellement, je ne me soucie pas des messages d'erreur génériques car il existe de nombreuses autres restrictions en place pour mes connexions (captchas, tentatives de connexion limitées), et les connexions sont comme la raison n ° 1 pour laquelle les gens abandonneront un site Web.
Si vous choisissez d'afficher un message d'erreur générique, alors bon Dieu, allez-y jusqu'au bout. Assurez-vous qu'il n'y a aucune extrémité libre n'importe où. Vous pouvez renforcer un mur avec de l'acier de 10 pouces d'épaisseur, mais cela n'aidera pas s'il y a une porte déverrouillée.
J'essaie de mettre mon chapeau d'attaquant et je vois 2 cas:
Votre site dispose d'une page d'inscription (telle que gmail ou stackoverflow). Je pourrais utiliser la page d'inscription pour comprendre le nom d'utilisateur d'un utilisateur existant par force brute. Ou je pourrais simplement créer un nouvel utilisateur. Mon nouvel utilisateur gmail ou stackoverflow aura probablement les mêmes droits que celui que j'aurais forcé brutalement.
Votre site n'a pas de page d'inscription. Votre point est nul.