Question:
Pourquoi une vérification de la complexité du mot de passe côté client n'est-elle pas considérée comme sécurisée?
Marco Altieri
2017-04-27 12:46:54 UTC
view on stackexchange narkive permalink

J'ai une application Web et j'ai mis en place une vérification sur le navigateur pour m'assurer qu'un utilisateur ne définit que des mots de passe forts.Une entreprise que nous avons appelée pour vérifier les vulnérabilités de sécurité a souligné que cela ne suffit pas car en utilisant un piratage d'un utilisateur peut ignorer la vérification et définir un mot de passe faible.

Je ne comprends pas comment cela peut être une faille de sécurité. Pourquoi quelqu'un piraterait le contrôle de sécurité juste pour définir un mot de passe faible? Quelqu'un suffisamment expert pour pirater l'application Web comprendra l'importance d'utiliser un mot de passe fort.

La seule raison pour laquelle je peux penser est que quelqu'un, très très paresseux, peut décider de pirater le chèque juste pour avoir un mot de passe plus facile à retenir. Je ne sais pas dans quelle mesure ce cas est probable.

Je sais que vous ne pouvez pas appliquer un mot de passe fort du côté client et que si vous devez avoir un mot de passe fort en toute circonstance, vous devez le faire côté serveur.

Mon point est: étant donné que, pour avoir une expérience utilisateur acceptable, nous devons faire la vérification côté client, il doit y avoir une bonne raison, un cas d'utilisation réel qui crée une éventuelle vulnérabilité pour justifier une duplication de la vérification côté serveur.

À la lecture des réponses, jusqu'à présent, il semble que le seul cas d'utilisation qui puisse créer une vulnérabilité soit lorsque le javascript ne fonctionne pas. Cela ne me semble pas un problème car le bouton d'envoi est désactivé par défaut.

Vous pouvez toujours demander des éclaircissements à ces entreprises.Demandez-leur un scénario d'attaque.Je suppose que c'est une erreur de leur part.
Si vous avez les mêmes exigences à la fois à l'avant et à l'arrière, il n'y a aucune confusion pour vos utilisateurs et aucune confusion dans votre système.
Je pense que ce n'est pas une duplication de l'autre question car elle pose quelque chose de plus précis.Je connaissais déjà les réponses données à cette question.Je savais que vous ne pouvez pas appliquer une force de mot de passe côté client, mais je voulais savoir dans quelles circonstances cela peut être une faille de sécurité.
Une considération qui pourrait vous aider est s'il est possible d'exécuter le même code côté client que côté serveur, ou d'utiliser un cadre dans lequel vous créez la spécification de validation une fois dans une langue, et elle est émise au client via untransformation.Par exemple, le JavaScript côté client pour effectuer la vérification de la force peut être exécuté à l'aide de Node côté serveur.Ensuite, vous réduisez votre charge de codage et vous vous assurez que les implémentations sont identiques pour éviter des problèmes étranges tels que des utilisateurs qui obtiennent des erreurs qu'ils ne savent pas comment corriger.Enfin, assurez-vous de tester votre javascript!
"Pourquoi une vérification du mot de passe côté client n'est-elle pas considérée comme sécurisée?"-> "Pourquoi une vérification du mot de passe ** force ** côté client n'est-elle pas considérée comme sécurisée?"
Soyez très prudent lorsque vous ajoutez des vérifications de mot de passe «fortes».Les mots de passe les moins sécurisés que j'utilise sont ceux pour lesquels j'ai dû modifier le mot de passe pour passer une série de règles.Les plus sûrs sont ceux où j'ai dit à un générateur de mot de passe "20 caractères: n'importe quel mélange de lettres, de chiffres et de caractères spéciaux" et utilisé le résultat directement.
Une partie de la réponse dépend de ce que vous * faites * avec un mot de passe faible.Le rejetez-vous?Prévenez-vous l'utilisateur et laissez-vous le configurer quand même?
Huit réponses:
Teun Vink
2017-04-27 13:28:39 UTC
view on stackexchange narkive permalink

