Punir les utilisateurs pour les mots de passe non sécurisés [fermé]

Je pense à limiter les droits des utilisateurs qui choisissent des mots de passe non sécurisés (l'insécurité d'un mot de passe étant déterminée par la longueur, le nombre de types de caractères (majuscules / minuscules, chiffres, symboles, etc.) utilisés, et s'il peut être situé dans une table arc-en-ciel) pour limiter les dommages que leur compte peut causer en cas de compromission.

Je n'ai pas encore d'application pour cette idée, mais disons que j'écris un forum ou quelque chose comme ça: les utilisateurs qui utilisent 1234 comme mot de passe devront peut-être remplir un captcha avant de poster, ou être soumis à des mesures anti-spam rigoureuses telles que comme des délais d'attente ou des filtres bayésiens rejetant leur contenu. Si ce forum est très hiérarchisé, permettant une "promotion" aux modérateurs ou quoi que ce soit par quelque moyen que ce soit, cela les empêcherait d'obtenir des privilèges ou leur dirait qu'ils ont des privilèges, mais ne les laisserait pas les exercer sans passer à un système plus sécurisé. mot de passe.

Bien sûr, cela ne pouvait pas être la seule mesure de sécurité, mais cela pourrait bien aller à côté de bonnes pratiques de sécurité sinon.

Qu'est-ce que tu penses? Est-ce juste en faire trop, en dérobant l'attention aux pratiques de sécurité plus importantes, ou est-ce un bon moyen de limiter les risques et d'encourager les utilisateurs à utiliser des mots de passe plus sûrs (et, espérons-le, à convaincre les gens que vous utilisez de bonnes pratiques de sécurité)?

YAGNI , KISS , DRY , la règle des 10 secondes et le fait que "[les] utilisateurs ne se soucient pas de VOUS" devraient probablement le réduire à une seule solution: Ne le faites pas.

• C'est plus de travail de développement qui nécessiterait beaucoup de tests pour être fiable et sécurisé.
• Cela réduit probablement la sécurité du site de quelque façon que ce soit. La probabilité qu'un bogue entraîne une élévation de privilèges avec un mot de passe terrible est tout simplement trop grande.
• Il augmente la complexité pour le développeur, le testeur, le mainteneur, le DBA, l'administrateur système et l'utilisateur.
• Plus il y a de complexité, plus il est difficile d'éviter de se répéter d'une manière ou d'une autre.
• Les utilisateurs n'ont pas la capacité d'attention pour lire vos informations et les suivre. Ils sont habitués à peaufiner le formulaire d'inscription jusqu'à ce qu'il accepte l'entrée, pas jusqu'à ce qu'ils atteignent un niveau idéal.
• Les utilisateurs s'en moquent.

Soit forcer un mot de passe sécurisé lors du changement d'inscription, soit utiliser un OpenId (Jeff Atwood's 2c: http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html ). Concentrez-vous ensuite sur des fonctionnalités plus intéressantes.

D'une part, les utilisateurs ont l'habitude d'être obligés de créer des mots de passe sécurisés ou d'utiliser leur OpenId, c'est donc simple pour eux.

Pourquoi autoriser les mots de passe que vous jugez mauvais en premier lieu? L'arrêt du problème à la source vous fera gagner beaucoup de temps lors de la conception pour essayer de déterminer quelles classes de mots de passe correspondent à quels rôles. Puisqu'un administrateur, par définition, aurait tous les droits, vous auriez déjà besoin de fonctionnalités pour vous assurer qu'il n'entre pas un mot de passe qui le restreindrait.

Ma réponse se résume vraiment à KISS .

En tant qu'utilisateur, cela me convaincrait probablement de ne pas utiliser votre site. Je veux dire, sérieusement, ma banque me dit qu'un code à 6 chiffres est parfaitement sûr pour les services bancaires en ligne, mais quand je veux écrire un commentaire sur un blog moins connu, je suis censé me souvenir d'un mot de passe unique contenant au moins 8 majuscules - et des minuscules, un chiffre, un caractère spécial et un symbole grec ou cyrillique qui ne peuvent être saisis que si vous connaissez par cœur la séquence unicode. Et changez-le régulièrement.

Ne vous méprenez pas, la sécurité est importante. Mais si vous ne devez pas ennuyer vos utilisateurs, à moins que vous n'ayez de bonnes raisons de croire que quelqu'un tentera de déchiffrer leurs mots de passe pour accéder à votre site. Si votre site fournit un accès VPN au réseau du FBI, allez-y, agacez. Mais s'il s'agit d'un forum d'utilisateurs où toute personne possédant une adresse e-mail peut s'inscrire, à quoi ça sert vraiment?

Meilleure solution: visages souriants.

Je suis serieux! La lecture de livres d'économie comportementale comme «Nudge: Improving Decisions About Health, Wealth, and Happiness» m'avait convaincu de plusieurs choses:

1. Vous ne pouvez pas forcer tout le monde à prendre de sages décisions.
2. Les gens aiment être libres de choisir, mais ils n'aiment pas beaucoup d'options.
3. Vous pouvez cependant influencer considérablement leurs choix pour le mieux avec de simples astuces.

Je vois que ces principes s'appliquent à votre situation comme ceci:

