Question:
Pourquoi nous authentifions-nous en demandant à un utilisateur d'entrer à la fois son nom d'utilisateur et son mot de passe? L'invitation du mot de passe suffit-elle?
LaTeX
2011-03-04 20:33:20 UTC
view on stackexchange narkive permalink

Je ne sais pas pourquoi nous nous authentifions en invitant l'utilisateur à entrer le nom d'utilisateur et le mot de passe.Dans mon modèle mental, l'invite de mot de passe suffit.

La raison est la suivante:

Supposons qu'il y ait x caractères valides à utiliser.

Cas 1 (demande de nom d'utilisateur et de mot de passe)

Soit la longueur du nom d'utilisateur et du mot de passe n / 2 caractères chacun. Puisque le nom d'utilisateur est exposé au public, la probabilité de succès pour casser le mot de passe est de un sur x ^ (n / 2).

Le nom d'utilisateur est unique.

Cas 2 ( demande de mot de passe uniquement)

Soit la longueur du mot de passe de n caractères. La probabilité de succès pour casser le mot de passe est de un sur x ^ n.

Pourquoi nous authentifions-nous en demandant un l'utilisateur doit entrer le nom d'utilisateur et le mot de passe? L'invitation du mot de passe suffit-elle?

Le mot de passe est unique.

pouvez-vous me dire comment vous souhaitez enregistrer les tentatives d'accès? sur quelle base? Je suis désolé mais cette approche ne peut tout simplement pas être réglementée ...
Je vois souvent cet attaquant essayer des noms d'utilisateurs aléatoires avec (je suppose) un mot de passe fixe commun. Ils contournent donc une interdiction temporaire des noms de compte pour trop de tentatives de connexion infructueuses.
@LaTeX: Si je n'ai pas entré de nom d'utilisateur et que je viens de saisir "passw0rd1", auquel des dizaines de comptes utilisant ce mot de passe vais-je accéder? ;)
Huit réponses:
#1
+40
Justin C
2011-03-04 21:02:02 UTC
view on stackexchange narkive permalink

Je pense que le problème est d'exiger que les mots de passe soient uniques. Si j'ai entré mon mot de passe souhaité et que vous m'avez dit que je ne pouvais pas l'utiliser, il est déjà utilisé, alors je sais que je peux me connecter à un compte de personnes aléatoires avec le mot de passe que j'aurais voulu.

Donc, vous avez besoin d'un nom d'utilisateur, qui est unique et peut être connu de tous. Ensuite, vous avez un mot de passe personnel, qui n'est pas nécessairement unique, ce qui rend encore plus difficile à deviner.

Pendant que vous y êtes, hachez et salez ce mot de passe.

> Pendant que vous y êtes, hacher et saler ce mot de passe.
#2
+21
AviD
2011-03-06 01:14:17 UTC
view on stackexchange narkive permalink

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]

Bon point. Je noterai également qu'il est également possible de faire une autorisation sans identification ni authentification. Peut-être pas aussi courant que cela puisse être, mais c'est ce que l'argent vous permet de faire, par ex. dans le monde réel. Ainsi, une sorte de mot de passe nu ou de jeton pourrait également être utilisé pour accéder à un système, bien que ce ne soit pas ainsi que la plupart des systèmes sont structurés.
@nealmcb, Je suis d'accord avec cela. Cependant, l'autorisation sans identification est en réalité effectuée plus souvent que vous ne le pensez - par ex. dans tous les sites pr0n "J'ai plus de 18 ans", je ne compterais pas cela comme une identification ... C'est aussi * un peu * ce qu'est l'autorisation basée sur les revendications (voir MS Genève) ...
Bon exemple. Hmmm - quelle est la relation entre Genève et U-Prove, qui semble être le nom sur lequel ils se concentrent maintenant?
#3
+11
nealmcb
2011-03-04 23:13:42 UTC
view on stackexchange narkive permalink

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.

La possibilité de réinitialiser un mot de passe oublié est un excellent point que j'ai manqué.
#4
+5
Andreas Arnold
2011-03-04 20:42:42 UTC
view on stackexchange narkive permalink

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.

Excellent résumé. Je voulais ajouter que les mots de passe ne devraient pas non plus être chiffrés, mais hachés avec un sel, vous ne devriez donc pas pouvoir comparer les mots de passe dans tous les cas.
#5
+5
Sigtran
2011-03-04 21:11:40 UTC
view on stackexchange narkive permalink

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.

#6
+4
D.W.
2011-03-06 06:47:38 UTC
view on stackexchange narkive permalink

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.

#7
+1
mrnap
2011-03-05 02:27:53 UTC
view on stackexchange narkive permalink
" t besoin d'un nom d'utilisateur (quelque chose comme un référentiel général auquel plusieurs personnes accèdent). Dans ces scénarios, exiger un mot de passe long et complexe (alphanumérique + caractères spéciaux) puis le saler est la voie à suivre.
#8
  0
JMB
2013-08-14 22:48:45 UTC
view on stackexchange narkive permalink

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.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...