web-dev-qa-db-fra.com

pourquoi tous les sites ne génèrent-ils pas de mots de passe pour les utilisateurs?

Je suis tombé sur cette question et je n'ai jamais vu un site qui fait ça, qui est un drapeau rouge. Cependant, l'approche semble bonne et elle contourne la nécessité d'implémenter des règles de mot de passe pour appliquer des mots de passe forts. De plus, si tous les sites le faisaient, cela garantirait aux utilisateurs de ne pas réutiliser les mots de passe. Quels sont donc les inconvénients de cette approche? Y a-t-il une bonne raison pour laquelle tous les sites n'utilisent pas cette approche?

Plus précisément, je suppose que nous suivons les meilleures pratiques mentionnées dans les commentaires et les réponses à cette question, telles que:

  • générer un mot de passe long (32+ caractères), aléatoire (avec un bon caractère aléatoire)
  • le montrer à l'utilisateur une fois
  • le hacher avec SHA256
  • la réinitialisation du mot de passe génère un autre mot de passe long et aléatoire

En fait, l'approche pourrait même être améliorée si au lieu d'afficher le mot de passe à l'utilisateur, le site affichait simplement un formulaire avec le champ de mot de passe rempli afin que le navigateur et/ou les gestionnaires de mots de passe puissent le mémoriser. L'utilisateur soumettrait simplement le formulaire et n'aurait jamais à le voir.

13
Reinstate Monica

La sécurité au détriment de l'utilisabilité se fait au détriment de la sécurité

Le problème est qu'il n'y a que peu de choses qu'une application Web peut faire pour forcer de bonnes pratiques de sécurité sur les utilisateurs. Dans ce cas particulier, je peux vous dire ce qui se passera dans la grande majorité des cas: les gens noteront leur mot de passe "sécurisé" quelque part Nice et pas sûr. En conséquence, cela ne sécurisera pas nécessairement quelque chose: cela se contentera de parcourir où se trouve la vulnérabilité. En substance, il manque à ce système une architecture de support nécessaire pour rendre l'expérience utilisateur très facile, et donc très sécurisée. En conséquence, il existe essentiellement trois types de personnes avec trois résultats différents:

  1. Les personnes qui ne se soucient pas/ne comprennent pas la sécurité des mots de passe. Ils vont écrire ce mot de passe non craquable dans un endroit super accessible, et par conséquent super insécurisé. Ce sont les mêmes personnes qui réutilisent les mêmes mots de passe faibles sur chaque site. En conséquence, ils passent d'une mauvaise solution de sécurité à une autre mauvaise solution de sécurité. Ce sont aussi la majorité des internautes, donc pour la majorité d'Internet votre solution n'a aucun réel avantage.
  2. Les personnes qui utilisent des gestionnaires de mots de passe et d'autres aides de mot de passe, leurs systèmes de mot de passe ne peuvent pas s'intégrer à votre site Web. La situation de ces personnes sera pire, car soudain, leur système normalement sécurisé ne peut plus être utilisé. En conséquence, ils finiront probablement par l'écrire, peut-être pas en toute sécurité, et seront pire qu'avant. Pour être clair, cela se produira certainement: votre solution "afficher le mot de passe sous une forme afin que le gestionnaire de mots de passe puisse l'enregistrer" ne fonctionnera absolument pas avec certains gestionnaires de mots de passe. Je peux à peu près le garantir.
  3. Les personnes qui utilisent des gestionnaires de mots de passe et ces gestionnaires de mots de passe s'intègrent correctement à votre système. Ils stockaient déjà les choses en toute sécurité et le sont toujours, mais maintenant avec un autre point de défaillance: votre générateur de nombres aléatoires. Dans l'ensemble, cependant, la sécurité n'aura ni diminué ni augmenté sensiblement.

Dans l'ensemble, je dirais donc que je ne vois aucun avantage réel pour ce système.

Je dois le dire à haute voix, car il est essentiel dans tous les autres contextes: vous ne voulez jamais utiliser SHA256 pour hacher des mots de passe. Dans ce cas, vous pouvez probablement vous en sortir avec un hachage rapide car votre mot de passe est trop long pour qu'une force brute soit de toute façon réalisable.

Modifier pour ajouter la réponse évidente