Vous supposez que la vérification est volontairement contournée. Il se peut que quelqu'un utilise un navigateur qui ne gère pas correctement le script ou avec des scripts désactivés, peut-être même sans le savoir.

Vous semblez avoir une raison pour que les gens utilisent des mots de passe forts. Si vous le faites, pourquoi accepter que les gens puissent le contourner?

La validation côté client peut être utile du point de vue de la convivialité, mais si vous décidez qu'une force minimale de mot de passe est requise, vous devriez l'appliquer en implémentant il côté serveur.

Exactement.S'il est davantage utilisé comme ligne directrice, mais n'est pas strictement nécessaire, le faire sur le client est très bien.Pour mon site Web, je "demande" aux utilisateurs d'avoir un mot de passe de plus de 5 caractères, qui ne doivent pas tous être des chiffres (date de naissance ...).Mais si le contrôle n'est pas exécuté pour une raison quelconque, le serveur l'accepte parfaitement.À moins que vous ne gériez des données sensibles, cela devrait être parfait.
D'ACCORD.Dans mon cas, si le javascript ne fonctionne pas, le bouton d'envoi ne sera pas activé.
@MarcoAltieri, il est trivial de bloquer vos scripts mais utilisez toujours javascript pour activer le bouton d'envoi.Quelqu'un peut également publier manuellement sur la cible de votre formulaire.
@MarcoAltieri, une règle de base que j'utilise est de supposer qu'un utilisateur suffisamment malveillant / incompétent n'utilise tout simplement pas de navigateur, et tout ce qu'il fera est d'envoyer des requêtes HTTP directement à mon backend indépendamment de ce que je tente de lui dire de faire.
Pour indiquer à quel point la suggestion d'@fhl's est triviale - * Je l'ai fait, et je n'écris pas de js, ni de code pour le Web de quelque manière que ce soit *.J'ai utilisé des commentaires sélectifs de js dans un navigateur (une validation cassée qui ne passerait jamais) et j'ai écrit un script python pour soumettre un formulaire sans navigateur (pour ma commodité - un écran de portail wifi fastidieux).
@fhl La question est: pourquoi quelqu'un le ferait-il?Juste pour définir un mot de passe faible?Il serait plus facile pour cette personne d'écrire un mot de passe fort, puis de l'écrire sur un post-it, comme quelqu'un l'a déjà souligné.
Le problème est plus important que la simple définition d'un mot de passe faible.Le vrai problème est que la validation côté client doit être supposée ne pas être effectuée.Vous avez sûrement entendu parler de l'injection SQL?Et s'ils définissent un mot de passe vide?Et si c'est si long qu'il déborde de votre base de données, permettant l'injection de code?Et si vous n'attendez que des ascii et qu'ils envoient un unicode en désordre?
@ftl Bien sûr, il existe des vérifications pour d'autres vulnérabilités de sécurité dans mon application et elles sont côté serveur.Les pentesters n'ont pas trouvé d'autres problèmes, seulement la vérification des mots de passe forts.
@MarcoAltieri Je pourrais contourner cette vérification soit parce qu'il est trop difficile de créer un mot de passe qui correspond aux critères de mot de passe fort, soit parce que je veux un mot de passe simple pour pouvoir me connecter plus rapidement, ou parce que je veux utiliser le même mot de passe partout.
@MarcoAltieri Je suis d'accord qu'il n'est pas faux de laisser les utilisateurs contourner les vérifications de complexité de votre phrase de passe en principe (parce que `Mon chemin est trop long pour être de manière réaliste une phrase de passe d'exemple qui est totalement plus sécurisée que 123456` échoue presque tous les contrôles naïfs de validation de la complexité de la phrase de passe que j'aijamais vu, et pourtant c'est bien meilleur que `abc123! @ #` qui passe presque toutes les vérifications de complexité de phrase de passe que j'ai vues).Mais, pour votre site spécifique, qu'est-ce qui compte le plus: permettre un contournement éclairé prudent, ou guider l'ignorant ou le négligent dont le navigateur ne fait pas la validation comme prévu?
@mtraceur il est impossible que le mot de passe soit affiché si le JavaScript n'est pas activé ou ne fonctionne pas.
@MarcoAltieri Je ne suis pas sûr de comprendre.Je suppose que vous voulez dire que votre page Web est implémentée d'une manière qui utilise JavaScript pour la publication du mot de passe, et n'a aucune dégradation gracieuse à une soumission de formulaire HTML simple via HTTP POST?Même si tel est le cas, est-ce que tous les interpréteurs JavaScript actuels et futurs fonctionneront correctement?Ce n'est pas un problème de sécurité à ce stade, mais si la future version hypothétique de Firefox 99 ou quoi que ce soit d'autre casse sur un cas particulier de coin de sorte que votre validation manque l'un de vos critères de phrase de passe mais fonctionne bien autrement, voulez-vous que votre serveur vous aide à détecter l'erreur?
Serge Ballesta
2017-04-27 14:55:09 UTC
view on stackexchange narkive permalink

