Autorisez tous les mots de passe. Soulignez simplement les conséquences.

Votre plan est étrange et étranger aux utilisateurs et je pense que beaucoup de gens préfèrent arrêter d'utiliser votre service plutôt que de se conformer. Au lieu de les laisser choisir leur propre mot de passe, vous les forcez à se souvenir de celui que vous avez choisi pour eux. C'est inacceptable pour la plupart des gens. Vous pensez que vous leur donnez le choix en "réessayez", mais la différence dans l'expérience utilisateur est à peu près la même que celle du guichet automatique par rapport au bandit manchot.

Gardez à l'esprit que le plus gros problème est le facteur humain . Ce que vous devez éviter en premier lieu, ce sont les mots de passe écrits sur un tableau blanc. Ces gars avaient un mot de passe très sécurisé. Et puis il a été diffusé à la télévision.

Si vous voulez vous assurer que personne à vos côtés ne pourra le déchiffrer, alors ce dont vous avez besoin, ce sont des procédures internes, pas une formation de singe utilisateurs. Peut-être un système où l'accès aux mots de passe salés est protégé par les mêmes limites de tentatives que le panneau de connexion de l'utilisateur. En outre, il n'est pas important de rendre impossible l'accès des travailleurs. Les commis des magasins ont un accès illimité aux caisses enregistreuses. Ce qui empêche le vol, c'est la conscience des conséquences inévitables. Utilisez l'enregistrement de session d'administration. Utilisez les procédures «minimum 2 personnes pour accéder». C'est ainsi que les banques procèdent, car des mots de passe utilisateur forts ne peuvent pas tout protéger.

Les questions spécifiques:

Cette méthode serait-elle plus sûre / efficace que de permettre aux utilisateurs de choisir la leur?

Oui. Vous réduirez la réutilisation des mots de passe et supprimerez immédiatement les mots de passe très courants.

Quelqu'un at-il une expérience de la mise en œuvre d'un système similaire? Était-ce efficace?

J'ai vu beaucoup de schémas de mots de passe «alternatifs» dans le passé. La plupart ont simplement ajouté des problèmes de support et des complications sans améliorer considérablement la sécurité.

La division du champ du mot de passe en plusieurs champs distincts est-elle bénéfique ou expose-t-elle trop d'informations?

Je pense que vous avez déjà vaincu la base attaques automatisées sans connaissance simplement en étant différent. Cela laisse une attaque ciblée. Cependant, s'il y a une inscription publique disponible, l'attaquant peut découvrir que vous avez besoin de 5 mots ou autre. Je ne pense donc pas que vous fournissiez plus d'informations à l'attaquant en les divisant en champs.

De toute évidence, ne donnez pas de conseils sur le (s) mot (s) incorrect (s) si l'authentification échoue - cela nuira à la sécurité!

Plus de conseils

Il y a beaucoup d'autres bons conseils dans d'autres réponses sur la convivialité.

Si la sécurité et la convivialité sont importantes, envisagez peut-être quelque chose de mieux que les mots de passe. SMS peut-être?

Il est possible de se faufiler avec des mots de passe pendant des lustres sans pour autant gérer correctement les risques. Chevaux de Troie sur l'ordinateur des utilisateurs, réinitialisation de l'authentification via des comptes de messagerie qui sont piratés, hameçonnage ... il y a des choses qu'aucun dérangement avec des schémas de mots de passe et des contrôles sophistiqués ne résoudra *.

Si les données sont importantes, je ferais mieux qu'un mot de passe.

(Parfois, il vaut mieux générer simplement un mot de passe aléatoire pour l'utilisateur et lui demander de le stocker en toute sécurité dans un tiroir verrouillé. Cela dépend des menaces et des attaques qui vous inquiètent, et comment le système sera utilisé.)

* Il y a beaucoup à dire sur l'offre google de l'approche à deux facteurs basée sur le risque, où l'authentification à deux facteurs n'est déclenchée qu'occasionnellement. Il contrôle les coûts et apporte une grande amélioration de la sécurité. Mais je sous-traiterais cela à moins que vous n'ayez beaucoup de temps libre :)