1. Restreindre les utilisateurs sur la base de mots de passe non sécurisés va très probablement les frustrer et les confondre ... en particulier pour la majorité des personnes qui ne lisent pas les explications soigneusement rédigées dans les boîtes de dialogue, et appellent simplement le Helpdesk pour dire: "Il ne travail."
2. Lors de la création de mots de passe, les utilisateurs n'ont pas besoin de voir une liste de toutes les possibilités de caractères spéciaux et tels qu'ils peuvent utiliser. Mieux vaut leur montrer un petit pop-up suggérant qu'ils ajoutent de la complexité uniquement si leur entrée ne répond pas aux exigences.
3. Les gens sont fortement influencés par les signaux sociaux - même les petits comme les visages joyeux montrant que nous approuvons leur comportement, ou les visages froncés de sourcils si nous ne le faisons pas. Certains des sites Web les mieux conçus affichent une barre de progression colorée qui passe du rouge pour Pas assez bon :( au vert pour Bon travail! :) lorsque l'utilisateur tape son mot de passe (proposé) et sa confirmation. Cette interface utilisateur leur donne une certaine pression sociale pour répondre aux normes - pour que la barre devienne verte ou pour transformer le froncement de sourcils en un sourire - alors qu'ils découvrent par eux-mêmes comment créer des mots de passe plus sécurisés à l'aide de la rétroaction immédiate du changements de couleur.

Pas à empiler, mais j'ai pensé à une autre raison de classer cela sous "Bad Idea" que je n'ai pas encore mentionnée - le support client.

Si c'est un produit qui aura des représentants du support client derrière lui, ils n'aimeront pas beaucoup ça. L'une des hypothèses sous-jacentes du support est qu'ils comprennent et peuvent prédire l'expérience utilisateur - s'ils aident un utilisateur régulier, alors la page 1 doit avoir des liens vers les pages 2, 3 et 4, où ils peuvent faire X, Y, Z , etc.

Maintenant, vous leur donnez une autre variable dont ils doivent garder la trace. Si l'utilisateur ne voit pas le lien vers la page 4, est-ce parce qu'il a fait quelque chose de stupide? Ou est-ce parce que leur mot de passe est nul et que votre système les punit en leur refusant l'accès à la page 4? Attends ... merde, refuse l'accès à l'une des sanctions pour un mauvais mot de passe, ou est-ce que je pense à la page 5? Permettez-moi de vérifier cela, juste un instant ... d'accord, cela dit que pour un mot de passe qui ne mélange pas les lettres majuscules et minuscules, l'accès aux pages paires est autorisé mais limité en lecture seule ... d'accord, Monsieur, votre mot de passe, est-il composé de toutes les lettres majuscules ou minuscules? Cas. Lorsque vous tapez simplement la lettre, c'est en minuscules; lorsque vous utilisez shift, c'est à ce moment-là qu'il est en majuscules. Avez-vous mélangé les cas dans votre mot de passe? Le mot de passe que vous avez utilisé pour vous connecter au système. Celui que vous venez d'utiliser. D'accord, allez dans Modifier, puis sélectionnez Préférences, puis Sécurité. Sélectionnez "Mots de passe enregistrés" ... non, monsieur, je ne vois pas vos mots de passe d'ici ....

Ouais. Ne fais pas ça.

Limitez les mots de passe ou informez les utilisateurs des risques de mots de passe faibles. Je suppose que si un utilisateur ne se soucie pas de ses données, vous voudrez peut-être restreindre l'accès aux autres. Peut-être que les utilisateurs se sentent plus en confiance si ceux qui suivent des pratiques de mot de passe négligentes sont éliminés. Quel est l'intérêt d'exiger un mot de passe plus fort s'il va se retrouver sur une note collante sous le clavier ou collé sur l'ordinateur portable (je ne peux pas inventer ce truc; je l'ai vu arriver).

et s'il peut être situé dans une table arc-en-ciel

Je suppose que vous voulez dire dictionnaire et non table arc-en-ciel. L'attaque par dictionnaire fonctionne simplement en testant tous les mots du dictionnaire s'ils correspondent au mot de passe. Cette attaque peut être corrigée par 5 tentatives et bloquée pendant x minutes ...

Une table arc-en-ciel ne sera utilisée que si vous hachez le mot de passe et que l'attaquant connaît le hachage. Alors il pourrait être en mesure de trouver le hachage dans la table arc-en-ciel si c'était juste "12345" ou quelque chose de similaire.

Juste pour terminer l'aller-retour: Pour rendre une table arc-en-ciel inutile, vous devez saler les mots de passe. Et utilisez un sel unqiue pour chaque mot de passe et pas seulement un pour tous. Si vous faites cela, l'attaquant doit créer une table arc-en-ciel avec le sel unique pour chaque compte auquel il souhaite accéder. Astucieux à vos côtés, vous pouvez pimenter le hachage avec l'algorithme de hachage multiple de concaténation afin qu'une génération puisse prendre une demi-seconde. Si vous avez fait cela, l'accès à un compte sur votre site Web doit valoir des jours, probablement un mois de génération de hachages pour trouver une correspondance avec ce compte ... Je ne peux pas penser à un attaquant qui essaiera d'obtenir tous les mots de passe quand il le fera prenez aussi longtemps.

Pour le temps de hachage: pensez au temps d'attente de 500 ms pour un mécanisme de connexion. Je pense que c'est acceptable ... (rappel: près d'une seconde prend la main pour SSL)