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, alors il stocke non pas les mots de passe eux-mêmes, mais la sortie d'une 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) inclut quelques fonctionnalités supplémentaires, y compris un sel (pour de très bonnes raisons de sécurité). La vérification d'un mot de passe nécessite alors la connaissance du sel correspondant. Puisque le sel est spécifique à une instance (le point du sel est que les 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 correspond à n'importe quel 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'ai eu trois utilisateurs:

  Nom d'utilisateur Passwordbob foobaralice foobarmaggie foobar  

Lorsque ces mots de passe sont définis, un sel est ajouté et un hachage est généré:

  Nom de l'utilisateur Salt Valeur à hacher Hash resultbob ABCDEF ABCDEFfoobar 778f9aab91717e420e447d7e4cdd84f1alice 123456 123456foobar 17e9191daecc5b8be26779209769b275maggie ZXCVBN2802SEL sont 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 de tables arc-en-ciel sur une liste de mots de passe extraite.  
 Cela rend impossible de déterminer quel compte est connecté sur la base du mot de passe seul, car le sel est l'utilisation n'est pas connue. Cela est dû au fait que le nom d'utilisateur est utilisé comme clé pour la recherche, et sans que cela ne soit fourni au serveur, le mot de passe entré à l'étape 1 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é, ce serait trop lent, car vous utilisez un algorithme lent (voir note de bas de page). 
 
 De plus, 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 à des fins d'illustration uniquement et utilise MD5. N'utilisez jamais MD5 pour hacher les mots de passe - utilisez bcrypt, scrypt ou pbkdf2.  

En gros, vous ne demandez pas "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 la chaîne unique un nom d'utilisateur ou un ID utilisateur car c'est unique.

Sur le plan de la sécurité et de la regarder dans l'ordre normal de connexion / mot de passe : Si vous exigiez que les deux soient uniques, vous ouvririez une attaque contre la base de données, car chaque mot de passe vérifié serait vérifié par rapport à chaque utilisateur de la base de données car vous avez exigé que vos mots de passe soient uniques . Donc, les deux uniques ne fonctionnent pas. Les deux non uniques ne fonctionnent pas car vous ne savez pas à quel compte accède. Donc, cela ne laisse qu'une seule chaîne unique. Si vous créez une seule chaîne de texte unique, autant en faire une donnée publique et vérifier cela en premier (et nous appelons ces données Login / ID / Username).

Imaginons une analogie ...

Je suis un messager envoyé par mon roi pour dé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é une phrase de passe à dire au garde afin que je puisse être laissé entrer dans le château.

J'ai deux options pour faire ceci:

1. Comme vous vous en doutez, la manière conventionnelle de le faire est de monter au château où j'ai été envoyé, puis de leur indiquer la phrase de passe à laisser entrer. C'est d'abord utiliser mes informations publiques (le château, visible par quiconque veut le regarder) pour se connecter avec mes informations privées (la phrase de passe).

2. Mais il existe un moyen inverse pour fais ça. Je peux avoir un klaxon et crier ma phrase secrète dans toute la vallée pour que le public puisse l'écouter. Puisque le château que j'ai l'intention de visiter a entendu ma phrase de passe (avec tous les autres châteaux et les habitants potentiellement néfastes de la vallée), le château que je visite devrait savoir pour m'attendre.

   Je continue alors à cheval vers le bon château et traversez son pont-levis ouvert. Mais ils laisseraient n'importe qui entrer par 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 moi-même cela dans une corne, habitants de la vallée pouvaient se tenir au sommet d'une colline avec leur propre klaxon, criant du charabia à travers la vallée jusqu'à ce qu'ils entendent le bruit sourd de l'ouverture d'un pont-levis; sachant qu'ils ont bien deviné une phrase secrète, ils doivent simplement passer d'un château à l'autre jusqu'à ce qu'ils en trouvent un ouvert.

La première option est la façon dont cela se fait habituellement. Il n'y a aucune raison de changer cette convention. L'alternative est possible, mais en partageant d'abord vos informations privées, vous facilitez beaucoup la tâche de deviner le mot de passe de tout le monde à la fois avant de vous authentifier avec des informations publiques, c'est-à-dire aller à chaque château ou 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 faire simplement correspondre avec l'un des quelques milliers de châteaux ou noms de comptes publics.

Google ne vous demande pas de saisir d'abord votre adresse e-mail pour des raisons de sécurité. Il vous faut entrer votre e-mail / nom d'utilisateur, donc si vous vous connectez à un domaine professionnel ou éducatif qui souhaite avoir sa propre page de destination pour SSO / SAML

Si vous demandez d'abord le mot de passe, vous devez conserver la valeur "secret" dans un certain état pendant que vous attendez le nom d'utilisateur. Avec une application Web, vous devrez généralement effectuer ce stockage d'une manière ou d'une autre pour qu'un nouveau processus puisse lire la valeur, car le nom d'utilisateur entrerait lors d'une deuxième demande. Cela augmente la fenêtre d'opportunité pour que la chaîne de mot de passe soit divulguée, à 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 utilise le hachage salé (ou non) peuvent 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 longtemps possible.

Et c'est une convention. En demandant d'abord le mot de passe, vous finirez par entraîner les utilisateurs à saisir accidentellement leur mot de passe dans les champs de nom d'utilisateur ailleurs, ce qui entraînera probablement une divulgation via les journaux.

Ne faites pas cela. :)

