... qui pourrait être utile dans une attaque mais qui n'est normalement pas disponible pour l'attaquant

La connaissance des caractères d'entrée invalides est utile mais peut facilement être trouvée par l'attaquant avec juste quelques essais. Ainsi, ces informations ne sont pas vraiment secrètes et garder tous les utilisateurs ignorants de ce qui ne va pas ne dissuade pas réellement les attaquants, cela éloigne seulement les utilisateurs innocents car ils ne peuvent pas continuer.

Créer une situation psychologiquement frustrante pour les utilisateurs pourrait les inciter à prendre des décisions moins sûres. Par exemple, ils essaient d'écrire un mot de passe en suédois, mais votre saisie refuse le caractère å sans explication. Au lieu de choisir un bon mot de passe différent sans å , ils lèvent la main et utilisent password123 - un mot qui est facilement vaincu par une attaque par dictionnaire.

Ainsi , vous avez tenté de créer un système "plus sécurisé" par l'obscurité, mais une fois que nous avons pris en compte les comportements des utilisateurs, il est en fait moins sécurisé.

Les caractères valides sont finalement détectables par des moyens systématiques. Les cacher ne vaut pas les dommages que vous pourriez causer aux comportements des utilisateurs.

Pour plus d'informations, reportez-vous à " Sécurité et biais cognitif: exploration du rôle de l'esprit" et " Mesure des incidences sur la sécurité des politiques de mot de passe à l'aide de Cognitive Behavioral Modélisation basée sur les agents "par Sean Smith et al.

Cela dépend.

Si le message décrit une erreur du point de vue des utilisateurs normaux, comme "Le 3ème caractère doit être un chiffre", ce n'est pas une faille de sécurité. Mais afficher l'expression régulière utilisée pour la validation signifie divulguer les détails d'implémentation , ce qui peut être une faiblesse, par ex. certaines bibliothèques utilisent largement les appels récursifs et certaines expressions peuvent provoquer un débordement de pile ou une utilisation élevée de la mémoire et du processeur, ce qui peut conduire à un DoS.

Le CWE-200 définit la divulgation d'informations comme une faiblesse uniquement si l'utilisateur n'est pas explicitement autorisé à accéder à ces informations . Vous envisagez l'entrée de l'utilisateur. Cela signifie que l'utilisateur est autorisé à entrer ces informations et donc autorisé à voir ces informations et naturellement il est autorisé à voir tous les messages d'erreur de validation liés à cette entrée.

Trace de pile ainsi que d'autres messages techniques peuvent fournir des informations sur les technologies utilisées dans l'application (par exemple, quelle version de quelles bibliothèques sont utilisées), sur l'environnement (par exemple, disposition du répertoire et autorisations, type et version du système d'exploitation), etc. Un attaquant peut utiliser ces informations pour choisissez des exploits pour ces technologies, bibliothèques, systèmes d'exploitation, etc. C'est pourquoi la divulgation de telles informations à l'utilisateur est potentiellement une faiblesse.

Ne pas expliquer à l'utilisateur ce qui ne va pas dans sa saisie est définitivement une mauvaise UX, mais pas la sécurité amélioration.

Ne confondez pas cela avec des cas similaires, lorsque les données sont sensibles et que toute validation y relative peut être sensible. Par exemple, si l'utilisateur a entré des lettres dans le champ où vous prévoyez un an, expliquer une telle erreur à l'utilisateur est sûr. Mais si l'utilisateur entre une adresse e-mail et que vous vérifiez si cette adresse est enregistrée dans votre système, alors toute information (l'adresse est connue, l'adresse est inconnue) peut être une faiblesse. C'est pourquoi lorsque vous allez implémenter des messages de validation ou tout autre commentaire concernant les entrées de l'utilisateur, évaluez les conséquences. Mais interdire tout retour par défaut pour tous les champs peut être une mauvaise expérience utilisateur avec un faux sentiment de sécurité.

Ce n'est que l'un des nombreux scénarios où des compromis de sécurité sont attendus en faveur de la convivialité du système.

