Citations pour inadvertance d'un mot de passe unique au monde


20

Je suis en désaccord avec quelqu'un (un client) sur le processus d'identification / d'authentification des utilisateurs d'un système. Le nœud du problème est qu'ils veulent que chaque utilisateur ait un mot de passe unique au monde (c'est-à-dire que deux utilisateurs ne peuvent pas avoir le même mot de passe). J'ai déployé tous les arguments évidents contre cela (c'est une vulnérabilité de sécurité, cela confond l'identification avec l'authentification, c'est inutile, etc.) mais ils insistent sur le fait qu'il n'y a rien de mal à cette approche.

J'ai effectué diverses recherches sur Google à la recherche d'opinions faisant autorité (ou semi-autorisées, ou même simplement indépendantes) à ce sujet, mais je n'en trouve aucune (principalement c'est juste un faux pas évident qu'il ne vaut pas la peine d'être averti, car autant que je sache). Quelqu'un peut-il me diriger vers une telle opinion indépendante, s'il vous plaît?

[EDIT]
Merci pour toutes vos réponses, mais je comprends déjà les problèmes avec cette approche / exigence proposée, et je peux même les expliquer au client, mais le client ne les acceptera pas, d'où ma demande de sources indépendantes et / ou faisant autorité .

J'avais également trouvé l'article du Daily WTF, mais il souffre du problème que Jon Hopkins a signalé - qu'il s'agit d'un WTF si évident qu'il ne semble pas utile d'expliquer pourquoi .

Et oui, les mots de passe vont être salés et hachés. Dans ce cas, l'unicité globale pourrait être difficile à garantir, mais cela ne résout pas mon problème - cela signifie simplement que j'ai une exigence que le client ne bouge pas, ce n'est pas seulement mal avisé, mais il est également difficile à mettre en place. Et si j'étais en mesure de dire "Je ne bouge pas sur le salage et le hachage", alors je serais en mesure de dire "Je n'implémente pas de mots de passe uniques au monde".

Des pointeurs vers des sources indépendantes et / ou faisant autorité pour expliquer pourquoi c'est une mauvaise idée sont toujours reçus avec gratitude ...
[/ EDIT]


2
C'est une idée assez étrange que je pense que vous allez avoir de la chance de trouver beaucoup d'écrits à ce sujet. À mon avis, il est si manifestement imparfait qu'il ne serait pas considéré comme suffisamment sérieux pour être écrit par des experts en sécurité.
Jon Hopkins

3
J'espère vraiment, vraiment que vous ne stockez pas de mots de passe en clair, mais plutôt salés et hachés. S'ils sont salés et hachés, il sera difficile de garantir l'unicité mondiale. Sinon, je me fiche de votre sécurité, car je sais déjà que c'est mauvais.
David Thornley

1
Malgré les vulnérabilités de sécurité, ne pourriez-vous pas simplement rejeter le mot de passe s'il ne parvient pas à hacher uniquement?
Robert Harvey

Après la modification, je réitère ma réponse - ce n'est pas un "ne veut pas" c'est un "ne peut pas" (en raison de la façon dont les mots de passe doivent être stockés) - donc au lieu d'expliquer pourquoi c'est mauvais pour quelqu'un qui n'est pas ' t intéressé, vous devez remonter le processus et comprendre pourquoi le client estime que cela est nécessaire en premier lieu.
Murph

2
Il est intéressant de noter qu'ils vous font suffisamment confiance pour concevoir leur système, mais pas assez pour les conseiller sur la conception de leur système.
Gary Rowe

Réponses:


24

Chaque fois qu'un client essaie de créer un mot de passe qui existe déjà, il reçoit des informations selon lesquelles un utilisateur utilise déjà ce mot de passe, généralement une violation de l'accord de confidentialité.

À côté de cela, les noms d'utilisateur sont beaucoup plus faciles à deviner (et s'il y a un forum, vous pouvez simplement y trouver beaucoup de noms d'utilisateur) et vous indiquez les moyens utilisés par les utilisateurs pour pirater le site Web.

Il devrait y avoir une page sur Internet quelque part qui décrit la partie de la violation de l'accord de confidentialité, à part que c'est juste du bon sens: ils donneraient à quelqu'un une clé et une liste d'adresses personnelles.

EDIT: Pas proche de l'autorité, mais peut-être utile après avoir expliqué ce que signifie WTF: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx


+1 De plus, la plupart des schémas d'authentification vous permettent d'essayer autant de noms d'utilisateur que vous le souhaitez, tout en ne vous donnant que trois essais avec un mot de passe.
Michael K

1
Ce WTF sert à utiliser le mot de passe comme clé primaire / étrangère plus que toute autre chose. Eh bien peut-être aussi pour les mots de passe en texte brut.
Murph

2
+1: Vous ne devez jamais laisser savoir qu'un autre utilisateur possède le même mot de passe. Parlez d'une faille de sécurité massive ... Vous pouvez exécuter des attaques par mot de passe par force brute en changeant votre mot de passe à plusieurs reprises. Cela passerait sous le radar de nombreux systèmes de surveillance.
Satanicpuppy

