Questions

Lorsque vous vous inscrivez à un service, vous avez de bonnes chances d'obtenir "Ce nom est déjà utilisé, choisissez-en un autre" - ou quelque chose à cet effet.

Dans le système que vous proposez, cela vous dire que le code d'accès est en cours d'utilisation - super, ouvrez un nouveau navigateur et connectez-vous avec ce code d'accès! Vous venez de pirater le compte de quelqu'un d'autre.

Vous pouvez trouver n'importe quel nombre de codes d'accès existants, simplement en essayant de changer le vôtre.

Et si vous oubliez votre code d'accès ? Cela peut être atténué si le système connaît votre adresse e-mail et peut vous envoyer un nouveau code d'accès, mais vous seriez alors proche d'une authentification à deux entrées; vous pouvez aussi bien utiliser votre adresse e-mail pour vous connecter.

Le nom d'utilisateur est un identifiant , une étiquette qui indique quel utilisateur vous êtes et identifie les ressources qui vous appartiennent (ou qui font référence à vous).

Le mot de passe est un

em> authentificateur , un moyen de prouver que vous êtes autorisé à assumer cette identité d'utilisateur.

Les noms d'utilisateurs ne peuvent pas être secrets, car un système d'information a besoin de ces connaissances en clair pour étiqueter ressources et pour autoriser votre utilisation des ressources. Les mots de passe doivent être secrets, même pour le service et ses opérateurs - c'est pourquoi les mots de passe stockés sont hachés avec une fonction à sens unique.

Par "ressources" ci-dessus, je suis être délibérément inclusif. Pour une connexion utilisateur, il peut s'agir de fichiers et de processus; en tant qu'utilisateur de base de données, vous disposez de tables et d'autres objets de base de données; pour un site Web, il peut s'agir de vos publications et de vos points de réputation.

Nous l'utilisons dans certains cas.

Un exemple est la fonctionnalité partager à l'aide d'un lien de documents Google. Le lien contient une clé d'accès ou un ID de document de 45 caractères alphanumériques. C'est assez long pour à la fois garantir l'unicité et rendre difficile le forçage brutal.

Ce système d'authentification à une seule entrée serait intéressant, mais il présente quelques problèmes de sécurité:

