Authentification SMTP
SMTP-AUTH est une extension du protocole SMTP. C'est un protocole de transfert des courriels sur Internet qui comporte une étape d'authentification au cours de laquelle le client se connecte explicitement au serveur (ou relais) pour l'envoi de courriers (d'e-mails). Les serveurs qui utilisent le protocole SMTP-AUTH (qui peuvent dialoguer en usant d'une authentification préalable) peuvent être paramétrés pour n'accepter que des clients capables de s'authentifier (clients possédant cette extension) et ainsi certifier d'une autorisation d'accès pour ces derniers. SMTP-AUTH fournit un mécanisme de contrôle d'accès. Il peut être utilisé pour n'autoriser que certains utilisateurs (clients) à relayer des courriers (et donc refuser les autres clients tels que les spammers). Il ne garantit pas l'authenticité de l'enveloppe SMTP ni l'information d'en-tête appelée From: de la recommandation RFC 2822. Par exemple, le « spoofing[précision nécessaire] », où un utilisateur se fait passer pour quelqu'un d'autre, est possible avec SMTP-AUTH (seule l'action d'envoi de courriers est ici contrôlée). L'extension SMTP-AUTH permet à un serveur (ou relais) de courriers d'indiquer à un autre serveur que l'expéditeur a été authentifié lors du relayage de courriers. En général, cela nécessite au serveur cible de croire le premier serveur (autrement dit que ce serveur soit déclaré comme serveur de confiance), raison pour laquelle ce protocole est peu utilisé sur Internet. Le destinataire d'un courrier ne peut pas savoir si l'expéditeur a été authentifié, c'est pourquoi SMTP-AUTH n'est qu'une solution partielle au problème du spam. SMTP-AUTH dispose de plusieurs modes : PLAIN: ce mode permet l'authentification en envoyant directement l'identifiant et le mot de passe, encodés en Base64. LOGIN: ce mode permet l'authentification par l'envoi successif de l'identifiant, puis du mot de passe, encodés eux aussi en Base64. CRAM-MD5: ce mode permet l'authentification par l'envoi de l'identifiant et du mot de passe hachés en MD5. Bien que SMTP-AUTH renforce dans l'ensemble la sécurité par rapport au protocole SMTP non authentifié, il peut cependant introduire une faiblesse. Si les utilisateurs authentifiés sont autorisés à émettre des courriers depuis des adresses IP, alors l'accès à un compte permet d'utiliser le serveur mail en relais ouvert. Autrement dit, dans cette configuration, les mots de passe de tous les utilisateurs donnent accès à la même fonctionnalité ; la compromission d'un seul d'entre eux suffit à compromettre les garanties d'authenticité offertes par le serveur entier. Pour cette raison, des serveurs SMTP-AUTH ont été pris pour cible par des spammeurs. Pour réduire ce risque, on peut imposer aux utilisateurs d'employer des mots de passe forts. Le fonctionnement du mécanisme SMTP-AUTH a été décrit en 1999 par J. Myers de Netscape Communications, et finalisé dans la RFC 2554 ("SMTP Service Extension for Authentication"). Cette RFC est aujourd'hui obsolète et remplacée par la RFC 4954.
Cet article est une ébauche concernant la sécurité informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Consultez la liste des tâches à accomplir en page de discussion.SMTP-AUTH est une extension du protocole SMTP. C'est un protocole de transfert des courriels sur Internet qui comporte une étape d'authentification au cours de laquelle le client se connecte explicitement au serveur (ou relais) pour l'envoi de courriers (d'e-mails). Les serveurs qui utilisent le protocole SMTP-AUTH (qui peuvent dialoguer en usant d'une authentification préalable) peuvent être paramétrés pour n'accepter que des clients capables de s'authentifier (clients possédant cette extension) et ainsi certifier d'une autorisation d'accès pour ces derniers.
SMTP-AUTH fournit un mécanisme de contrôle d'accès. Il peut être utilisé pour n'autoriser que certains utilisateurs (clients) à relayer des courriers (et donc refuser les autres clients tels que les spammers). Il ne garantit pas l'authenticité de l'enveloppe SMTP ni l'information d'en-tête appelée From: de la recommandation RFC 2822[1]. Par exemple, le « spoofing[précision nécessaire] », où un utilisateur se fait passer pour quelqu'un d'autre, est possible avec SMTP-AUTH (seule l'action d'envoi de courriers est ici contrôlée).
L'extension SMTP-AUTH permet à un serveur (ou relais) de courriers d'indiquer à un autre serveur que l'expéditeur a été authentifié lors du relayage de courriers. En général, cela nécessite au serveur cible de croire le premier serveur (autrement dit que ce serveur soit déclaré comme serveur de confiance), raison pour laquelle ce protocole est peu utilisé sur Internet. Le destinataire d'un courrier ne peut pas savoir si l'expéditeur a été authentifié, c'est pourquoi SMTP-AUTH n'est qu'une solution partielle au problème du spam.
SMTP-AUTH dispose de plusieurs modes[2] :
- PLAIN: ce mode permet l'authentification en envoyant directement l'identifiant et le mot de passe, encodés en Base64.
- LOGIN: ce mode permet l'authentification par l'envoi successif de l'identifiant, puis du mot de passe, encodés eux aussi en Base64.
- CRAM-MD5[3]: ce mode permet l'authentification par l'envoi de l'identifiant et du mot de passe hachés en MD5.
Bien que SMTP-AUTH renforce dans l'ensemble la sécurité par rapport au protocole SMTP non authentifié, il peut cependant introduire une faiblesse. Si les utilisateurs authentifiés sont autorisés à émettre des courriers depuis des adresses IP, alors l'accès à un compte permet d'utiliser le serveur mail en relais ouvert. Autrement dit, dans cette configuration, les mots de passe de tous les utilisateurs donnent accès à la même fonctionnalité ; la compromission d'un seul d'entre eux suffit à compromettre les garanties d'authenticité offertes par le serveur entier. Pour cette raison, des serveurs SMTP-AUTH ont été pris pour cible par des spammeurs. Pour réduire ce risque, on peut imposer aux utilisateurs d'employer des mots de passe forts.
Le fonctionnement du mécanisme SMTP-AUTH a été décrit en 1999 par J. Myers de Netscape Communications, et finalisé dans la RFC 2554[4] ("SMTP Service Extension for Authentication"). Cette RFC est aujourd'hui obsolète et remplacée par la RFC 4954[5].
Références
[modifier | modifier le code]- ↑ (en) Request for comments no 2822
- ↑ « AUTH Command and its Mechanisms (PLAIN, LOGIN, CRAM-MD5) - SMTP Commands Reference », sur www.samlogic.net (consulté le 14 novembre 2016)
- ↑ Catoe, R. et Klensin, J., « IMAP/POP AUTHorize Extension for Simple Challenge/Response », sur tools.ietf.org (consulté le 14 novembre 2016)
- ↑ (en) Request for comments no 2554
- ↑ (en) Request for comments no 4954