En fait, dans certains contextes, avoir un seul champ pour un identifiant de connexion serait raisonnable, si les mots de passe devaient être choisis de sorte qu'une partie particulière [par exemple la première lettre] soit unique. Si l'on a 26 utilisateurs ou moins, par exemple, on pourrait dire que chaque utilisateur doit choisir un mot de passe commençant par une lettre différente. Un tel système équivaudrait à avoir 26 noms d'utilisateur distincts à un seul caractère, mais éviterait d'avoir à taper «tab» ou «enter» entre le nom et le mot de passe.
supercat

10

Les meilleures pratiques empêchent de répondre à l'exigence:

Vous ne pouvez pas faire cela parce que vous ne savez pas quels sont les mots de passe, vous ne pouvez donc pas les comparer parce que tout ce que vous stockez est le hachage du mot de passe et un sel (que vous pouvez stocker à côté du mot de passe haché). C'est la meilleure pratique, c'est donc ce que vous faites. Terminé.

Un autre montage: Doh! Le recul est facile - vous pouvez toujours vérifier l'unicité parce que (bien sûr) vous avez le sel ... tirez-moi maintenant ... bien sûr, vous n'avez pas à mentionner ce détail au client.


FWIW, ce n'est pas aussi stupide que vous le pensez - le but est d'empêcher des groupes d'utilisateurs d'accepter et de partager le même mot de passe, ce que les gens feront en pensant que cela leur facilitera la vie.

S'il est appliqué avec une exigence de changer le mot de passe régulièrement et une contrainte qui empêche les gens de réutiliser un mot de passe actuel ou précédemment utilisé (jamais) et des exigences de "force" raisonnables (ou au moins un dictionnaire préchargé de "bloqué" "mots de passe), vous allez arriver à un point, assez rapidement, où les chances ne sont pas en faveur du pirate de toute façon.


Ok, ma réponse a commencé par:

Il y a théoriquement très peu de mal à cela, étant donné quelques réserves - dont la plupart sont que je suis épais ...

Humour inapproprié apparemment - le fait était que si vous n'avez pas la contrainte unique au monde, vous créez des opportunités différentes, peut-être moins dangereuses - je ne sais pas.


4
+1 pour avoir donné un aperçu de la raison pour laquelle quelqu'un peut demander des mots de passe uniques
Michael Haren

3
Mais c'est une vulnérabilité de sécurité - si vous êtes un utilisateur, entrez un nouveau mot de passe et on vous dit qu'il n'est pas valide, vous savez maintenant qu'au moins un utilisateur possède ce mot de passe. Combinez cela avec d'autres facteurs (disons la langue dans laquelle le mot est, ou un certain contexte / sens qu'il pourrait avoir pour quelqu'un) et vous avez découvert un nombre très limité d'options qui pourraient facilement tomber dans une attaque par force brute - même potentiellement un manuel un.
Jon Hopkins

Euh, je n'ai pas dit que ce n'était pas un problème potentiel, j'ai dit que ce n'était pas aussi stupide que ce qui était suggéré dans la question car cela empêche plusieurs utilisateurs d'avoir le même mot de passe (ce qui arrive) et ce qui est pire si ces mots de passe sont faibles en premier lieu. Permettre aux utilisateurs d'accéder à un système est une vulnérabilité de sécurité ... mais nous devons l'accepter et donc tout ce qui suit est un compromis.
Murph

+1 pour avoir souligné que vous ne pouvez pas le faire si vous gérez correctement les mots de passe.
David Thornley

Pouvons-nous également noter que ma réponse est que vous ne pouvez pas tester l'unicité car vous devriez quand même hacher le mot de passe? Donc, si j'ai un downvote pour avoir suggéré que j'aimerais savoir pourquoi?
Murph

10

L'application de mots de passe non reproductibles fuit des informations

Comment? Parce que chaque fois qu'un pirate tente de créer un nouvel utilisateur avec un mot de passe simple, votre système répond par "Non, ne peut pas avoir ce mot de passe", le pirate dit "Goody, c'est un pour la liste".

