Les liens de connexion par e-mail sont-ils une mauvaise pratique?
Dans mon application Spring, je prévoyais de supprimer les mots de passe du processus d'authentification en envoyant un "lien de connexion magique" à l'adresse e-mail d'un utilisateur. Cependant, dans cette question Rob Winch (responsable de Spring Security) dit ce qui suit:
Faites attention de savoir ce que vous faites pour autoriser la connexion à partir d'un lien dans un e-mail. SMTP n'est pas un protocole sécurisé et il est donc généralement mauvais de se fier à quelqu'un ayant un e-mail comme forme d'authentification.
Est-ce vraiment le cas? Si c'est le cas, comment l'envoi d'un lien pour la réinitialisation du mot de passe est-il plus sûr? Se connecter en utilisant un lien magique n'est-il pas la même chose que d'envoyer un lien magique pour réinitialiser un mot de passe?
Un lien magique n'est pas nécessairement mauvais à lui seul. Une valeur entièrement aléatoire de 512 bits ne sera pas plus facile à deviner qu'une clé privée de 512 bits. En général, il est considéré comme une bonne pratique de les expirer après un délai raisonnable. Une bonne approche - qui évite également d'avoir à stocker des entrées de base de données consiste à incorporer les données de jeton dans l'URL et à les signer avec une clé privée. C'est à dire.
site.com/login?type=login&user=[username]&expires=[datetime]&sig=[signature of other parameters].
Cependant, le courrier électronique en tant que mécanisme de transmission n'est pas sécurisé.
Par défaut, SMTP offre très peu de protection contre l'interception. Le trafic peut être crypté entre les serveurs mais il n'y a aucune garantie. Même avec le cryptage, il est souvent possible de maintenir la connexion au milieu (le cryptage n'est pas la même chose que l'authentification).
Si c'est le cas, comment l'envoi d'un lien pour la réinitialisation du mot de passe est-il plus sûr?
Ça ne l'est pas. C'est pourquoi plusieurs services demandent des preuves supplémentaires avant d'envoyer le lien (ou après avoir cliqué dessus).
Il y a trois problèmes ici.
- Comme l'écrit la documentation, le courrier électronique n'est pas un protocole sécurisé. Les e-mails sont stord en texte brut sur les serveurs de messagerie. Le chiffrement entre les serveurs et entre les serveurs et les clients est facultatif et indépendant de votre volonté. Et vous n'êtes probablement pas dans un scénario où vous pouvez utiliser l'un des systèmes de chiffrement de bout en bout optionnels construits sur le dessus des e-mails (PGP, S/MIME, etc.). Vous ne pouvez donc pas garantir que personne, sauf le destinataire prévu, ne verra l'e-mail en texte clair.
- Les secrets n'appartiennent pas aux URL. Les URL apparaissent dans les historiques du navigateur, dans les caches de proxy, dans les journaux du serveur et dans de nombreux autres endroits où vous ne souhaitez pas que des informations secrètes apparaissent.
- Les utilisateurs savent comment fonctionnent les mots de passe. Ce n'était pas facile, mais après une longue lutte, nous avons finalement compris que les mots de passe devaient rester secrets. Avec votre système, les utilisateurs peuvent ne pas savoir quel est le secret pertinent pour l'authentification avec votre service. Cela les rend susceptibles de mal gérer ces informations et vulnérables aux attaques d'ingénierie sociale.
Si vous envoyez des liens avec un jeton de connexion secret par e-mail, ils doivent être à usage unique et expirer assez rapidement.