Si un utilisateur laisse son ordinateur sans surveillance pendant quelques minutes (lorsqu'il est connecté), nous ne voulons pas que quelqu'un d'autre puisse passer et changer rapidement son mot de passe. D'une part, cela permettrait à l'attaquant de modifier également l'adresse e-mail associée, et maintenant le propriétaire légitime ne récupère jamais son compte.

Pour une autre chose, pensez simplement au potentiel de fonction des farces!

Changer votre mot de passe est une opération suffisamment sensible pour qu'il soit logique de demander à l'utilisateur de s'authentifier de nouveau. Et comme changer votre mot de passe est une opération relativement rare, cela n'introduit pas beaucoup d'inconvénients pour les utilisateurs: cela ne change l'expérience utilisateur que dans les rares cas où vous changez votre mot de passe.

Outre la motivation de sécurité exprimée par d'autres réponses (car le mot de passe est très sensible et nous ne voulons pas que quelqu'un obtienne un accès transitoire, par exemple un raid à l'heure du déjeuner, pour le transformer en accès permanent), il peut y avoir des problèmes pratiques. Par exemple, dans les systèmes où il existe des secrets d'utilisateur cryptés par mot de passe , l'ancien mot de passe est nécessaire pour déchiffrer ces données et les rechiffrer avec le nouveau mot de passe. C'est exactement ce qui se passe sur les systèmes d'exploitation Windows (c'est l'une des grandes différences avec le modèle de sécurité Unix), et cela peut également s'appliquer à certains systèmes Web (en fonction de ce que fait le système Web).

C'est ce qu'on appelle le principe TOCTOU (Time of Check / Time of Use), ce qui signifie que l ' assurance d'authentification de l'identité de l'utilisateur (c'est-à-dire que l'utilisateur est toujours le même utilisateur qui s'est authentifié sur le système) est trop faible pour lui permettre d'effectuer certaines actions, comme changer le mot de passe ou redéfinir l'identité.

Pour s'assurer que le niveau d'assurance d'authentification est aussi élevé que possible lorsque des actions critiques sont effectuées, le "delta TOCTOU", le temps entre la vérification des informations d'identification et l'utilisation de leur privilège, doit être aussi court que possible pour éviter les problèmes résolus par DW

Pour moi, c'est un exemple évident de compromis ajustable entre sécurité et convivialité.

Une autre raison secondaire pour laquelle l'ancien mot de passe peut être nécessaire est lorsque les mots de passe sont hachés, et vous voulez vérifier que le nouveau mot de passe n'est pas trop similaire à l'ancien, vous devez demander à l'utilisateur, car vous ne pouvez pas obtenir cette information autrement à partir du mot de passe haché.

Comme les réponses ci-dessus l'ont laissé entendre, il s'agit de limiter les dégâts.

Un autre exemple serait si vous aviez simplement implémenté la fonction de réinitialisation du mot de passe en appelant http: //www.example. com / changepassword.php? newpassword = monkey alors je pourrais créer un lien comme ça, le cacher comme un tinyurl ou quelque chose et envoyer quelqu'un que je voulais pirater un tel lien, et s'ils cliquent dessus en étant connecté, je je les ai exclus de leur compte et je l'ai repris.

Si l'application n'utilise pas de jeton CSRF (cross site request forgery), alors le mot de passe peut facilement être mis à jour par un attaquant simplement en envoyant un lien. Et cela sera également très utile si un utilisateur accède à notre session, il ne pourra pas mettre à jour le mot de passe.

Je cherchais une norme, une directive ou au moins un terme reconnu pour la "confirmation d'action sensible". Ce que j'ai trouvé est la section Aide-mémoire pour l'authentification OWASP et Exiger une ré-authentification pour les fonctionnalités sensibles. En résumé, la surface d'attaque ressemble à:

• CSRF
• XSS
• Détournement de session incluant un accès physique temporaire au navigateur d'un utilisateur

Pour les fonctionnalités sensibles nécessitant les informations d'identification actuelles d'un compte (lire le mot de passe actuel dans la plupart des cas) atténue le risque des attaques ci-dessus.

Certains produits et services (voir ci-dessous) vous permettent de définir des ressources sensibles et nécessitent une ré-authentification ou une intensification (l'utilisateur doit fournir un facteur d'authentification supplémentaire).

Notez également que l'application au niveau de l'interface utilisateur n'est pas conseillé. Ici Auth0 a un exemple comment émettre un jeton dédié pour une ressource sensible particulière avec sa bibliothèque cliente.

Référence:

• Configure Re -authentification pour les ressources sensibles (manuel du produit Broadcom SSO)
• Step-up Authentication (Auth0 docs)