OK, ça répond plutôt pas mal à ma question, merci beaucoup.

Les seuls cas « vitaux » sont les cas où le services est :
- Un point d'entrée vers d'autres (mail, réseaux sociaux…)
- Lié à des données personnelles (on voit bien l'étendu et la complexité avec le RGPD, par exemple)
- Troué et par conséquent le mot de passe ne suffit plus (c'est des buts du 2FA, par exemple)
Cela fait tout de même pas mal de cas où elle est nécessaire voire indispensable (à la discrétion des créateurs dudit site).

Comme déjà dit : le mécanisme peut être un envoi de mail/SMS, une 2FA, une notification sur les autres équipements connectés…

Ça se tient, en l'état elle est candidate et je n'ai pas non plus envie de la passer en recommandation.
Cela dit, je voudrais qu'on aille plus loin et j'ai besoin de toi. Je t'explique mon souci : tu l'as bien compris, on risque d’interpréter ça comme un truc systématique à faire.
Dans le cas de la 160, on sait dire "ne la faites pas si le site n'a qu'une seule page."
Dans le cas de celle-ci, j'aimerais que tu m'aides à déterminer s'il y a des cas où elle est vitale, et lesquels. J'ai envie de la garder en BP, mais j'aimerais qu'elle soit à l'épreuve des balles.

Tout dépend de la mise en place, ça peut être du 2FA (sous une forme ou une autre), comme le proposait Bertrand Matge l'envoi d'un message lors d'une nouvelle connexion. De très nombreux CMS le proposent (ainsi que de nombreux sites, applis web…).
Concernant "la valeur ajouté pour l'utilisateur", voir point précédent : si de nombreuses entitées l'ont mise en place, c'est un réel ancrage. Libre au site de le mettre en place ou non, en connaissance de cause, et à l'utilisateur de l'activer envie. Il ne s'agit pas de l'imposer (comme il n'est pas utile de respecter la "160 - Le site propose un moteur de recherche interne" sur tous les sites, un site ayant une seule page n'en a pas utilité), mais simplement de favoriser cette bonne pratique.







Si ce ne peut être une bonne pratique, alors recommandation, et on l'envisagera peut-être dans 5ans.

Et après relecture, pour l'instant, c'est la seule règle de toute la liste pour laquelle j'ai encore des doutes.

Je continue à avoir de gros doutes sur deux choses :
- La faisabilité par toute entité Web (exemple : à exiger a priori sur tout site web demandant une aithentification, et par extension TOUS LES CMS.
- La valeur ajoutée pour tous les sites.

Sémantiquement ça ne "prévient" pas, donc non. Cependant, cela peut être un premier pas, en effet, qui pourrait être activé ou non par l'utilisateur

Est-ce que le simple fait fait d'envoyer une notification de connexion à un utilisateur est considéré comme un "mécanisme de prévention" (ça n'empêche pas l'acte malveillant en soi, mais ça permet à l'utilisateur d'en être averti ; ce qui est déjà un premier pas) ?

Je ne suis pas pour le fait de précision la solution ou le lieu de mise en place dans le libellé. Par expérience, ça nous est à peu près toujours retombé sur la figure. On pourra le dire dans la fiche. Je trouve ma formulation pas mal, mais je continue à pnser que ça risque d'être overkill dans plein de cas. Il va falloir continuer à farfouiller, je pense que c'est une des cas les plus complexes qu'on va avoir à traiter sur cette nouvelle version.

Assez vague, peut-être rajouter {Le site propose un mécanisme de prévention des usurpations de compte ou d'identité lors de la connexion} (rajouter "connexion" ce qui cible le lieu pour la mise en place)

Reformulation de ma part :
{Le site propose un mécanisme de prévention des usurpations de compte ou d'identité}
J'ai mis de compte ou d'identité pour que mes camarades puissent jouer avec le libellé, il faudra sans doute choisir.

SI vous le voulez bien, je préférerais qu'à ce stade, la discussion ne soit pas orientée sur "je la veux comme bonne pratique" ou "je ne la veux pas comme bonne pratique", mais plutôt comment la formuler de façon parfaite, il sera ensuite largement temps de décider si on veut la placer en bonne pratique (universelle, vérifiable, réaliste - faisable sur tous les sites (!). On en est très loin, mais on va voir plus tard. Déjà, travaillons sur une formulation propre et ON Y EST PAS ;)

Il y a eu quelques échanges sur twitter car le sujet est passionnant.
https://twitter.com/ffoodd_fr/status/1207271888902348800

Après ces échanges, je suis arrivé à la conclusion que la valeur ajoutée était de prévenir les usurpations d'identité ou de compte.

Je propose donc de faire évoluer le libellé {Le site propose un mécanisme de prévention des usurpations de compte}

"si tu laisses uniquement ton mail en guise de compte (voire pas de mail mais un pseudonyme associé à un mot de passe, par exemple), une authentification forte n’a aucun intérêt" → pourquoi "aucun intérêt" ? On ne laisse pas plus pour s'authentifier à un compte de messagerie instantanée, mail ou réseau social. À quels cas cela s'appliquerait-il alors ?


Je le rappelle c'est bien "propose" et non "impose", libre à l'utilisateur de ne pas le mettre en place pour son compte, mais au site de le proposer (et peut aussi ne pas être mis en place, c'est une BP par une obligation)

Je plus-ise le "authentification à facteur multiples" :)

Le rapprochement portait uniquement sur la formulation ;)

Et si tu parcoures les échanges cités, il y a une notion de criticité sur les données personnelles : si tu laisses uniquement ton mail en guise de compte (voire pas de mail mais un pseudonyme associé à un mot de passe, par exemple), une authentification forte n’a aucun intérêt et peut même sérieusement freiner un projet pour lequel cette authentification forte serait une charge démesurée — et gêner l’utilisateur final avec une procédure de connexion complexe pour un intérêt perçu minime voire inexistant.

Un cas pratique : un framapad ou framadate dont l’accès est restreint uniquement par un unique mot de passe (le même pour tout le monde). On est bien devant une forme d’authentification, mais une authentification forte paraît absurde, non ?

La connexion est nécessairement basée sur de la "donnée personnelle", donc c'est lié à tous les sites nécessitant une connexion… je ne vois pas où est la nuance ici, la formulation (indépendamment de "double authentification" peut-être trop restrictive) est claire sur ce point.

Pour le rapprochement à la BP 199 : ce n'est absolument pas de cela qu'i lest question ici, ça n'est pas une confirmation de création de compte, mais une sécurité plus forte pour la connexion.

Cependant : +1 pour ta formulation, si la fiche descriptive inclut plusieurs exemples (2FA avec appli, SMS, mail ou autre…).

En écho aux commentaires ici, et à ceux reçus sur Twitter (https://twitter.com/ffoodd_fr/status/1207271888902348800), je constate que la nuance apportée majoritairement est que ce n’est pas universel : ça ne concerne que les projets dont la valeur ajoutée repose sur des données personnelles — y compris les publications personnelles, comme les réseaux sociaux.

Je ne sais pas encore traiter ça, en revanche pour la formulation orientée bénéfice utilisateur, je crois qu’on devrait la rapprocher de la BP 199 : « La création d’un compte est soumise à un processus de confirmation ».

Ce qui donnerait, ici : « L’authentification à un compte est soumise à un processus de confirmation. »

Cela me paraît pouvoir inclure le 2FA et toutes les autres technologies d’authentification forte. En revanche, il manque toujours le point de bascule qui rend cette BP applicable ou non…

Comme dit dans l'intitulé initial (et dans les diverses proposition suggérées) c'est bien "propose" et non pas "met en place" ou "impose", libre à chaque utilisateur de le mettre en place pour ellui-même ou non.

Peut-être "tout simplement", ce qui était évoqué plus haut : "le site propose un mécanisme d'authentification forte de la connexion" ce qui peut être 2FA ou tout autre chose.

Concernant la "Web Crypto API" c'est une API Javascript pour faire de la crypto vers un serveur, ça n'a pas vocation (actuellement) à faire ce que 2FA propose.
On a sensiblement le même débat à avoir avec la notion de mots de passe, que le W3C veut virer à terme (voir : passwordless & fido)

Je suis plutôt d'avis d'adopter le terme authentification forte ou authentification à facteur multiples que double connexion.
Ensuite, l'intérêt est bien réel sur beaucoup de sites, mais vraiment inutile et très chiant sur d'autres. je veux évidement que mes données bancaires soient sécurisées, que certaines autres aussi. Mais je trouve ça beaucoup plus complexe et moins accessible qu'une simple connexion sécurisée. Je serais d'avis de proposer une authentification forte mais pas de l'imposer . (Sauf sur des sites aux données critiques ?)

Clairement, dans une boite comme Proton Mail, la double authentification est obligatoire : c'est p-e moins souple dans certains cas (et encore), mais ça ajoute une couche supplémentaire de vérification. Et dans l'absolu, je me dis que c'est une très bonne pratique de sécurité.
+1 pour double authentification/authentification forte ^^

Merci @Gaël. C'est super intéressant. Je crois vraiment qu'il faut arriver à trouver ce à quoi servent ces trois approches.
Double facteur, 3D secure, Webcrypto. Qu'est-ce qu'on veut faire avec ça ?
Il faut qu'on trouve une formulation qui ne fait pas référence à une technologie et qui montre bien la différence avec HTTPS par exemple.

Sur cette reformulation, je dirais non : « un mécanisme de sécurisation » est trop vague. HTTPS en est un, par exemple.
En revanche quitte à reformuler pour s’abstraire de la mise en œuvre à deux facteurs, que diriez-vous de parler d’authentification forte ?

Comme Élie, je pense que le double-facteur ne tiendra pas cinq ans (et sera même carrément obsolète) — comme peut le devenir actuellement 3D Secure (remplacé par un double-facteur via application sur mobile, par exemple).

Et j’invite à la table les élucubrations de Matthias Dugué (@M4dz) et ses pérégrinations sur la WebCrypto API — depuis deux ans déjà une recommandation du W3C : https://www.w3.org/TR/WebCryptoAPI/ — qui permettent par exemple de conserver une clé privée sur l’appareil de l’utilisateur. Ce n’est pas un deuxième facteur à proprement parler mais un renforcement, c’est un standard qui va s’épanouir dans les années à venir car poussé par les gros du web via le W3C (l’éditeur de la spéc travaille pour Netflix, et la plupart des gens impliqués pour des banques…) et qui va, à mon humble avis, complètement effacer à terme le besoin initial d’un double-facteur comme actuellement.

My two cents, comme disent les jeunes :)

Sinon, j'ai une idée :
{Le site propose un mécanisme de sécurisation de la connexion}.

Comme ça, ça reste ouvert.

C'est exact, il y a eu des paris, CSP en était un, et nous pourrions le refaire pour cette approche.

Il y a quand même deux grosses différences :
1 CSP ne peut pas vraiment nuire à l'UX alors, que si on préconise systématiquement la double authentification ça risque d'être nuisible dans certains cas
2 J'ai de gros doutes sur le fait que cette approche tiennent pendant cinq ans.

Pour l'instant je vous propose d'attendre de voir s'il y a consensus, je vais demander quelques avis sur le slack Opquast et on avise.

C'est pourtant ce qui est fait avec la BP 205, sur les CSP : c'est de la sécurité, ça signifie que Opquast recommande la mise en place des CSP (qui sont en v1 dans la fiche). La BP 193 recommande l'utilisation de HTTPS (dans la fiche). Les articles sur le sujet ne manquent pas en ligne, un certains nombre de sites l'utilisent (voir : https://twofactorauth.org )

En l'état, je ne suis pas encore fan de la formulation. En fait, c'est une mesure de sécurité. Cela signifierait qu'Opquast recommande la mise en place d'une authentification à double facteur pour tout mécanisme de connexion. On peut le recommander, mais je pense qu'on est très loin d'avoir un consensus sur le fait de le faire systématiquement. De plus ce n'est pas la seule solution pour renforcer la sécurité...Pour finir, tiendra t-elle 5 ans.
Cela me semble risqué de l'intégrer en l'état. En revanche, si on arrive à dire dans quel cas elle est valable et la reformuler correctement, pourquoi pas.

C'est réaliste pour tous les services/sites nécessitant la connexion à un espace personnel, il n'est pas spécifique à la gestion de données bancaires. Les réseaux sociaux propose ce mécanisme, Githuh/Gitlab et autre gestionnaires de versions aussi, les sites bancaires peuvent envoyer un SMS (fait l'objet d'une deuxième proposition en commentaire).
Il est possible de le mettre en place partout, libre à l'utilisateur de s'en servir ou non.

oui, il faudra juste bien expliquer "propose" dans la fiche de la BP. Après, je suis casse-pied, mais est-ce réaliste pour tous les services en ligne ? Ou gagnerait-on à cibler plus précisément ? (je cherche comment, du côté de l'usage de données bancaires en particulier)

C'est "proposé", ça n'impose ni son utilisation pour l'utilisateur, ni celle côté créateur. De nombreux sites et applicatifs web le mettent, de plus en plus, à disposition.

C'est de plus: vérifiable, valable sur le plan international, valeur ajouté de sécurisation pour l'utilisateur le voulant, il est raisonnablement faisable de le mettre en place, fait déjà consensus (voir point précédent).

Rah, il veut perdre ma grand-mère qui a déjà du mal avec son smartphone (je sors)

Si la proposition est retenue, une deuxième peut lui emboiter le pas "La double authentification est possible par recours à une application dédiée" (en opposition à l'envoie d'un SMS, nécessitant une information perosnnelle supplémentaire et inutile)