Pourquoi l’utilisateur et le mot de passe sur deux pages différentes ?

Cet article a été publié il y a 4 ans 5 mois 8 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Avec la multitude de services auxquels on doit se connecter en permanence, vous avez sûrement remarqué que certains sites proposent de saisir l’utilisateur (ou l’adresse e-mail) et le mot de passe sur deux pages différentes. C’est parfois fluide, parfois pénible, et je suis tombé sur un article en anglais qui met en lumière les réflexions derrière cette technique. Une traduction, ça faisait longtemps n’est-ce pas ?

L’article original a été posté sur le blog de Twilio, un service proposant des API pour construire des applications de communications (très très résumé).

La raison la plus courante pour demander l’utilisateur et le mot de passe sur deux pages différentes est de pouvoir supporter à la fois :

1. Le Single-Sign On, aka SSO (par exemple, « se connecter avec Google », ou un autre service comme Okta)
2. Le login classique utilisateur/mot de passe

Cependant, ce flux de login embrouille les gens ce qui est probablement la raison pour laquelle vous lisez ceci ! Les sites Web présentent habituellement les champs utilisateur et mot de passe sur la même vue pour l’authentification. Donc vous n’êtes pas seuls si vous vous êtes déjà demandé pourquoi le champ du mot de passe manque ou est sur une autre page.

Cet article jette un oeil à la sécurité associée à cette décision concernant cette conception et propose quelques options pour concevoir des formulaires de connexion qui supportent plusieurs méthodes d’authentification.

Est-ce que séparer les champs utilisateur et mot de passe sur deux pages différentes est plus sécurisé ?

La séparation pourrait rendre les attaques « credential stuffing » (NdT : attaque voisine du brute-force, qui se concentre sur les dictionnaires d’identifiants fuités provenant d’attaques différentes) plus compliquées. Ça permet également à la plateforme de vérifier certaines conditions de sécurité. Par exemple, le site peut vérifier si le compte a activé l’authentification à deux facteurs, et sinon, demander de valider un CAPTCHA. La conception sur deux pages permet également de rendre plus difficile la création de sites de phishing avec des pages qui se ressemblent quand ça implique une redirection. Mais l’étape supplémentaire n’est probablement pas nécessaire à moins d’être dans un cas d’usage de SSO.

Il y a quelques discutions excellentes sur le sujet sur dev.to et Security Stack Exchange si vous voulez en savoir plus.

Options pour prendre en charge l’authentification à la fois SSO et utilisateur/mot de passe

1. Pages séparées pour les deux champs

Ce design fournit un chemin clair à suivre pour l’utilisateur dans les deux cas. L’étape de vérification de l’e-mail et l’action distincte (‘Next’) peut aussi simplifier le code de l’implémentation sous le capot. La séparation permet également les vérifications conditionnelles évoquées plus tôt.

Aujourd’hui, des sites comme Shopify, Yahoo, Google, Twilio font tous ça. Le bémol, c’est que les gens l’ont remarqué et se sont plaints. Également, ce flux n’est pas très pratique pour les gestionnaires de mots de passe et leur fonction d’auto-remplissage, mais les plus répandus (LastPass, 1Password) se sont adaptés.

2. Vérification sur une seule page

Des sites comme Dropbox et Segment proposent une belle interface pour ça. Un des ingénieurs de Segment m’a montré comment ça fonctionne. Si vous allez sur https://app.segment.com/ et entrez foobar@segment.com une option pour utiliser le SSO apparaîtra. Ca vérifiera le domaine de l’adresse e-mail et vérifier si l’organisation utilise le SSO avec Segment. C’est similaire à l’option 1 mais sans impliquer deux vues séparées. Cette option met d’abord l’accent sur l’authentification utilisateur/mot de passe, et peut fonctionner mieux avec les gestionnaires de mots de passe, mais ça demande une gestion via Javascript qui peut être capricieuse.

3. Champ de mot de passe optionnel

Une autre option est de rendre le champ du mot de passe optionnel. Hackerone, une plateforme de « bug bounty », procède ainsi sur son formulaire de login. Ca simplifie la page, ne nécessite pas la vérification du domaine, mais ça peut être malhabile/peu pratique pour les utilisateurs de SAML.

Montrer les deux champs sur une seule page permet aussi d’inclure d’autres méthodes d’authentification comme celles via les comptes de réseaux sociaux. Des sites comme Pinterest et Twitch proposent de telles options.

Comment concevoir le formulaire d’authentification parfait

Brad Frost a d’excellents conseils qui valent la peine d’être débattus dans son article « Ne soyez pas astucieux avec les formulaires de mots de passe« . Vous pouvez suivre la discussion sur Hacker News pour voir également d’autres idées. Évidemment les utilisateurs et mots de passe ne sont pas les seuls éléments à considérer sur un écran d’authentification. Vous pouvez renforcer la sécurité de votre flux avec l’authentification à deux facteurs de Twilio ou via la vérification du numéro de téléphone (NdT : ce que propose Twitter par exemple).

Est-ce que votre entreprise a résolu le problème d’une manière différente ? Où y a-t-il une autre raison pour séparer les pages utilisateur et mot de passe que je n’ai pas mentionné ? Dites le moi sur Twitter @kelleyrobinson ou allez voir la discussion sur cet article sur Hacker News.