La règle lors de l'écriture d'une application serveur est simplement de ne jamais faire confiance à ce qui vient du client . Les vérifications effectuées côté client sont excellentes car elles permettent une expérience utilisateur agréable avec de belles fenêtres contextuelles et un affichage immédiat. Mais comme tout peut arriver, d'un navigateur javascript désactivé à un utilisateur utilisant un langage de script pour simuler un navigateur, toutes les vérifications doivent être effectuées (à nouveau) côté serveur.

Si les mots de passe forts sont simplement recommandés, faites ce qui vous voulez, si elles sont une exigence, vous devez implémenter une vérification côté serveur.

BTW: vous en tant que développeur pouvez proposer des solutions, mais le client exprime des exigences. Si vous n'êtes pas d'accord avec eux, vous pouvez demander des éclaircissements et proposer d'autres moyens, mais à la fin, le client décidera.

nebulak
2017-04-27 13:19:43 UTC
view on stackexchange narkive permalink

Si l'utilisateur DOIT définir un mot de passe fort, vérifier la force du mot de passe uniquement du côté client est une vulnérabilité.

Exemple

Si vous travaillez dans une grande entreprise et que vous avez pour changer votre mot de passe tous les 2 ou 3 mois, quelques personnes commenceront à contourner la vérification côté client de la force du mot de passe pour utiliser des mots de passe plus courts ou meilleurs pour mémoriser les mots de passe. pour le chiffrement multi-utilisateur des fichiers, cela devient horrible ...

Solution

Vérifiez toujours la force du mot de passe sur le serveur et éventuellement vérifier la force du mot de passe chez le client pour diminuer les requêtes à le serveur.

Bibliothèque recommandée: ZXCVBN

  • Utilise la correspondance de modèle et vérifie les mots de passe les plus utilisés pour estimer la force du mot de passe.
  • Est disponible dans plusieurs langues de programmation