Cependant, il y a une énorme différence entre l'affichage des traces de pile (mauvaise gestion des erreurs) et nier les caractères attendus ou interdits dans un champ de saisie.

Pour la plupart des scénarios, on peut affirmer que le refus de savoir quels caractères sont attendus ou interdits dans un champ de saisie n'est pas une faille de sécurité du tout, si d'autres mécanismes de sécurité sont en place, comme la limitation des tentatives de mot de passe.

Il peut être déterminé à l'aide d'un cadre de modélisation des menaces qu'il s'agit d'un risque accepté du système.

L'obscurité n'est pas la sécurité. Un bon système est sécurisé même lorsqu'un attaquant en sait tout. Dans votre cas, réduire les estimations de fissuration gaspillées d'un certain pourcentage, disons 25%, ne devrait pas faire ou défaire l'aspect pratique de la fissuration: 1 billion d'années est tout aussi pratique que 0,75 billion d'années. Le fait de ne pas masquer les détails d'implémentation aide également les nouveaux bons à se défendre.

Il y a aussi des considérations sociales. Un signe «BEWARE OF DOG» peut divulguer des détails d'implémentation de sécurité, mais il décourage également une certaine échelle d'attaques courantes. Le chien aide, connu ou inconnu, mais un signe pourrait réduire les coûts d'entretien de la clôture, ce qui libère des ressources pour mener d'autres batailles.

Les autres réponses montrent à quel point le fait de divulguer ceci n'est pas un problème de sécurité.

Je soutiendrai une anecdote vraie selon laquelle ne pas divulguer peut conduire non seulement à frustrer les utilisateurs, mais encore à réduire la sécurité.

Cela m'est arrivé plus d'une fois sur des sites qui n'indiquaient pas clairement les caractères autorisés. À ce moment-là, je n'utilisais pas de générateur de mots de passe, j'avais donc un schéma mental pour me souvenir des mots de passe. Cela impliquait d'utiliser quelques caractères spéciaux comme $ @. & . Quelques tentatives frustrées où tout ce que j'ai obtenu était des "caractères invalides dans le mot de passe" et j'ai progressivement commencé à éliminer les caractères spéciaux. Puis vint "votre mot de passe n'est pas assez sûr, essayez d'ajouter des chiffres et des symboles" ... ouais ... Je suis vraiment détendu à ce stade.

J'ai finalement réussi à accepter mon mot de passe. Ce qui non seulement contenait un seul caractère spécial, mais ne correspondait à aucun de mes schémas de mémorisation des mots de passe, alors j'ai dû ... hmm ... le stocker ailleurs (c'était avant même de connaître les gestionnaires de mots de passe, alors je vais laisser vous imaginez comment je l'ai sécurisé. Je vais vous dire que c'était comme un hélicoptère et comme une ficelle).

Je ne vois pas de problème dans la divulgation du jeu de caractères parmi lesquels l'utilisateur peut choisir, tant que ces règles sont d'une part également appliquées et vérifiées. C'est-à-dire que si l'utilisateur n'est pas autorisé à utiliser \ dans le champ, il ne suffit pas de le vérifier dans l'entrée JS, mais également avant de le saisir, c'est-à-dire dans le DB et lorsque les données sont utilisées. Les règles doivent donc s'appliquer tout le temps (TOCTOU). L'autre partie est qu'il n'y a aucun problème à réduire le jeu de caractères, tant que l'entropie est toujours donnée. Vous pouvez réduire les caractères du mot de passe à "a" et "b", mais vous devez ensuite augmenter la longueur minimale de PW en conséquence (et vérifier qu'ils ne maintiennent pas seulement la touche "a" enfoncée jusqu'à ce qu'elle soit suffisamment longue). Avec un mot de passe assez long (aléatoire), ce serait aussi un mot de passe sécurisé.En fin de compte, tout ce qu'il y a à un caractère sont des bits, et tout le monde sait que ce sont 0 & 1, donc l'alphabet (réel) est toujours connu, comment il y a de nombreux arrangements possibles, à vous de préciser (et de vérifier).