web-dev-qa-db-fra.com

Quel est le type d'authentification SMTP le plus sécurisé?

Supposons que vous ne deviez choisir qu'un seul parmi les types d'authentification suivants pour votre propre serveur SMTP:

  • CONNEXION, PLAIN
  • CRAM-MD5
  • DIGEST-MD5
  • NTLM/SPA/MSN

Lequel recommanderiez-vous pour une sécurité optimale?

PS: La liste est les types d'authentification donnés dans man swaks

emailserversmtp
17
user123456

Avec SSL/TLS, vous pouvez utiliser LOGIN/PLAIN.

Vous devez fournir SMTP en plus d'une connexion cryptée SSL. Certains schémas de votre liste (par exemple, DIGEST-MD5) peut sécuriser un mot de passe même sur un canal non fiable, il ne protégera pas les utilisateurs contre un pirate man-in-the-middle altérant leur session. (Généralement, les serveurs de messagerie enveloppent SMTP via TLS direct ou une mise à niveau de connexion avec STARTTLS sur les ports 465/587.)

Tout type d'authentification SMTP, que vous utilisiez PLAIN ou une méthode avancée, fournit simplement authentification au niveau de l'application. Mais ce que vous voulez, c'est sécurité au niveau du transport =. Une fois qu'un utilisateur est authentifié via SMTP, il n'y aura plus de connexion cryptée automatiquement. Conformément au protocole SMTP, les commandes et les e-mails sont échangés avec le serveur en texte brut, ce qui permet à un attaquant du milieu de lire et de modifier la communication et d'injecter de nouvelles commandes. C'est pourquoi vous devez le fournir en plus du cryptage SSL, tout comme HTTPS fournit HTTP en plus de SSL.

L'analogie HTTP: si vous sécurisez votre site Web avec HTTPS, alors peu importe que le formulaire de connexion transmette réellement votre mot de passe sous forme de chaîne simple dans le corps POST de la requête HTTP, car le transport de données est crypté SSL. Activation de CRAM-MD5 pour SMTP est analogue à l'implémentation d'un schéma challenge-response en Javascript avant de transmettre les informations de connexion à un site Web. (Vous pouvez parfois voir cette technique dans les interfaces de routeur qui ne fournissent pas HTTPS mais ce n'est pas très courant.)

En ce qui concerne un exemple réel, GMail est d'accord avec l'offre d'authentification LOGIN/PLAIN (où les informations d'identification sont envoyées dans le texte du plan) après avoir établi une connexion SSL sécurisée:

 $ openssl s_client -starttls smtp -connect smtp.gmail.com:587 
 ... 
 250 SMTPUTF8 
 EHLO foo 
 250-smtp .gmail.com à votre service, [127.0.0.1] 
 250-SIZE 35882577 
 250-8BITMIME 
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKBE OAUTHBEARER XOAUTH
 250-STATUSCODES AMÉLIORÉS 
 250-PIPELINING 
 ...

(Comme vous pouvez le voir, ils fournissent également certaines méthodes que vous n'avez pas répertoriées, par exemple XOAUTH2 pour les jetons OAuth2 qui pourraient être intéressants si vous recherchez une authentification sans mot de passe.)

45
Arminius

Ce que j'appelle une authentification Nice est celle qui a les propriétés suivantes:

  • le serveur n'a jamais à connaître le mot de passe réel mais n'en garde qu'un hachage

    Cela garantit que même si la base de données de mots de passe est compromise, l'attaquant n'aura que du mal à inverser les hachages et les utilisateurs auront suffisamment de temps pour modifier leurs mots de passe.

  • le mot de passe n'est jamais échangé en texte clair

    Ce qui est échangé peut être espionné trop facilement, et un mot de passe qui passe en texte clair sur un canal non crypté doit être considéré comme compromis

À condition que le serveur SMTP autorise TLS, PLAIN respecte les deux avec le scénario suivant: HELO, STARTTLS, LOGIN

3
Serge Ballesta

Outre les meilleures recommandations pour SMTP, voici votre liste disponible:

  • LOGIN, PLAIN: Le mot de passe est transféré en texte clair.
  • CRAM-MD5: Faible par rapport à texte en clair choisi et a des problèmes de stockage de mot de passe.
  • DIGEST-MD5: Mieux que CRAM-MD5 car il est plus fort contre l'attaque en texte clair choisi et permet l'utilisation d'une authentification tierce les serveurs
  • NTLM/SPA/MSN: Authentification NTLM qui est également vulnérable au texte en clair choisi .
3
Opaida