Vous devriez lire les Diceware. Vous pouvez obtenir 44 bits d'entropie avec quatre mots à partir d'une liste beaucoup plus petite. Si votre liste contient environ 2050 mots et que vous sélectionnez sans remplacement, chaque mot aura environ 11 bits d'entropie car log ₂ (2048) = 11. Avec 5000 mots, vous pouvez obtenir 12 bits par mot. (log ₂ (4096) = 12)

J'aime l'idée d'un lien «réessayer» sur lequel l'utilisateur peut cliquer jusqu'à ce qu'il lui soit présenté une combinaison dont il pense se souvenir.

Une chose dans votre question me dérange. Si les données sont chiffrées avec le mot de passe d'un utilisateur particulier, seul cet utilisateur pourra déchiffrer les données. Si vos données sont stockées par utilisateur, cela peut être acceptable. Notez que si un utilisateur oublie son mot de passe, les données sont toastées si le mot de passe est la clé cryptographique. Vous voudrez peut-être vraiment envisager une disposition asymétrique des touches à la lumière de cela.

Pour l'accès, ne séparez pas l'entrée en quatre champs. Cela donne à un attaquant des informations qu'il ne devrait pas avoir. Décidez simplement si les mots doivent être séparés par des espaces ou non et dites-le à vos utilisateurs.

Le problème que je vois avec cette approche est simplement sa nature non conventionnelle, qui réduira la probabilité que les gens l'utilisent même.

Personnellement, je devrais avoir une raison très convaincante pour utilisez le service afin de supporter cela, par opposition à la saisie de mot de passe traditionnelle. J'ai dit par le passé que je pense que les développeurs d'applications ont une responsabilité d'essayer de s'assurer que les utilisateurs utilisent des mots de passe forts. Pourtant; en fin de compte, c'est la responsabilité de l'utilisateur.

Considérez également que vous obligez l'utilisateur à utiliser une méthode particulière pour garantir l'entropie du mot de passe. L'approche XKCD est bonne, mais ce n'est pas la seule et il n'y a pas de preuve empirique absolue que c'est la meilleure, ni aucune assurance que si elle est la meilleure aujourd'hui, elle restera les six meilleurs mois à partir de Maintenant.

Pensez à l'utilisation de gestionnaires de mots de passe, qui peuvent générer des mots de passe très volumineux et complètement aléatoires et les saisir automatiquement pour l'utilisateur. Vous risqueriez de casser ces applications avec cette approche.

Pensez également à des choses comme l'article de grc.com password haystacks, qui prétend que ceci:

  D0g .....................  