Je pense que le plus gros problème avec cette solution est qu'elle ne va pas assez loin pour résoudre le problème sous-jacent. Le problème sous-jacent est que les gens se moquent des mots de passe: nous choisissons les mauvais, les réutilisons ou ne les stockons pas en toute sécurité. La solution n'est pas de trouver un nouveau système de mots de passe: la solution est de laisser tomber les mots de passe tous ensemble. De nombreuses entreprises commencent à introduire une connexion sans mot de passe. Voilà la réponse que vous voulez vraiment.

22
Conor Mancone

Votre solution oblige les gens à utiliser un gestionnaire de mots de passe. Les gens peuvent enregistrer leurs mots de passe dans un navigateur, mais ce n'est pas toujours crypté et n'est souvent stocké que localement, ils ne peuvent donc plus accéder à votre service à partir de plusieurs ordinateurs. Gardez à l'esprit que la plupart les gens ne savent même pas ce qu'est un gestionnaire de mots de passe.

De plus, même s'ils ont un gestionnaire de mots de passe, y ont-ils accès sur tous leurs appareils? Si quelqu'un doit taper un mot de passe aléatoire de 32 caractères, même une fois, il commencera à détester votre site pour cela.

9
JPhi1618

Deux choses qui me viennent à l'esprit:

  1. Les utilisateurs détesteraient ne pas pouvoir choisir leur propre mot de passe car à moins qu'ils aient déjà un gestionnaire de mots de passe ou une sorte de système, c'est une chose supplémentaire dont ils doivent se souvenir ou écrire ou garder une trace de quelque part.

  2. Si le site Web prend la responsabilité de générer des mots de passe "aléatoires", les méthodes qu'il génère un mot de passe pourraient se révéler défectueuses à l'avenir, ce qui mettra en danger la sécurité de tous les mots de passe existants à la fois. Je pense que récemment, il y avait une puce matérielle qui a généré des mots de passe BitLocker dans des ordinateurs dont la faille a été découverte et maintenant tous ces mots de passe BitLocker peuvent être piratés avec environ 40000 $ en AWS - beaucoup d'argent pour un individu, mais pour une entreprise ou un gouvernement, non beaucoup.

3
downwardCorgi

quels sont les inconvénients de cette approche?

Pour commencer, c'est une étape supplémentaire que d'autres méthodes d'authentification ont considérablement réduite. C'est un effort supplémentaire pour vos utilisateurs. Les mots de passe sont ... faciles à oublier, et cela peut devenir un problème qui va à l'encontre de leur objectif. Plus important encore, des règles de mot de passe solides et déconnectées de la réalité sont une insécurité.

Vous pouvez observer cela à travers les personnes qui essaient leur mot de passe le plus courant sur un forum, seulement pour découvrir qu'ils se sont trompés à cause d'une règle obscure et anormale qu'ils ont oubliée, et donc ils continuent à perroquet combinaison de nom d'utilisateur et mot de passe ils ont déjà utilisé dans les champs de connexion. Quel est l'intérêt des mots de passe si vous allez simplement les partager avec des inconnus aléatoires comme ça?

Chaque fois que je remarque des sites qui font cela, je soupçonne qu'ils pourraient subtilement essayer de hameçonner les mots de passe d'autres sites. En ce qui me concerne, à moins que vous ne soyez une agence bancaire de nos jours, vous devriez probablement éviter de stocker des mots de passe si vous voulez être considéré comme légitime. Il existe de meilleures méthodes qui sont plus fiables et plus sûres.

Pour élaborer: à moins que vos utilisateurs n'aient quelque chose à protéger, laissez-les utiliser le mot de passe qu'ils veulent. Autrement dit, si vous décidez d'utiliser un mot de passe, même des mots de passe vierges devraient être acceptables.


Y a-t-il une bonne raison pour laquelle tous les sites n'utilisent pas cette approche?