Pour ajouter; le mécanisme d ' 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 - correspond à un ensemble de résultats présélectionné; 1: many - correspond à tous les résultats de la base de données  

Les noms d'utilisateur comme ceux de gmail sont uniques. Ce n'est pas obligatoire pour toutes les applications, mais cela facilite certainement la vie de l'algorithme de vérification par opposition à l'algorithme d'identification.

Considérez le nom d'utilisateur populaire puis l'authentification par mot de passe pour gmail:

1. 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; Aucune correspondance, aucun accès.

2. Entrez le mot de passe.

   gmail correspond simplement au 1 nom d'utilisateur avec le 1 mot de passe stocké dans n'importe quel format; Aucune correspondance, l'authentification a échoué. Oui, accédez à votre messagerie.

À mon humble avis.

De l'autre côté, l'identification (1: plusieurs), le processus de correspondance de gmail serait comme ceci:

1. entrez le mot de passe; et comme @SilverlightFox l'a clairement indiqué, de nombreux comptes peuvent avoir le même mot de passe.

     l'algorithme de correspondance fait correspondre le mot de passe à TOUS les noms d'utilisateur enregistrés dans la base de données gmail.  

   Un ensemble de résultats trop prudent peut contenir 10 noms d'utilisateur.

2. Entrez le nom d'utilisateur;

La question de savoir si les noms d'utilisateurs sont uniques ou peuvent être identiques, décidera de la durée de plus du processus d'authentification et du nombre de correspondances trouvées. Si plusieurs correspondances, 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 de la configuration de l'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.

Au cas où de la plupart de ces situations, l'identifiant d'utilisateur entré par personne n'est qu'une entrée considérée. Parallèlement à cela, de nombreuses autres informations (comme l'adresse IP à partir de laquelle vous accédez, l'appareil que l'utilisateur utilise - une signature d'appareil est générée et transmise avec l'identifiant de l'utilisateur) sont transmises à un moteur de détermination des risques (dans la plupart des banques). mais ne peut pas toujours être utilisé) qui peut fournir un processus de connexion suggéré. En plus de cela, le système vérifie la politique de connexion associée à l'utilisateur (c'est-à-dire s'il a activé le multi-facteur 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, vous pouvez être invité à opter pour un processus d'authentification multiple (par exemple, OTP basé sur un téléphone, etc.).