... est un mot de passe plus fort que celui-ci:

  PrXyc.N (n4k77 # L! eVdAfp9  

... simplement parce qu'il y a un caractère supplémentaire, bien que l'entropie globale (aléatoire) soit assez faible, et cela il faut 95 fois plus de temps à un ordinateur pour deviner par force brute le mot de passe dont vous vous souviendrez le plus facilement.

Le problème est que les attaques par force brute ne sont réellement utilisées que jusqu'à une certaine longueur de mot de passe (6 à 8 caractères) à cause des dépenses informatiques ridicules à mesure que les mots de passe s'allongent. Mais même les mots de passe courts très complexes sont très vulnérables à la force brute. Les nouvelles attaques sont des attaques hybrides basées sur des modèles qui utilisent des mots de passe compromis comme modèles dans des mots de passe plus volumineux. Des GPU puissants rendent cette approche réalisable et, apparemment, elle est très efficace. Remplir simplement un mot de passe faible avec . ne semble pas être une bonne solution.

Voir également cet article, Les règles de complexité des mots de passe sont plus ennuyeuses, moins efficaces que les plus longs.

Ainsi, au moins des recherches récentes indiquent que le facteur le plus pertinent dans la force du mot de passe est la longueur du mot de passe, au moins en partie parce que les mots de passe avec beaucoup de complexité sont tout simplement trop la plupart des utilisateurs, même s'ils sont courts. L'approche XKCD permet de garantir la longueur du mot de passe en facilitant la mémorisation des mots de passe très longs, sans que ces mots de passe ne soient de simples modèles ou phrases bien connus. C'est (probablement) sa force ultime - juste la longueur des mots de passe résultants. Cela dit, je commence à me demander combien de temps «l'agrafe de batterie de cheval correcte» durera jusqu'à de nouvelles attaques basées sur des modèles hybrides.

Puisqu'il existe d'autres approches pour obtenir le même résultat, les utilisateurs celui-ci peut en fait rendre votre service plus difficile à utiliser sans un gain proportionné en matière de sécurité. De plus, si une faiblesse est décelée dans l'approche XKCD dans six mois, vous y êtes connecté et devez déployer des efforts considérables pour changer votre service.

Cela semble être un excellent moyen d'empêcher la réutilisation du mot de passe, même si vous pouvez pousser les utilisateurs hors de leur zone de confort, cela pourrait les amener à enregistrer le mot de passe dans un fichier texte afin qu'ils puissent s'en souvenir. Vous devez souligner que l'utilisateur doit se souvenir de son mot de passe ou utiliser un gestionnaire de mots de passe pour le stocker en toute sécurité (si cela est acceptable pour vous et votre système). Je voudrais également m'assurer que la solution à champs multiples fonctionne avec les gestionnaires de mots de passe courants, bien que je ne vois aucun autre problème avec la division des mots de cette façon.

En tant que fonctionnalité de gestionnaire de mots de passe avec plusieurs champs désignés comme mot de passe, cela peut être difficile Pour mettre en œuvre, je donnerais également aux utilisateurs la possibilité d'utiliser leurs propres mots de passe, mais vous devez indiquer que l'utilisateur ne doit utiliser que des séquences aléatoires générées de manière sécurisée, par exemple comme celles utilisées dans les générateurs de mots de passe inclus dans Keepass ou LastPass. Pour empêcher un utilisateur d'entrer simplement le même mot de passe qu'il utilise toujours, vous pouvez appliquer une restriction idiote juste dans le cas où il est entré par l'utilisateur pour vous assurer qu'il est réellement unique. Par exemple. 50 caractères minimum, en utilisant au moins 20 chiffres et il doit inclure des minuscules / majuscules et au moins un symbole. Cela rendra les utilisateurs experts heureux, tout en empêchant les mots de passe faibles des autres (bien que certains utilisateurs puissent compléter leurs mots de passe faibles avec 45 " 2" s et un "! ") . Vous pouvez essayer de détecter de tels cas, puis renforcer le message selon lequel cette option est à utiliser uniquement avec les générateurs de mots de passe, mais il y aurait des rendements décroissants en mettant autant d'efforts dans les cas extrêmes. Le meilleur choix serait d'essayer d'expliquer aux utilisateurs non experts que l'option de mots différents générés serait plus avantageuse.

Je conçois un service qui, entre autres, stocke des informations sensibles. Pour s'assurer que personne de notre côté de ne puisse récupérer ces informations, celles-ci seraient cryptées avec une clé dérivée de leur mot de passe (PBKDF2). Le mot de passe sera stocké dans un format BCrypt haché + salé dans la base de données. Il n'est jamais stocké en texte brut.

Pour qu'un chiffrement basé sur un mot de passe soit sécurisé contre les attaques hors ligne (par exemple les personnes de votre côté, ou si l'accès a été obtenu par un attaquant d'une autre manière ), vous auriez besoin d'une entropie de 128 bits ou plus, ce qui signifie que vous auriez besoin de dix mots aléatoires pour cela au lieu de quatre ou cinq. Bien que, comme vous utilisez PBKDF2 pour renforcer la clé, cela peut vous donner environ 16 bits d'entropie supplémentaire (en fonction des itérations ), donc seulement neuf mots sont nécessaires. Mon objectif est de vous assurer que vous faites le calcul pour vous assurer que votre cryptage est adéquat.

Cela rendrait encore plus difficile pour l'utilisateur moyen de se souvenir de la phrase de passe, et s'il utilisait un gestionnaire de mots de passe, vous pouvez optez également pour l'option 50 caractères et laissez-les se connecter de cette façon. Comme d'autres l'ont souligné, il semble que cela pourrait potentiellement générer de nombreuses demandes de support et que développer une seule partie d'un système d'authentification et de gestion de session sécurisé demande beaucoup d'efforts.

Votre méthode est intéressante, mais je pense que je ne l'aime pas.

1. Vous autorisez les utilisateurs à "respin the wheel" jusqu'à ce qu'ils trouvent un mot de passe qui leur plaît. Si vous faisiez cela avec des nombres à quatre chiffres, j'ai peur que certaines personnes puissent tourner encore et encore jusqu'à ce qu'elles se retrouvent avec 1234 ou 0000. Cela rendrait l'attaquant heureux.

2. Même s'il existe de nombreuses combinaisons, un attaquant peut se limiter à essayer des mots de passe uniquement de la structure que vous avez prescrite (et en fait, il peut utiliser votre service pour déterminer la liste de mots que vous utilisez).

Avant d'essayer de mettre en œuvre une politique de mot de passe, vous devriez vraiment regarder cette excellente présentation de Rick Redman à AppSecUSA 2014 intitulée "Vos exigences en matière de complexité de mot de passe sont sans valeur":

https://www.youtube .com / watch? v = zUM7i8fsf0g

Il discute du piratage des mots de passe en utilisant les modèles similaires que tous les humains utilisent pour créer des mots de passe.

L'utilisateur serait présenté avec 4-5 mots différents d'une grande liste de mots avec plus de 6 caractères (pas de mots avec des caractères spéciaux inclus, juste ASCII). La boîte de dialogue de saisie du mot de passe serait formatée avec 4-5 champs au lieu du champ unique normal, pour renforcer le paradigme de la phrase de passe. Lors de l'enregistrement, le mot de passe peut être régénéré à volonté, pour donner à l'utilisateur la possibilité de sélectionner une phrase secrète composée de mots dont il se souviendra facilement. L'utilisateur ne peut pas saisir ses propres mots.

Cela va être un problème.

Cela signifie que vous devez avoir une liste des mots en cours utilisé dans la phrase de mot de passe, et qu'il n'y a aucun écart par rapport à cette liste.

Si un hacker est capable d'obtenir la liste d'une manière ou d'une autre, que ce soit à partir de tentatives de force brute, de piratage social ou de toute autre manière, alors il a la liste des mots et il est beaucoup plus facile pour eux de comprendre le mot de passe.

Si vous faites plutôt en sorte qu'un utilisateur puisse entrer ses propres mots et autoriser des chiffres et / ou des caractères spéciaux, la phrase de mot de passe sera beaucoup plus sécurisée et vous les empêcherez toujours d'utiliser le même mot de passe que { partout ailleurs } car vous forcez toujours 4 à 5 mots pour la phrase de mot de passe.

Deux choses (dont certaines ont déjà été mentionnées)

1. Assurez-vous que les mots ne se répètent pas plus d'une fois
2. Ne pas autoriser répéter un mot plusieurs fois ( pass , word , pass , word )
3. N'utilisez pas le mot de passe comme clé pour crypter les données
   • C'est une très mauvaise idée, surtout si l'utilisateur oublie son mot de passe et a besoin d'une réinitialisation de mot de passe.
4. N'utilisez pas de schéma de mot de passe
   • Cela laisse des indices à un pirate pour éliminer les mots et les phrases, réduisant ainsi le champ.