La fuite d'informations sur votre sécurité est généralement une mauvaise chose. OK, des tiers connaissant que l'algorithme est bien (il a besoin d'un examen par les pairs) mais permettant à un pirate dédié d'inférer des clés - mauvais, vraiment, vraiment mauvais.

Ressources décrivant les bonnes et les mauvaises politiques de gestion des mots de passe

Lisez cet article de l'expert en sécurité Bruce Schneier pour une discussion approfondie sur la force des mots de passe.

Lisez ce PDF par les chercheurs en sécurité Philip Inglesant et M. Angela Sasse pour une discussion approfondie sur "Le vrai coût des politiques de mot de passe inutilisables". Pour citer la conclusion:

Contre la vision du monde selon laquelle «si seulement [les utilisateurs] comprenaient les dangers, ils se comporteraient différemment» [12], nous soutenons que «si seuls les responsables de la sécurité comprenaient les véritables coûts pour les utilisateurs et l'organisation, ils définiraient les politiques différemment».

Faux sentiment de sécurité

Ainsi, le client répond: «Si personne n'a le même mot de passe, alors si l'un est piraté, une seule personne est affectée». Non. Tout le monde est concerné car le pirate a démontré que votre système de mot de passe est fondamentalement défectueux: il est vulnérable à une attaque par dictionnaire dans un système en ligne. Il n'aurait pas dû être possible pour un pirate de tenter plusieurs suppositions contre un mot de passe en premier lieu.

Pour un accès en ligne, 6 caractères suffisent

Aller hors sujet, mais j'ai pensé qu'il valait la peine d'être mentionné pour les lecteurs intéressés. En termes de sécurité, un système en ligne est un système doté d'un processus de gestion de la sécurité actif qui surveille et contrôle l'accès aux données. Un système hors ligne est un système qui ne fonctionne pas (comme avoir des données chiffrées sur un disque dur qui a été volé).

Si vous avez un système de mot de passe en ligne, vous n'avez pas besoin de mots de passe de haute sécurité. Les mots de passe doivent seulement être suffisamment complexes pour empêcher les suppositions dans les 20 tentatives (donc une simple attaque "nom du conjoint / enfant / animal" échouera). Considérez l'algorithme suivant:

  1. Cracker devine le mot de passe en utilisant l'approche "root plus suffix" pour minimiser les suppositions
  2. Informations d'identification rejetées et autres tentatives de connexion empêchées pendant N * 10 secondes
  3. Si N> 20 verrouiller le compte et informer l'administrateur
  4. N = N +1
  5. Informez l'utilisateur que la prochaine connexion peut avoir lieu au temps T (calculé ci-dessus)
  6. Aller à l'étape 1

Pour un mot de passe simple à 6 caractères, l'algorithme ci-dessus empêchera les attaques par dictionnaire, tout en permettant même à l'utilisateur le plus inepte d'un clavier mobile de passer. Rien n'empêchera la soi-disant «attaque de tuyau en caoutchouc» où vous battez le détenteur du mot de passe avec un tuyau en caoutchouc jusqu'à ce qu'il vous le dise.

Pour un système hors ligne lorsque des données chiffrées traînent sur un lecteur flash et que le pirate est libre de tout essayer, vous voulez la clé la plus résistante que vous puissiez trouver. Mais ce problème est déjà résolu .


1
Qu'entendez-vous par accès "en ligne"? Y en a-t-il un autre?
Robert Harvey

Voir la dernière phrase pour la différence en termes de sécurité.
Gary Rowe

4

Si vous les avez déconseillés et que vous leur avez fourni des raisons, je les prendrais au mot et je mettrais simplement en œuvre le système comme ils le suggèrent. Ce n'est peut-être pas satisfaisant, mais vous avez fait votre travail, et ils paient la facture, alors ils devraient obtenir ce qu'ils veulent.

Il y a une exception. Si les conséquences négatives d'une violation du système seraient graves (par exemple, si des informations très privées sont susceptibles d'être compromises par une violation de la sécurité), vous pouvez en fait avoir l'obligation professionnelle de ne pas mettre en œuvre le système souhaité. Ne vous attendez pas à ce que cela vous rende populaire si vous refusez, mais ne laissez pas cela vous guider.


4

Je veux juste renforcer la réponse de Murph. Oui, c'est un problème de sécurité et il existe des vulnérabilités de divulgation d'informations dans sa mise en œuvre. Mais du point de vue du client, il ne semble pas trop inquiet à ce sujet.

Ce que vous devez souligner, c'est qu'il est physiquement impossible d'implémenter une vérification de "mot de passe unique". Si vous salez et hachez un mot de passe, et que vous ne le stockez pas en texte clair, alors ce sont des opérations O (n) (coûteuses) pour effectuer la vérification d'unicité.

Pouvez-vous imaginer si vous avez 10 000 utilisateurs et qu'il faut 30 secondes pour parcourir le mot de passe de chaque utilisateur pour vérifier l'unicité chaque fois qu'une nouvelle personne s'inscrit ou modifie son mot de passe?

Je pense que c'est la réponse que vous devez apporter à votre client.


Ouais. Ce serait un bon point à souligner.
PeterAllenWebb

1

En pensant simplement à l'endroit approprié pour poser la question, la section sécurité informatique de Stack Exchange devrait être un point utile pour vous. Essayez /security/tagged/passwords - un éventail de personnes axées sur la sécurité informatique devrait être en mesure de fournir des réponses spécifiques.


0

Il aimerait probablement le cryptage RSA à deux facteurs. Si vous utilisez Active Directory ou l'appartenance à ASP.NET, c'est une évidence.

texte alternatif

Le jeton matériel ou logiciel génère un mot de passe unique dépendant du temps qui est suivi d'un code PIN. Ensemble, cela fournit un mot de passe unique pour chaque utilisateur.


Le double facteur est inutile pour prévenir les attaques de l'homme du milieu.
BryanH

Certes, mais cette déclaration ne semble pas se rapporter à la question à l'examen.
goodguys_activate

Mais maintenant je connais votre 2ème facteur !!! Oh attendez ... veuillez mettre à jour votre photo
Michael Haren

2
Hmm, je pense que ce serait cool de faire un GIF animé
goodguys_activate
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.