Il y a déjà de bonnes réponses ici, mais le concept simple et de base manque toujours:

L'identification et l'authentification ne sont pas la même chose.

En termes simples, il s'agit de deux exigences distinctes et ne doivent pas être confondues.
Un nom d'utilisateur fournit une identification et un mot de passe vous permet de vérifier cette identité revendiquée (c'est-à-dire l'authentification) .

Voir aussi Différence entre authentification et identification [Crypto and Security perspective]

L'utilisateur et l'administrateur bénéficient tous deux d'un nom d'utilisateur, généralement unique, qui n'est pas un secret, qu'ils peuvent librement utiliser pour se référer au compte. Si le nom d'utilisateur n'est pas unique, il peut être associé à une adresse e-mail ou à un autre identifiant de contact unique. De cette façon, un utilisateur peut réinitialiser son mot de passe et en obtenir un nouveau, ou changer son mot de passe sans changer de compte.

En outre, comme l'ont noté d'autres personnes, exiger simplement un mot de passe unique est également problématique lorsqu'il s'agit du seul identifiant et il y a une collision.

Le but du nom d'utilisateur est d'identifier l'utilisateur. Si vous ne demandez qu'un mot de passe, plusieurs personnes auront (malheureusement) le mot de passe 123456 ou le mot de passe. Comment identifiez-vous maintenant, quel utilisateur avec ce mot de passe tente de se connecter? C'est pourquoi il existe également un nom d'utilisateur.

Et comme le mot de passe ne doit pas être enregistré en texte brut, vous ne devez pas vérifier que le mot de passe est unique.

L'autre point que vous manquez dans le cas 2: j'ai juste besoin de trouver un mot de passe que quelqu'un a utilisé, et non qui l'a réellement utilisé. Donc, si une personne utilise le mot de passe 123456, je n'ai qu'à le savoir et je peux me connecter. S'il y a aussi un nom d'utilisateur, le mot de passe seul ne permet pas de se connecter avec succès.

Vos chances de trouver un mot de passe sont définitivement fausses.

Exemple:

Vous avez 8 utilisateurs & chaque mot de passe est de 64 bits (standard 8 caractères, non salés en aucune façon).

Pour cas deux:

Un attaquant devra exécuter son algorithme de rupture du mot de passe une seule fois pour obtenir les 8 utilisateurs (travail total au pire = 64 bits, 32 bits en moyenne)

Pour le cas un:

Pour casser tous les mots de passe, un attaquant devra exécuter son algorithme 8 fois (une fois pour chaque utilisateur), ce qui est évidemment plus de travail (par exemple, total fonctionne au pire = 67 bits, 33-34 bits en moyenne)

La probabilité de rupture du mot de passe doit être:

Pour le cas un:

  1 / (2 ^ bitsUsedForPassword)  

Pour le cas deux:

  numberOfUsers / (2 ^ bitsUsedForPassword)  

Par conséquent, le deuxième cas a plus de chances d'obtenir le mot de passe s'il y a plus d'un utilisateur.

Avoir un nom d'utilisateur et un mot de passe est certainement plus sûr. Supposons que votre site compte un million d'utilisateurs:

• Si vous n'utilisez qu'un mot de passe, un attaquant n'a qu'à deviner l'un des millions de mots de passe valides pour pénétrer dans le site.

• Si vous utilisez un nom d'utilisateur et un mot de passe, l'attaquant doit trouver un nom d'utilisateur valide et le mot de passe correct pour ce nom d'utilisateur (pas n'importe lequel mot de passe sur le site). C'est beaucoup plus difficile pour l'attaquant.

Exiger à la fois un nom d'utilisateur et un mot de passe offre une bien meilleure sécurité.

Exemple: Supposons que nous supposons que chaque mot de passe est choisi uniformément au hasard parmi un ensemble d'un milliard de possibilités, par exemple, il s'agit d'un nombre aléatoire à 9 chiffres. (Oui, je sais que c'est une hypothèse irréaliste, donc cet exemple sera une simplification, mais les résultats similaires s'appliquent à des hypothèses plus réalistes.)

• Si le site ne nécessite qu'un mot de passe valide pour se connecter, un attaquant qui saisit des nombres aléatoires à 9 chiffres parviendra à accéder au site après environ 1000 essais, en moyenne.

• Si le site nécessite un nom d'utilisateur valide et son mot de passe correspondant pour se connecter, alors même en supposant que l'attaquant connaisse le nom d'utilisateur de tout le monde, l'attaquant devra essayer environ 1 000 000 000 (un milliard) de fois avant d'entrer sur le site, en moyenne. (En fait, la moitié, mais peu importe.)

Vous pouvez voir que la différence de sécurité est dramatique.

De plus, @Justin C's et les commentaires de @ nealmcb fournissent des raisons orthogonales supplémentaires pour exiger à la fois un nom d'utilisateur et un mot de passe. Chacune de ces raisons serait suffisante; pris ensemble, les arguments en faveur de l'exigence à la fois d'un nom d'utilisateur et d'un mot de passe sont d'autant plus solides.

La raison pour laquelle vous avez besoin à la fois d'un nom d'utilisateur et d'un mot de passe est que vous pouvez rechercher le sel unique de cet utilisateur avant de hacher et de vérifier le mot de passe.

Un schéma typique et sécurisé a une table utilisateur avec au moins 3 colonnes : nom d'utilisateur, sel, mot de passe. Le passwordhash est le mot de passe de l'utilisateur avec son sel unique (une combinaison aléatoire et unique de caractères) ajouté, puis exécutez votre algorithme de hachage. L'authentification consiste à rechercher l'utilisateur par nom d'utilisateur, à ajouter son sel unique à son mot de passe, à hacher le résultat et à vérifier qu'il correspond au mot de passe dans la base de données.

Si vous hachez simplement le mot de passe et le stockez dans la base de données , qu'un attaquant qui accède à votre table utilisateur peut trouver certains des mots de passe courants en utilisant une table arc-en-ciel (liste des mots de passe courants). Autrement dit, ils prennent la liste des mots de passe courants, les hachent tous et voient si l'un d'entre eux correspond au mot de passe stocké dans votre base de données. Si chaque utilisateur a un sel unique, alors il devrait ajouter ce sel à chaque mot de passe de la table arc-en-ciel, puis les hacher tous, juste pour voir s'ils trouvent une correspondance pour cet utilisateur. Ensuite, ils doivent répéter cela pour chaque utilisateur de votre table. Cela augmente considérablement le calcul nécessaire pour trouver un mot de passe correspondant à partir d'une table utilisateur volée.