Sur les formulaires de connexion en deux étapes, pourquoi est-ce le nom de connexion et non le mot de passe qui est demandé en premier?
Il existe plusieurs formulaires de connexion (par exemple, Google) sur Internet où vous entrez d'abord votre nom de connexion, puis, une fois celui-ci soumis, vous pouvez entrer votre mot de passe.
Un des avantages de ceci est, je suppose, que le serveur peut extraire une image seulement il le sait et l'afficher à l'utilisateur pour aider à déjouer les schémas de phishing simples.
Ma question est pourquoi personne ne fait l'inverse - demandez d'abord un mot de passe puis le nom de connexion.
Je peux voir la réponse évidente (que le mot de passe n'est peut-être pas unique et que le serveur ne saurait donc pas quelles images anti-hameçonnage afficher), mais cela ne me convainc pas. Désactiver immédiatement les comptes qui partagent des mots de passe ou au moins forcer les utilisateurs à changer leurs mots de passe en une chaîne unique la prochaine fois qu'ils se connectent pourrait être un moyen de contourner cela et, en passant, cela résoudrait le phénomène de mot de passe "123456".
Un autre problème que je peux voir est que dans un scénario de phishing où un utilisateur saisit correctement son mot de passe et remarque ensuite que les mauvaises images lui sont affichées, il a déjà renoncé à son mot de passe et tout ce qui reste à faire pour le phishing est d'identifier qui ce mot de passe appartient.
Ce que je voudrais savoir, c'est si la séquence de connexion puis de mot de passe est principalement due à des considérations de convention ou d'interface utilisateur ou s'il y a d'autres problèmes de sécurité avec l'inversion de la séquence pour demander le mot de passe en premier (en plus des deux que j'ai mentionnés ).
Un mot de passe unique n'est pas nécessairement vérifiable par lui-même. En particulier, si le serveur fait les choses correctement, il ne stocke pas les mots de passe eux-mêmes, mais la sortie d'un fonction de hachage de mot de passe calculée sur le mot de passe. Une fonction de hachage de mot de passe (par opposition à une simple fonction de hachage) comprend des fonctionnalités supplémentaires, notamment un sel (pour de très bonnes raisons liées à la sécurité). La vérification d'un mot de passe nécessite alors la connaissance du sel correspondant. Étant donné que le sel est spécifique à l'instance (l'intérêt du sel est que des utilisateurs distincts ont leurs propres sels), l'identité de l'utilisateur est requise (l'identité de l'utilisateur est utilisée comme clé d'indexation pour le sel).
D'une part, le serveur ne saurait pas si le mot de passe seul correspondait à un compte.
Dans un système sécurisé, les mots de passe sont salés puis hachés.
Dans une démo simpliste, supposons que j'avais trois utilisateurs:
Username Password
bob foobar
alice foobar
maggie foobar
Lorsque ces mots de passe sont définis, un sel est ajouté et un hachage est généré:
Username Salt Value to hash Hash result
bob ABCDEF ABCDEFfoobar 778f9aab91717e420e447d7e4cdd84f1
alice 123456 123456foobar 17e9191daecc5b8be26779209769b275
maggie ZXCVBN ZXCVBNfoobar 527cb07b112559cf9c1aff19d28074fa
Comme vous pouvez le voir, le but du sel est que deux mots de passe ne sont pas stockés de la même manière, même si le mot de passe peut correspondre. Il s'agit d'une étape de sécurité importante à prendre pour empêcher l'utilisation des tables Rainbow sur une liste de mots de passe extraite.
Cela rend impossible de déterminer quel compte est connecté sur la base du seul mot de passe, car le sel à utiliser n'est pas connu. En effet, le nom d'utilisateur est utilisé comme clé pour la recherche et sans qu'il soit fourni au serveur, le mot de passe entré à la première étape ne peut pas être mis en correspondance sans essayer chaque hachage dans la table utilisateur jusqu'à ce qu'une correspondance soit trouvée. Sur un système correctement configuré, cela serait trop lent, car vous utilisez un algorithme lent (voir note de bas de page).
En outre, ce serait une fuite massive d'informations de sécurité si le système vous disait que votre mot de passe était utilisé par un autre.
L'exemple ci-dessus est uniquement à des fins d'illustration et utilise MD5. N'utilisez jamais MD5 pour hacher des mots de passe - utilisez bcrypt, scrypt ou pbkdf2.
Ne demandez-vous pas essentiellement "Y a-t-il une raison pour laquelle nous n'avons pas de mots de passe publics et de noms d'utilisateur privés?"
Ce ne sont que des chaînes de texte. Votre idée d'appliquer des mots de passe uniques signifie simplement que les noms d'utilisateur sont uniques. L'étiquette que vous appliquez à une zone de texte n'a pas d'importance. Nous appelons la chaîne privée un mot de passe et l'unique un nom d'utilisateur ou un ID utilisateur car c'est unique.
En termes de sécurité et en les regardant dans l'ordre normal de connexion/mot de passe: si vous vouliez que both soit unique, vous ouvririez une attaque sur la base de données, car chaque mot de passe vérifié serait vérifié par rapport à chaque utilisateur dans la base de données parce que vous avez exigé que vos mots de passe soient uniques. Donc, les deux uniques ne fonctionnent pas. Les deux éléments non uniques ne fonctionnent pas, car vous ne savez pas à quel compte vous accédez. Cela ne laisse donc qu'une seule chaîne unique. Si vous créez une seule chaîne de texte unique, cela pourrait tout aussi bien en faire une donnée publique et la vérifier en premier (et nous appelons ces données Login/ID/Username).
Imaginons une analogie ...
Je suis un messager envoyé par mon roi pour livrer un message à un certain château de la vallée des châteaux. Je sais à quoi ressemble le château où je veux aller et on m'a donné un mot de passe pour le dire au gardien afin que je puisse entrer dans le château.
J'ai deux options sur la façon de procéder:
Comme vous vous en doutez sans doute, la manière conventionnelle de le faire est de monter au château où j'ai été envoyé, puis de leur dire la phrase secrète à laisser entrer. C'est d'abord en utilisant mes informations publiques (le château, visible par tous ceux qui veulent pour le regarder) pour me connecter avec mes informations privées (la phrase secrète).
Mais il existe une manière inverse de procéder. Je peux obtenir un klaxon et crier ma phrase secrète à travers toute la vallée pour que le public l'écoute. Depuis que le château que j'ai l'intention de visiter a entendu ma phrase secrète (avec tous les autres châteaux et les résidents potentiellement néfastes de la vallée), le château que je visite devrait savoir m'attendre.
Je continue ensuite à cheval jusqu'au château approprié et traverse son pont-levis ouvert. Mais ils laisseraient entrer n'importe qui à travers ce pont-levis ouvert! Maintenant que mes informations privées ont été partagées avec le monde, n'importe qui peut monter entre les châteaux et entrer dans celui avec la porte ouverte.
Si je ne suis pas ici pour crier cela moi-même dans un cor, les habitants de la vallée pourraient se tenir au sommet d'une colline avec leur propre cor, criant du charabia à travers la vallée jusqu'à ce qu'ils entendent le bruit sourd d'une ouverture de pont-levis; sachant qu'ils ont deviné une phrase de passe correctement, ils doivent simplement rouler entre les châteaux jusqu'à ce qu'ils en trouvent une qui soit ouverte.
La première option est de savoir comment cela se fait habituellement. Il n'y a aucune raison de modifier cette convention. L'alternative est possible, mais en partageant d'abord vos informations privées, vous faciliterez beaucoup la devinette du mot de passe de tout le monde à la fois avant de vous authentifier avec des informations publiques, c'est-à-dire de monter dans chaque château ou d'essayer tout le public noms de compte. Avec des milliers de châteaux dans cette vallée ou des comptes sur un site Web, il est fort probable que quelqu'un devine un mot de passe facile, puis il est beaucoup plus facile de le mettre en correspondance avec l'un des quelques milliers de châteaux ou noms de compte public.
Google ne vous demande pas d'entrer votre e-mail en premier pour des raisons de sécurité. Il vous fait entrer votre adresse e-mail/nom d'utilisateur, donc si vous vous connectez à un domaine professionnel ou éducatif qui veut avoir sa propre page de destination pour SSO/SAML
Si vous demandez d'abord le mot de passe, vous devez conserver la valeur "secrète" dans un certain état pendant que vous attendez le nom d'utilisateur. Avec une application Web, vous devez généralement effectuer ce stockage d'une manière ou d'une autre afin qu'un nouveau processus puisse lire la valeur, car le nom d'utilisateur apparaîtra sur une deuxième demande. Cela augmente la fenêtre d'opportunité pour la chaîne de mot de passe à divulguer, à la fois en termes de temps et en termes de moyens d'accéder aux données.
En demandant d'abord le nom d'utilisateur, la vérification du mot de passe qui utilise (ou non) le hachage salé peut déjà avoir accès à tout ce qui est nécessaire pour vérifier le mot de passe immédiatement, et le système n'a besoin que du mot de passe lui-même disponible pendant un minimum de temps. Il est généralement préférable de disposer de données sensibles le moins de temps possible.
Et c'est la convention. En demandant d'abord le mot de passe, vous finirez par former les utilisateurs à taper accidentellement leur mot de passe dans les champs de nom d'utilisateur ailleurs, ce qui entraînera probablement une divulgation via les journaux.
Ne fais pas ça. :)
Pour ajouter; le mécanisme de identification vs authentification/vérification est décidé lors du développement de l'application. L'identification est 1: plusieurs, la vérification/authentification est 1: 1
1:1 - match against one pre-selected result set;
1:many - match against all results in the DB
Les noms d'utilisateur comme gmail sont uniques. Ce n'est pas obligatoire pour toutes les applications, mais cela rend la vie de l'algorithme de vérification plus simple que l'algorithme d'identification.
Considérez le nom d'utilisateur puis l'authentification par mot de passe pour gmail:
entrez le nom d'utilisateur;
gmail correspond au nom d'utilisateur unique avec tous les autres noms d'utilisateur uniques; Oui, entrez le mot de passe; Pas de match, pas d'accès.
Entrer le mot de passe.
gmail fait correspondre le 1 nom d'utilisateur au 1 mot de passe stocké dans n'importe quel format; Aucune correspondance, l'authentification a échoué. Oui, correspond, accédez à votre courrier.
IMHO assez simple.
En prenant l'autre côté, l'identification (1: plusieurs), le processus de correspondance de gmail serait comme ceci:
entrer le mot de passe; et comme @SilverlightFox l'a clairement indiqué, de nombreux comptes peuvent avoir le même mot de passe.
matching algorithm matches password to ALL usernames registered in gmail database.Un jeu de résultats trop conservateur peut contenir 10 noms d'utilisateur.
- Saisissez votre nom d'utilisateur;
Si les noms d'utilisateur sont uniques ou peuvent être identiques, décidera du temps de plus de temps pendant lequel le processus d'authentification s'exécutera et du nombre de correspondances trouvées. Si plus d'une correspondance, nous devrons implémenter l'authentification de connexion en 3 étapes.
L'authentification en deux étapes facilite la vie du développeur et de l'algorithme.
Dans le cas de Google et de la plupart des configurations d'authentification fractionnée, le système utilise essentiellement l'ID utilisateur pour identifier le risque associé et déterminer le processus de connexion approprié qu'il doit exécuter pour l'utilisateur.
Dans le cas de la plupart de ces situations, l'ID utilisateur entré par personne n'est qu'une entrée prise en compte. Parallèlement à cela, de nombreuses autres informations (comme l'adresse IP à partir de laquelle vous accédez, le périphérique que l'utilisateur utilise - une signature de périphérique est générée et transmise avec l'ID utilisateur) sont transmises à un moteur de détermination des risques (dans la plupart des banques mais ne sont pas toujours utilisés), ce qui peut suggérer un processus de connexion. En plus de ce système, il vérifie la politique de connexion associée à l'utilisateur (c'est-à-dire s'il a activé le facteur multiple par exemple). Sur la base de la détermination finale, la plupart du temps, vous pouvez simplement obtenir un écran de mot de passe simple, mais dans certains cas, il peut vous être demandé de passer par un processus d'authentification multiple (par exemple, OTP basé sur téléphone, etc.).