Êtes-vous en train de dire qu'il y aura des utilisateurs qui prendront vraiment le temps de pirater le chèque juste pour définir un mot de passe faible?Cela me semble si peu probable.Au fait, j'aime la bibliothèque que vous avez liée!
Je ne sais pas à quel point cette vulnérabilité est critique pour votre application.Mais vérifier la force du mot de passe sur le serveur est la meilleure pratique et cela ne devrait pas être trop de travail à mettre en œuvre.
Mes deux cents: vérifier la force du mot de passe sur le client est une fonctionnalité UX, pas une fonction de sécurité.Ne faites jamais confiance au client, donc la même vérification doit être effectuée sur le serveur indépendamment
Ne validez jamais rien sur le client!Jamais!Vous pouvez ** en plus ** vérifier l'entrée sur le client pour une convivialité accrue, mais vous devez toujours la valider sur le serveur. Le client appartient à l'utilisateur, donc la validation uniquement du client équivaut à aucune validation, mais simplement à dire aux utilisateurs qu'ils doivent utiliser un mot de passe fort.Je me demande comment cela fonctionnerait?
@MarcoAltieri le tout "vous devez définir un nouveau mot de passe dont vous avez peu de chances de vous souvenir" pourrait être conçu pour inciter vos utilisateurs à rechercher des solutions de contournement.Ou post-it.Surtout si * leur perception * est que ce sont des tracas inutiles.
@MarcoAltieri certains utilisateurs experts pourraient en effet passer leur temps à contourner les contrôles qu'ils jugent inutiles.J'ai tout un tas de scripts côté client (bookmarklets) qui m'aident à naviguer plus facilement dans les pages, ou à remplir des formulaires de connexion pour les démos client.
@Zefiro mais parce que vous êtes un expert, vous n'utiliserez pas ces scripts pour définir un mot de passe faible sur un compte réel.
@MarcoAltieri Je le ferai.J'ai un mot de passe "standard" qui est très faible que j'utilise sur tous les comptes qui n'ont aucune valeur réelle pour moi.(Vous devez vous inscrire pour voir cette image et autres).Si votre compte entre dans cette catégorie et qu'il est possible d'ignorer votre chèque pour utiliser ce mot de passe, je le ferai!En outre, c'est très amusant.
Je pourrais, et je voudrais peut-être, peut-être juste pour le plaisir de montrer ce que je pense de règles stupides pour des comptes que je n'apprécie pas beaucoup, et je veux utiliser mon mot de passe «dragon» partout.Donc, la décision pour vous est la suivante: encourager les bons mots de passe ou les appliquer?Si ce dernier vous n'avez pas d'autre choix qu'une seconde vérification sur le serveur.
Stevoisiak
2017-04-27 20:26:21 UTC
view on stackexchange narkive permalink

Sur la base de la réponse de Teun Vink, il existe quelques scénarios du monde réel où un utilisateur peut accidentellement contourner le contrôle de sécurité.

Supposons qu'un utilisateur télécharge un bloqueur de publicités comme Adblock Plus ou uBlock Origin . Ensuite, en raison de la mauvaise configuration des scripts, l'un de ces adblockers bloque accidentellement le script que vous utilisiez pour vérifier la sécurité du mot de passe. Désormais, l'utilisateur peut saisir 1234 comme mot de passe sans qu'aucune vérification côté serveur ne soit en place pour l'empêcher.

Ou peut-être que la mise en cache locale a donné le utilisez une ancienne version de votre script. Peut-être ont-ils enregistré votre page Web en tant que fichier HTML statique sur leur bureau. Peut-être que le PC de l'utilisateur a un virus qui a modifié le contenu de votre script. Comme le dit le dicton commun ...

Ne faites jamais confiance à l'utilisateur.

Modifier: Voir aussi " Impossible d'enregistrer le profil lorsque maps.googleapis.com est bloqué" pour un excellent exemple des raisons pour lesquelles vous ne devriez jamais faire confiance à l'utilisateur.