J'exécute ce que certains considèrent généralement comme des "sites" auxquels je donne parfois accès à d'autres, et je ne stocke pas de mots de passe ou ne respecte pas les exigences de mot de passe pas du tout; J'utilise des certificats pour l'authentification (comme toute technologie moderne devrait le faire), et les gens peuvent (s'ils le souhaitent) protéger ces certificats avec une phrase secrète à leur fin .

Mes sites sont des serveurs, et il y a une très bonne raison je ne ' Je ne veux pas stocker les mots de passe d'autres personnes. Si l'un de mes utilisateurs parvient à obtenir un accès administratif à mes serveurs, il peut obtenir d'autres hachages de mot de passe.

De même, vous pouvez observer ce site , pour lequel vous n'aviez probablement pas à saisir de mot de passe car vous étiez déjà connecté au réseau StackExchange ... et le réseau StackExchange vous permet de vous connecter en utilisant Facebook ou Google, donc il y a ça aussi.

L'authentification par certificat n'est pas nouvelle; il est utilisé dans PAM depuis des années, ne nécessite pas d'authentification par mot de passe et est certainement encore plus fort à utiliser pour les institutions bancaires qu'un simple mot de passe.


générer un mot de passe long (32+ caractères), aléatoire (avec un bon caractère aléatoire)

Vous pouvez le faire, mais lorsque vous oubliez ou désorganisez vos mots de passe, vous finirez par donner des mots de passe pour certains services à d'autres services. Si cela vous satisfait, tant pis. Le monde n'arrêtera pas de tourner si votre compte bancaire est ouvert.

Désolé, mais vous ne trouverez personne pour affirmer que la génération d'un mot de passe long et aléatoire est plus sûre que la génération d'un certificat privé long et aléatoire utilisé pour signer du sel nonce et jamais directement stocké du côté des serveurs.


le montrer à l'utilisateur une fois

Vous ne devez pas montrer à l'utilisateur (sauf si le mot de passe est pour quelque chose sans importance , comme vos forums Internet), mais votre générateur de clé SSH devrait plutôt demander à l'utilisateur de répéter sa phrase secrète au moment où la clé est générée. Cela a le même effet que la vérification visuelle (peut-être même plus fort), sauf que vous n'affichez pas votre "mot de passe" en texte brut pour que quiconque regarde par-dessus votre épaule puisse le voir ...


le hacher avec SHA256

On pourrait même aller jusqu'à suggérer l'utilisation d'un sel . Le problème est que vous stockez toujours un condensé et vos utilisateurs peuvent toujours perroqueter les mots de passe pour d'autres services. La solution au problème "Mot de passe oublié" n'est pas d'essayer tous les mots de passe que vous avez déjà utilisés , affaiblissant ainsi considérablement votre sécurité, mais de éliminer les mots de passe (de votre serveur).


la réinitialisation du mot de passe génère un autre mot de passe long et aléatoire

Même les schémas d'authentification par mot de passe les plus solides présentent des défauts de longue durée en raison d'une autre technologie , comme le courrier électronique ou les téléphones portables; lorsque l'un de ceux-ci devient le lien le plus faible, vous constaterez que l'option mot de passe s'effondre entièrement.

La voie à suivre en matière de confidentialité et de sécurité consiste à utiliser des clés cryptographiques pour authentifier, plutôt que des e-mails, des numéros de téléphone, des mots de passe et des codes PIN.


En fait, l'approche pourrait même être améliorée si au lieu d'afficher le mot de passe à l'utilisateur, le site affichait simplement un formulaire avec le champ de mot de passe rempli afin que le navigateur et/ou les gestionnaires de mots de passe puissent le mémoriser. L'utilisateur soumettrait simplement le formulaire et n'aurait jamais à le voir.

La solution est de stocker le mot de passe quelque part dans la mémoire, afin que les gens n'aient qu'à accéder à cet emplacement de mémoire pour le trouver? Cela ne me semble guère être une solution. Utilisez quelque chose de physique, comme une clé GPG protégée par une phrase secrète sur une clé USB.

3
autistic

Vous n'êtes pas le seul à le suggérer, car j'ai vu de nombreux articles étudier des schémas similaires. Cependant, les mots de passe générés par le système sont généralement beaucoup moins utilisables que les mots de passe générés par l'utilisateur.

En n mot de passe généré par le système et une approche mnémonique , le chercheur Sanjaykumar Ranganayakulu a conclu:

En général, cette recherche a révélé que les gens ont tendance à se souvenir des mots de passe et des mnémoniques qu'ils génèrent mieux que ceux qui leur sont attribués. Même si les mnémoniques générés par le système étaient des phrases significatives, les participants ne pouvaient pas s'y rapporter aussi bien que les mots de passe ou les mnémoniques créés eux-mêmes.

Une ancienne étude navale américaine de 1990 par Moshe Zviran et William J. Haga a comparé plusieurs schémas de mot de passe. Le rappel des mots de passe après plusieurs mois a montré que les mots de passe prononçables générés par le système fonctionnaient mieux, les mots de passe et les phrases secrètes générés par les utilisateurs fonctionnaient bien, et les mots de passe générés par le système alphanumériques étaient les plus mauvais en mémoire, chaque utilisateur écrivant son mot de passe plutôt que de le mémoriser. Malgré les performances surprenantes des mots de passe prononçables, les utilisateurs préfèrent toujours choisir leurs propres mots de passe:

personne n'a été en mesure de se souvenir de leur mot de passe généré par le système et généré au hasard ...

Lorsqu'on leur a demandé de classer les différentes méthodes en fonction de leur facilité de mémorisation, les répondants ont clairement choisi les mots de passe générés par les utilisateurs comme celui qu'ils jugeaient le plus facile ...

Lorsque la capacité de l'utilisateur à se souvenir des différents types de mots de passe est examinée, les mots de passe prononçables [générés par le système] se sont avérés bien meilleurs que les phrases secrètes, les mots de passe générés par le système aléatoires ou même les mots de passe sélectionnés par l'utilisateur

En fin de compte, l'utilisabilité du mot de passe généré par le système varie énormément selon le schéma. Votre système, avec 32 caractères alphanumériques aléatoires, ne semble pas du tout conçu pour être convivial. Cependant, certains schémas de génération de systèmes ont une sécurité décente et une facilité d'utilisation raisonnablement élevée, comme le schéma "choisissez quatre mots aléatoires" de xkcd. D'autres schémas conviviaux générés par le système incluent la génération de mots de passe prononçables et les alphanumériques générés de manière aléatoire avec une mnémonique utile générée par le système. Ces types de régimes, lorsqu'ils sont étudiés, résistent beaucoup mieux que des systèmes comme celui que vous proposez.

Il y a d'autres problèmes techniques au-delà des problèmes d'utilisabilité recherchés, mais d'autres réponses ont déjà couvert ces problèmes.

Ainsi, des programmes comme le vôtre ont été évalués plusieurs fois dans la recherche et ne sont pas bien accueillis par les utilisateurs. En général, les mots de passe générés par le système ne sont pas bien reçus par les utilisateurs, et à moins d'être soigneusement mis en œuvre, ils sont plus difficiles à rappeler. Les alternatives sont généralement beaucoup plus appropriées, comme les indicateurs de force de mot de passe, les notifications de comportement suspect, l'authentification à deux facteurs, les exigences de longueur de mot de passe, l'interdiction des mots de passe courants et la protection contre les attaques par force brute et les fuites de hachage de mot de passe.

2
Cody P

Pas un avocat, mais une raison importante à laquelle je peux penser pour les entreprises qui ne veulent pas assumer la responsabilité des mots de passe de l'utilisateur est que cela ouvre la responsabilité de l'entreprise en cas de violation de données parce que quelqu'un a obtenu un mot de passe et a fait quelque chose. Certes, ce qui se passe une fois le mot de passe généré est la responsabilité de l'utilisateur, mais il serait coûteux d'établir cela devant un tribunal si quelqu'un (ou pire, une classe de quelqu'un, dans un cas comme Yahoo! Ou Adobe) a décidé de tenir la société seul responsable.

À un niveau plus pratique, les gens ont des options, et seuls les fanatiques de la sécurité iront avec quelque chose qui rejette la pratique courante et la commodité au nom d'un degré de sécurité accru qu'ils ne savent même pas comment quantifier. Même s'ils décident de continuer à essayer le service, à la troisième ou quatrième réinitialisation du mot de passe parce qu'ils l'ont oublié, ont mal tapé un caractère (qu'ils ne pouvaient pas voir, en raison des restrictions de champ de mot de passe), ne pouvaient pas le coller, etc. ., ils vont réfléchir sérieusement à votre compétiteur qui ne les met pas dans de tels cerceaux juste pour vérifier comment leur équipe de football fantastique se porte aujourd'hui.

2
Kaji