Le principal obstacle est l'exigence d'unicité. Pour que différents utilisateurs puissent se connecter à leurs comptes respectifs, les informations de connexion (généralement nom d'utilisateur + mot de passe) doivent être uniques. En théorie, cela signifie que dans un système classique à double entrée, les noms d'utilisateur ne doivent pas nécessairement être uniques tant qu'aucun utilisateur ne partage le même nom d'utilisateur et mot de passe. Le problème est que dans un système à entrée unique, le seul identifiant disponible est le mot de passe unique, ce qui signifie que chaque utilisateur devrait avoir un mot de passe différent les uns des autres, ce qui introduit un certain nombre de vulnérabilités:

1. Vous pouvez supposer que dans tout service suffisamment populaire, un certain nombre de mots de passe évidents sont utilisés par quelqu'un . En essayant simplement de vous connecter avec des mots de passe tels que "mot de passe", "12345" et "Beatles", vous pourriez probablement accéder à au moins quelques comptes.
2. Comme mentionné par S.L. Barth, n'importe qui pouvait trouver des mots de passe existants simplement en essayant de changer leur mot de passe jusqu'à ce qu'ils rencontrent un message "mot de passe déjà utilisé". Étant donné que les mots de passe doivent être uniques, vous devez empêcher un utilisateur de choisir un mot de passe existant, révélant ainsi que le mot de passe est déjà utilisé.
3. Attaques de dictionnaire: il s'agit essentiellement de la somme logique de points 1 et 2. Si vous créez un compte, puis demandez à un script d'essayer de modifier le mot de passe à l'aide d'un dictionnaire de mots de passe, en enregistrant chaque mot de passe "déjà utilisé" qu'il rencontre en cours de route, vous pouvez rapidement et facilement créer une liste de des milliers, voire des millions de mots de passe existants, c'est tout ce dont vous auriez besoin pour accéder à tous ces comptes.

Notez qu'une sécurité intéressante et que vous en tirez est que s'il serait très facile de pénétrer dans n'importe quel nombre de comptes aléatoires (comme décrit ci-dessus), il serait beaucoup plus difficile de pénétrer dans n'importe quel compte lors d'une attaque ciblée. Parce que les mots de passe devraient être uniques, vous vous retrouveriez avec des mots de passe plus complexes dans un système à une seule entrée que dans les systèmes à double entrée actuels, et il n'y aurait pas de nom d'utilisateur que vous pourriez utiliser pour cibler un utilisateur particulier, donc la seule façon si vous vous connectez à un compte cible, vous vous frayez un chemin brutalement dans tous les comptes jusqu'à ce que vous obteniez le compte que vous recherchez. De plus, il serait plus difficile de confirmer que le compte auquel vous êtes connecté est le compte que vous recherchez, car vous ne pouvez pas utiliser le nom d'utilisateur comme preuve d'identité. C'est un effet de sécurité vraiment intéressant, alors bravo là-bas.

Le nom d'utilisateur est un identifiant et ne devrait jamais changer (*). Les meilleures pratiques de sécurité recommandent de changer le mot de passe régulièrement et chaque fois qu'il aurait pu être compromis.

Comme ces 2 parties ont une durée de vie différente, il est préférable de les garder séparées.

(*) En fait, il existe des cas d'utilisation qui nécessitent un changement de nom d'utilisateur, par exemple lorsqu'il y a une fusion entre deux entités et deux utilisateurs différents utilisent le même nom d'utilisateur. Mais la durée de vie d'un nom d'utilisateur devrait être beaucoup plus longue que celle d'un mot de passe

Mode de mot de passe principalement

et dans le passé, cela aurait nécessité des exigences de stockage / traitement supplémentaires beaucoup moins chères maintenant.

Il n'y a pas de raison technique significative à cela

Ils l'utilisent simplement pour accéder à ce document, pas pour l'identification.

ie

Ils ne le font pas connaître votre identité (pas de nom de connexion)

Mais l'url authentifie (est valide dans leur base de données)

et elle aussi vous accorde automatiquement une autorisation (pour afficher ou modifier ce document)

Le système peut facilement gérer la modification / la perte de mots de passe, de "pseudonymes", d'adresses e-mail, etc.

Les gens sont TRÈS habitués à choisir leur propre beaucoup plus court et des mots de passe beaucoup moins sécurisés qui rendraient cette approche trop peu sûre pour être pratique

Les gens sont également très habitués à la méthode «login» + «password» et prendraient une formation importante pour comprendre et faire confiance à une alternative.

Wikipédia a ce qui suit à propos de l'authentification:

Contrairement à l'identification qui fait référence à l'acte de déclarer ou d'indiquer autrement une réclamation prétendument attestant une personne ou l'identité d'une chose, l'authentification est le processus de confirmation de cette identité .

_{(je souligne)}

Dans le monde réel, imaginez que vous alliez à la banque:

1. Vous: Bonjour, je m'appelle John Doe et je voudrais ouvrir un compte.
2. Greffier: Pouvez-vous me fournir une preuve de votre identité?
3. Vous: (Fournit une carte d'identité ou un permis de conduire)

Sur le point un, vous Vous vous êtes identifié comme étant John Doe et au troisième point, vous avez prouvé cette identité d'une manière à laquelle la banque a confiance. Dans le monde réel, votre identité a généralement été décidée par vos parents il y a longtemps lorsqu'ils ont choisi votre nom.

Dans le monde en ligne, les sites utilisant le processus traditionnel d'enregistrement à deux entrées vous permettent de choisissez votre identité et aussi la façon dont vous prouvez cette identité .

Il est vrai que vous pourriez essayer de fusionner à la fois l ' identité et la preuve dans la même donnée réelle, mais est-ce là vraiment un avantage ? Le nom de l'utilisateur et une autre donnée à utiliser comme preuve sont déjà compris par tout le monde, car ils correspondent quelque peu à la vie réelle. De plus, cela rend également la mise en œuvre sous-jacente beaucoup plus simple, comme indiqué dans d'autres réponses et commentaires.

Il est également vrai que le fait d'être obligé de toujours créer une identité et une preuve dans chaque site en ligne sur lequel vous allez est un peu ennuyeux . En particulier, étant donné que la partie identité doit être unique sur ce site et que vous êtes un utilisateur tardif, ce qui signifie que toutes les identités intéressantes ont déjà été choisies.

Au départ, cela a été résolu en acceptant votre adresse e-mail comme identité , de cette façon, l'utilisateur n'a pas besoin d'y penser et l'unicité est toujours assurée.

Cependant, certains vont même plus loin et essaient de simplifier encore plus le processus en autorisant ce que l'on appelle l'authentification sans mot de passe. Ce qui est cool ici, c'est que vous n'avez pas besoin de créer une nouvelle identité ni même un nouveau mot de passe pour prouver l'identité.

Un exemple de ceci est la implémentation Auth0 de l'authentification sans mot de passe qui permet à un utilisateur de s'authentifier sur un site via un lien fourni via son adresse e-mail ou un code à usage unique fourni par SMS.

Les connexions sans mot de passe dans Auth0 permettent aux utilisateurs de se connecter sans avoir à se souvenir d'un mot de passe. Cela améliore l'expérience utilisateur , en particulier sur les applications mobiles, car les utilisateurs n'auront besoin que d'une adresse e-mail ou d'un numéro de téléphone pour s'inscrire à votre application.

Sans mot de passe, votre application n'aura pas besoin pour mettre en œuvre une procédure de réinitialisation du mot de passe et les utilisateurs évitent la pratique non sécurisée consistant à utiliser le même mot de passe à de nombreuses fins .

_{(je souligne) sub>}

Du point de vue de l'utilisateur, c'est très simple à réaliser et du point de vue du site utilisant ce type d'authentification, il est toujours possible d'identifier les utilisateurs récurrents soit en faisant correspondre leur adresse e-mail ou leur numéro de téléphone.

Si vous y réfléchissez, cela simplifie simplement ce que de nombreux utilisateurs faisaient auparavant. J'admets, par exemple, que plusieurs fois que je voulais m'authentifier sur un nouveau site, j'utiliserais simplement mon adresse e-mail et un mot de passe aléatoire dont je ne me souviendrais jamais et dans l'éventualité où mon navigateur perdrait la session ou le mot de passe stocké, je le ferais réinitialisez simplement le mot de passe.

_{Divulgation : je travaille chez Auth0.}

L'authentification basée sur un certificat PKI est un peu comme un ID utilisateur et un mot de passe en un.

signez la clé publique

PKI

Ce n'est pas vraiment possible avec les mots de passe. C'est faisable avec n'importe quel schéma où la clé / secret / identifiant / jeton / tout ce qui est stocké sur l'ordinateur d'un client et non dans le cerveau humain.

Alambiqué? Retournez exactement la même chose: si vous avez une clé / secret / identifiant / jeton / quoi que ce soit suffisamment aléatoire et suffisamment compliqué, cela n'a même pas de sens de demander un nom d'utilisateur à un humain , un pseudo, un GUID, toute autre identification pour une authentification quotidienne. Le logiciel leur dira tout cela.

Si votre logiciel n'accepte pas les comptes suckpuppet , c'est le cas. (Certains sont les bienvenus. Par exemple, ssh est satisfait de "sockpuppets", différents comptes utilisés par un humain; il demande le nom du compte même si vous fournissez une clé RSA. Les clés privées Sockpuppet RSA placées les unes à côté des autres sur le même appareil seraient complication inutile, pas plus de sécurité.) Demander un pseudo est le moyen le plus simple de prendre en charge les sockpuppets.

La clé "suffisamment compliquée" implique que nous ne nous attendons jamais à une collision . Cela implique que nous ne nous attendons jamais à avoir besoin de le sel . Cela implique qu'un humain moyen ne s'en souvient pas . Et cela implique que nous n'avons pas besoin des bits supplémentaires de complexité de la mémoire humaine du nom d'utilisateur.

Réinitialisation du compte

Le seul problème est la réinitialisation après avoir perdu la clé ou après avoir été compromise. Cela signifie un appareil perdu ou compromis. Ici, nous devons utiliser une authentification plus sécurisée (également peut-être plus gênante). Avez-vous besoin que l'utilisateur se souvienne de son surnom ici? Si vous ne demandez à l'utilisateur que le nom de famille de jeune fille d'une mère, la collision est presque certaine. Cela ne signifie pas que vous avez besoin d'un surnom, cela signifie que l'authentification du nom de famille est trop faible! Toutes les attaques concerneraient les noms de jeune fille des mères pauvres. Mais vous devrez probablement demander un identifiant global en dehors de l'application, très probablement un numéro de mobile pour la vérification par SMS (cela exclut la menace d'un attaquant contrôlant votre mobile).

Un autre schéma est e -Vérification de la messagerie, nécessitant également un identifiant global en dehors de l'application (cela exclut la menace d'un attaquant contrôlant tout votre appareil, donc c'est vraiment faible dans ce paramètre).

Observez que, dans la plupart des cas les humains n'ont pas besoin de se souvenir de leur identifiant global, mais parfois ils doivent aller le vérifier et le saisir manuellement.

Le schéma alternatif est la vérification papier pré-partagée: demandez à l'utilisateur un mot de passe à usage unique numéro 04 de la carte papier qui leur a été envoyée lors de l'ouverture d'un compte. C'est un cas où je trouve pratique d'augmenter avec une authentification "trivial secret", de sorte que quasiment toute personne qui obtient une lettre ne réinitialise pas l'accès juste pour le plaisir ou par pure curiosité. Cela pourrait être "quel code postal avons-nous utilisé pour envoyer ce papier?", Cela pourrait être le nom de jeune fille redouté, mais cela pourrait aussi bien utiliser un surnom.

Mots de passe mémorisés par les humains

Le mot de passe, ou un court texte secret dont un humain pourrait se souvenir, est un schéma inférieur qui se fait attendre depuis longtemps. Les coûts inutiles associés incluent:

• Page "Veuillez vous connecter"
• "Ce pseudo est occupé" problème
• "ce mot de passe est trop faible" problème
• besoin d'un sel côté serveur (mise à niveau du secret faible en un secret vraiment aléatoire pour contrer les tables arc-en-ciel)
• KeePass et bases de données similaires - solution trop compliquée à un problème simple consistant à faire fonctionner un schéma approprié sur d'anciennes invites de connexion

Tout cela disparaît avec le schéma de clé stocké par machine (symétrique ou asymétrique ce dernier suggéré).

Nous ne l'utilisons pas parce que ce n'est pas pratique.

Imaginez que vous avez une énorme base de données d'utilisateurs, disons 8 milliards, parce que tout le monde sur terre utilise votre site Web. Quelqu'un vient de vous remettre sa clé d'entrée unique. Comment savoir s'ils sont dans la base de données?

Vous ne pouvez pas simplement stocker les clés et les rechercher car ce sont essentiellement des mots de passe en texte brut, et stocker les mots de passe en texte brut est une mauvaise chose. Vous ne pouvez pas le hacher quelques centaines de fois avec md5 non plus parce que vous seriez vulnérable aux tables arc-en-ciel. Vous devez utiliser un algorithme de hachage de mot de passe approprié comme bcrypt avec un gros sel aléatoire.

Vous avez maintenant une clé et une grande table de sels, et vous devez comprendre lequel va avec cette clé. Mais si vous pouviez rechercher le sel, vous auriez pu simplement rechercher la clé hachée en premier lieu! Vous êtes bloqué.

Votre seul choix est de hacher la clé avec les 8 milliards de sels, puis de rechercher la base de données 8 milliards de fois (une fois pour chaque clé). Beaucoup de gens suggèrent que vous définissiez le hachage pour prendre environ 1/10 de seconde. Imaginez: 8 milliards de hachages à 1/10 de seconde chacun prendraient 25 ans pour se connecter.

À moins que vos utilisateurs ne soient particulièrement patients, vous aurez besoin d'un grand nombre d'ordinateurs pour calculer tous ces hachages en parallèle, ce qui coûte beaucoup d'argent, que vos clients devront payer, ce qui rend la concurrence plus attractive. Sinon, vous devrez réduire le facteur de travail afin que les hachages soient faciles à calculer pour vous (et, par extension, pour les attaquants). Ou peut-être développer du matériel spécialisé qui a le même effet que de réduire le facteur de travail puisque vous pouvez parier que les attaquants l'achèteront aussi.

Tout cela est commodément évité en demandant à l'utilisateur de fournir un nom à la place. Le nom n'est pas secret, il peut donc être stocké sous forme de texte brut dans la base de données. Ensuite, la base de données peut trier ses tables par nom afin que le serveur puisse rechercher efficacement le sel associé au mot de passe de l'utilisateur.

C'est pourquoi nous aurons probablement toujours des noms d'utilisateur sous une forme ou une autre: nous avons besoin d'une clé de recherche pour rendre le processus de connexion efficace, et les demandes de sel et de hachage des mots de passe font de tout ce qui ressemble à un mot de passe un mauvais candidat pour la tâche.