Si le javascript est bloqué, le bouton d'envoi ne sera pas activé car il est désactivé par défaut.
@MarcoAltieri Adblock ne fonctionne pas en bloquant JavaScript dans son intégralité.Cela fonctionne en bloquant *** des scripts spécifiques *** tels que définis par l'utilisateur.
Il semble peu probable que l'adblock soit capable d'exécuter sélectivement des parties de mon script finissant par activer le bouton même si la vérification n'a pas été exécutée.Tout est dans le même script.
@MarcoAltieri Je suis d'accord.Le scénario que j'ai décrit est très improbable.En fait, *** improbable *** est le mot clé ici.Lorsque vous envisagez la sécurité, s'il y a un risque que quelque chose se produise, même si cela est extrêmement improbable, vous voulez généralement vous assurer que votre système est prêt si cela se produit.
Mais l'utilisation de ressources Google dans votre page n'est-elle pas une mauvaise pratique de toute façon?
@wannabeLearner - Pas si vous utilisez [l'intégrité des sous-ressources] (https://en.wikipedia.org/wiki/Subresource_Integrity)
@paj28 oui cela le rendrait sûr.Mais s'il y a un blocage en place dans votre pays contre les services appartenant à Google, cela n'endommagerait-il pas encore les choses?
@wannabeLearner - Je m'attendrais à ce que les bibliothèques hébergées par Google soient traitées différemment des services Google, mais je ne suis pas sûr.Vous pouvez poser une nouvelle question à ce sujet
@paj28 ils le sont.Même SE est difficile à utiliser dans des pays comme la Chine (en référence à une expérience passée que j'avais peut-être déjà corrigée)
Je voulais dire qu'ils ne sont * pas * traités de la même manière
user3742898
2017-04-28 00:01:28 UTC
view on stackexchange narkive permalink

Vous mentionnez que la vérification & et l'activation du bouton d'envoi sont un seul script, donc c'est sûr même si certains scripts sont chargés et d'autres non. Dans quelle mesure êtes-vous sûr que ces deux fonctions seront toujours dans le même script?

Je suppose que ce que je dis, c'est que cela ressemble à, dans l'état actuel des choses, signifierait que quelqu'un fait intentionnellement quelque chose qu'il sait être une mauvaise idée pour qu'il obtienne un mauvais mot de passe, et cela vous convient; vous essayez d'éviter les accidents, pas la stupidité intentionnelle.

Ce qui m'inquiète, c'est que si ce script est un jour refactorisé, & se sépare, ou la stupidité intentionnelle devient votre problème, ou un attaquant écrit un côté client script ostensiblement pour aider les gens, ... alors vous avez des ennuis.

rackandboneman
2017-04-28 01:29:54 UTC
view on stackexchange narkive permalink

Un problème possible est qu'il suffit d'un seul sage (qui peut être suffisamment informé pour utiliser cette technique pour utiliser un mot de passe qui échoue au vérificateur et qui est néanmoins sécurisé!) pour trouver un moyen de le pirater - et de distribuer le hack à quelques autres personnes (qu'il / elle juge probablement suffisamment responsables) qui finiront par le donner à des personnes contre lesquelles la solution était censée protéger le manque de compétences en matière de sécurité.

Cela semble un cas réel qui peut créer une vulnérabilité.Merci
njzk2
2017-04-27 19:54:04 UTC
view on stackexchange narkive permalink

Appliquer des règles sur le serveur

Quelles que soient les règles que vous définissez, elles doivent être appliquées au niveau du serveur dans tous les cas. Ceci est vrai pour la configuration du mot de passe, et pour les champs obligatoires dans les formulaires par exemple (par exemple, si un numéro de téléphone est requis lors de l'inscription, il doit être vérifié sur le serveur).

Aidez votre utilisateur sur le client

Quelles que soient les règles que vous appliquez sur le serveur, vous devriez aider votre utilisateur autant que possible en donnant de l'aide sur le client.

Cela peut être juste une explication, étoiles à côté des champs obligatoires, indiquant les erreurs avant de soumettre les formulaires, ...

Mais appliquer les règles sur le serveur

Mais dans tous les cas, vous ne pouvez pas du tout compter sur le client. Certaines personnes bloqueront JS. Certaines personnes bloqueront le flash. À un moment donné, vous pouvez ouvrir votre API à des tiers, qui peuvent ou non appliquer vos règles à votre place.

Pour ma part, j'ai parfois réactivé des boutons bloqués par JS parce que j'ai trouvé ce client -les règles appliquées étaient ridicules (par exemple, votre mot de passe doit contenir exactement 8 caractères, dont exactement 1 lettre majuscule, 1 chiffre et 1 caractère spécial dans (! @ # $% & *?) uniquement), en espérant que le serveur ne les applique pas règles (ce qui souvent non).

Si vos spécifications doivent avoir un ensemble précis de règles sur le mot de passe de vos utilisateurs, alors avoir la validation côté client ne répond pas aux spécifications.

paj28
2017-04-27 23:21:38 UTC
view on stackexchange narkive permalink

Je m'attends à ce que la firme de test de stylos applique un principe général ici "faire toute la validation côté serveur" sans considérer le cas spécifique en détail.

Dans votre scénario, où JavaScript ne peut pas être désactivé, je voir aucun risque de sécurité pratique. Il peut y avoir un risque non technique si vous avez besoin de mots de passe complexes pour une exigence réglementaire (par exemple PCI-DSS).



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...