Warum ist SMTP unsicher?

[Falc410]

Ich habe gelesen, dass Google und Microsoft SMTP Auth abschalten und durch OAuth ersetzen wollen.

https://docs.microsoft.com/de-de/Ex...fice-365-69f58e99-c550-4274-ad18-c805d654b4c4

MS rudert hier ein wenig zurück aber die Hauptfrage ist, warum überhaupt? Ich habe nichts gelesen, dass SMTP Auth unsicher wäre. Bei TLS werden die Passwörter ja verschlüsselt übertragen. SMTP wird doch von 100% aller Clients unterstützt, OAuth 2.0 hingegen ist doch nicht stark verbreitet, oder doch?

 

[Yuuri]

Wo steht, dass es "unsicher" ist? Da steht lediglich, dass es durch OAuth ersetzt wird.

 

[Staubgeborener]

Gehts einfach darum das die aus Prinzip SMTPS haben wollen?
Bin da nicht ganz drinne aber TLS mit SMTP ist doch SMTPS.
Warum sollte das nicht genügen....
Würde mich auch interessieren!

 

[Falc410]

Wo steht, dass es "unsicher" ist? Da steht lediglich, dass es durch OAuth ersetzt wird.

Das war die Aussage der Kollegen die O365 betreuen bei uns. Es gab auch ein Security Assessment von MS, wo das ebenfalls als Security Risiko erkannt worden ist und ist laut den Kollegen im Moment das Größte Risiko. Ich verstehe nur nicht wieso. Mir sind keine Lücken oder Angriffe bekannt. Man kann hinreichend komplexe Passwörter vorgeben und gut ist. SMTP nur verschlüsselt über TLS / STARTLS zulassen und fertig.

Jira schreibt ebenfalls:

Some providers such as Google and Microsoft are planning on disabling Basic Authentication. When they do, you will not be able to create issues and comments from email and your connection to the Gmail and/or Microsoft Exchange Online server will no longer be operational. You do not need to update the settings in your custom email servers or other service providers if they use IMAP or POP3. They will continue to work.

https://confluence.atlassian.com/adminjiraserver/integrating-with-oauth-2-0-1013845729.html

Aber warum?

 

[Drewkev]

SMTP ist alt, POP3 oder IMAP werden mittlerweile genutzt. Das Protokoll SMTP selbst ist unverschlüsselt, verschickt also die E-Mails standardmäßig in Klartext. Die Verschlüsselung übernimmt, wenn, der Client.

 

[BFF]

Macht Google Mail nicht eh schon OAUTH fuer die Authentifizierung?
z.B. der Thunderbird legt das ja schon so an mit dem GMAIL-Konten.

Putzig. Bei outlook.com per TB sieht es ganz anders aus.

 

[PHuV]

Gehts einfach darum das die aus Prinzip SMTPS haben wollen?
Bin da nicht ganz drinne aber TLS mit SMTP ist doch SMTPS.

Du liegst hier vollkommen richtig. Und wenn man nachliest, OAuth gibts auch schon seit 2006, ist also nicht mehr so jung. OAuth 2.0 funktioniert erst wirklich anders und ist schön länger Basis von OpenID Connect, was wiederum heute jeder aktuelle E-Mail-Server wie Client beherrscht.

Im Windows Umfeld kann man es hier schön nachlesen:
https://docs.microsoft.com/de-de/wi...velopment/ad-fs-openid-connect-oauth-concepts

 

[Masamune2]

Hier geht es nicht um die Verschlüsselung, SMTP gibt es auch mit TLS, sondern um die Authentifizierung. OAuth ist einfach das modernere Verfahren und erlaubt damit unter anderem auch 2FA für die Mails.

 

[Falc410]

Ok also OAuth 2.0 wird unterstützt aber warum ist es jetzt "besser" als SMTP Auth?

SMTP ist alt, POP3 oder IMAP werden mittlerweile genutzt. Das Protokoll SMTP selbst ist unverschlüsselt, verschickt also die E-Mails standardmäßig in Klartext. Die Verschlüsselung übernimmt, wenn, der Client.

SMTP hat mit POP3 und IMAP nichts zu tun.
Die Verschlüsselung kann der Server natürlich erzwingen. Du sagst ja auch nicht das Webseiten verboten werden sollen nur weil es HTTP vorher gab. Server forcieren HTTPS und gut ist.

Ich hätte halt gerne irgendwelche Argumente zur Hand warum SMTP Auth schlecht ist und OAuth gut um das reale Risiko einzuschätzen. Und da brauche ich etwas mehr als "ist alt" oder "mein Bauchgefühl" sagt. Also falls jemand entsprechende Links hat, bin ich sehr dankbar

Ergänzung (20. Januar 2022)

Hier geht es nicht um die Verschlüsselung, SMTP gibt es auch mit TLS, sondern um die Authentifizierung. OAuth ist einfach das modernere Verfahren und erlaubt damit unter anderem auch 2FA für die Mails.

Das ist ein guter Punkt. Bringt bei APIs und Script-basierten Dingen aber nichts, weil da kein 2FA (zumindest nicht so leicht) funktioniert. Für End-user eine Verbesserung, ja. Danke

 

[emulbetsup]

SMTP ist alt, POP3 oder IMAP werden mittlerweile genutzt. Das Protokoll SMTP selbst ist unverschlüsselt, verschickt also die E-Mails standardmäßig in Klartext. Die Verschlüsselung übernimmt, wenn, der Client.

Man muss bei dem ganzen Themenkomplex hart zwischen der Verschlüsselung auf dem Transportweg und der eventuellen Ende-zu-Ende-Verschlüsselung der eigentlichen Mail unterscheiden.

Auch werden hier die Protokolle und deren Funktion durcheinander geworfen. SMTP wird kaum noch zwischen Clients und Servern, sondern hauptsächlich zwischen Mail-Servern gesprochen, während POP3 und IMAP die Protokolle für die Kommunikation zwischen Mail-Client und Mail-Server sind.

SMTPS ist der Sache nach genauso unsicher, wie es HTTPS ist.

 

[PHuV]

Hier geht es nicht um die Verschlüsselung, SMTP gibt es auch mit TLS, sondern um die Authentifizierung. OAuth ist einfach das modernere Verfahren und erlaubt damit unter anderem auch 2FA für die Mails.

Macht das jemand so? Wir machen alle paar Tage eine 2FA für den Exchange Server für alles. Für jede E-Mail würde ich ja wahnsinnig werden.

 

[Piktogramm]

Ok also OAuth 2.0 wird unterstützt aber warum ist es jetzt "besser" als SMTP Auth?

https://en.wikipedia.org/wiki/OAuth

OAuth erlaubt aus dem grundlegendem Design heraus, dass Zugriffsrechte sauber getrennt für jeden Clienten verwaltet werden können. Was unheimlich praktisch ist, denn im Zweifelsfall bekommen so Angreifer keinen Vollzugriff auf alles wenn sie irgendwie an Kennung + Passwort kommen.
Sowas kann man selber bauen und für jedes Protokoll implementieren. Das macht aber kaum jemand und wenn es getan wird, sind die Lösungen immer zum Wegrennen.

Edit: Clienten sind im Zweifelsfall Anwendungen. Email auf dem Desktop, Email auf dem Smartphone, Email im Browser sind je ein Client.

Edit2:
Was aber auch so ein Ding ist, OAuth ist deutlich weniger offen als es der Name andeutet und kann ganz hervorragend dazu genutzt werden um Kunden zu gängeln. Im Zweifel kann man die Schnittstellen auch dazu nutzen um Clientsoftware von unerwünschten Mitbewerbern auszuschließen.

 

[Yuuri]

Du liegst hier vollkommen richtig.

Aber wieso deswegen "SMTP abstellen"? Sonst würde es ja SMTP Auth über Port 25 heißen und nicht SMTP Auth über Port 587 (STARTTLS) und 25 (unverschlüsselt). Ergo gilt auch SMTPS über Port 587 als removed. Ggf. wegen STARTTLS?

Der Vorzug für OAuth - geschenkt. Ich denke die Vorteile erkennt man, da der Web Login genutzt wird und somit 2FA erzwungen werden kann, sowie nur Tokens ausgestellt werden, welche auch noch in ihren Berechtigungen fein eingestellt werden können. Das kann man aber auch jahrelang bereits mit App-Passwörtern umsetzen, wenn man diese nur forcieren würde und so weit ich weiß wird auch bei Microsoft und Google der SMTP Login mit Account-Passwort unterbunden bzw. sowieso OAuth präsentiert beim Einrichten. Ich hatte in Outlook zuletzt zumindest nen OAuth Prompt für meine Google Adressen bekommen.

Wieso also SMTP Auth abgestellt und OAuth eingeführt wird, wäre mir auch klar. Nur nicht, dass nur SMTP Auth über STARTTLS und unverschlüsselt abgeschaltet wird. Unverschlüsselt ist logisch, STARTTLS wegen potentiellem MITM? Implizites TLS über Port 465 muss ja weiterhin offen bleiben und bleibt es ja auch. Thunderbird über OAuth richtet das Konto (Google) zumindest über :465 ein, Outlook macht es aber über :587.

 

[PHuV]

Aber wieso deswegen "SMTP abstellen"?

Das mußt Du den Betreiber fragen, nicht mich. 😉

 

[Falc410]

Das kann man aber auch jahrelang bereits mit App-Passwörtern umsetzen, wenn man diese nur forcieren würde und so weit ich weiß wird auch bei Microsoft und Google der SMTP Login mit Account-Passwort unterbunden bzw. sowieso OAuth präsentiert beim Einrichten.

Ich benutze weder Google noch O365, aber mit App-Passwörtern ist es so zu verstehen, dass ich ein extra Passwort z.B. für SMTP Auth anlege für einen speziellen Client? Dann kann ich später zuordnen, welches Passwort bzw. welcher Client für den Versand verantwortlich war?

 

[kim88]

Das mußt Du den Betreiber fragen, nicht mich. 😉

Ist am Ende wohl eine Ressourcenfrage. Warum als Anbieter ein legacy Protokoll Unterstützen.

Ist ja Wartung, und Support bei Anfragen, etc. Bei Supportfokumenten muss man immer unterscheiden ob Funktion mit Protokoll A oder B kompatibel ist.

Wenn man Dokus mit Bild-Anleitungen macht muss man alles doppelt machen je nach Protokoll, das jeweils in mehreren Sprachen, usw

Da fragt man sich halt als Betreiber warum das alles machen und bezahlen

 

[Yuuri]

Ich benutze weder Google noch O365, aber mit App-Passwörtern ist es so zu verstehen, dass ich ein extra Passwort z.B. für SMTP Auth anlege für einen speziellen Client?

App specific passwords oder wie sie auch immer genannt werden sind halt dafür da 2FA zu umgehen, wie man es vom Web Login kennt, falls die Anwendung keinen 2FA Support besitzt - sei es nun TOTP, FIDO, WebAuthn, Mail, SMS, $youNameIt. Google und MS ermöglichen die Generierung in den Accounteinstellungen, wodurch man sich im Mail Client trotzdem zum Mail Account verbinden kann, auch wenn 2FA forciert ist.

Man erstellt halt ein Passwort, welches kurz im Mail Client eingetragen wird und danach verschwindet es auch im Nirwana. Wenn du ne andere Anwendung hast, generierst du dir ein Neues. Brauchst du ne Anwendung nicht mehr, ziehst du das entsprechende Passwort zurück. Es ist halt ein Ersatz fürs reguläre Account-Passwort.

Nichtsdestotrotz ist das nur zum Umgehen des fehlenden 2FA Supports. Prinzipiell kann man sich mit dem Passwort dann überall einloggen. Google und MS erlauben allerdings keine App-Passwörter für den Web Login, ist bei anderen Anbietern hoffentlich genauso.

Dann kann ich später zuordnen, welches Passwort bzw. welcher Client für den Versand verantwortlich war?

Nein, es gibt nirgendwo ein Logging. Das ist nur zur Nutzung des Dienstes für Anwendungen gedacht, welche keinen 2FA Support bieten. Und eine erfolgreiche Passwortabfrage beinhaltet auch nur ein ja/nein und kein PasswortÜbermittelt/PasswortInDb.

Es ist im Prinzip nicht mehr wie ein fixes Token, mit welchem man sich autorisiert - ähnlich bspw. Shared Secrets, wie man sie von PayPal und Co. kennt, womit man bspw. in seinem Shop mit PayPal zahlen lassen kann oder auch in OAuth bekommst du ja nur ein Token übergeben, welches dir den Zugriff erlaubt.

Die Art und Weise wird wohl allerdings zukünftig komplett wegfallen, da man ja OAuth forciert.

 

[Falc410]

Also ich sehe zwar Vorteile bei OAuth, dank eurer Hilfe, aber kein grundlegendes Problem bei SMTP Auth - ausser, dass eben 2FA nicht funktioniert. Aber wie gesagt, gerade für APIs trifft das eh nicht zu. Somit sehe ich keinen Grund, SMTP Auth zu verdammen (in bestimmten Kontexten)

 

[RalphS]

Wird hier nicht bissel zuviel durcheinandergeworfen? 🤔

1. SMTP ist hauptsächlich server-to-server, ja. Aber der Client nutzt es weiterhin für die Datenübermittlung (client-to-server). Auch bei IMAP. Auch bei POP.

2. SMTP ist natürlich NICHT die Authentifizierung. SMTP kann keine Authentifizierung. Es gab mal irgendwann angeflanschte Erweiterungen. Aber SMTP ist und bleibt Klartext.
Ausnahmen gibts, sind aber überschaubar: Exchange und HCL Notes gehören dazu, aber auch dann insbesondere NUR, wenn da kein SMTP Connector dran hängt. Und selbst die benötigen spätestens zur Übergabe an den nächsten Mailserver was anderes.

SMTP ist, wenn man so will, auf derselben Stufe wie HTTP zu suchen. Kann jeder reinlangen. Eventuelle Integritätsprüfungen und andere "Vorkehrungen" sind ausschließlich am Endpunkt definierbar und sind dort wegen Interopabilität optional.

SMTP-over-SSL ist bissel wie HTTPS. Protocol negotiation geht damit aber nicht, das gibt das Protokoll nicht her. Dafür braucht es STARTTLS.

Rein von der Sache her sind sämtliche existenten Kommunikationsprotokolle in Sachen Mail hoffnungslos veraltet und überholt. Sie sind aber auch allgegenwärtig. Einfach mal abschaffen und neumachen geht leider nicht, da gab es schon hunderte Versuche zu, manche sogar sehr medienwirksam.

Ob ich jetzt via SMTP hergehe und OAUTH implementiere oder Kerberos oder Lets Encrypt - kann ich alles machen, wenn ich das will -- ist egal. Am Ende wird die Mail spätestens am nächsten Hop entschlüsselt, auch über TLS egal in welcher Implementierung. Jeder(!) mit Zugriff auf die Maildaten an einem Unterwegsbahnhof hat Zugriff auf die Mails und kann sie ändern --- was meint ihr wohl, warum Mails per se kein rechtssicheres Kommunikationsmittel sind?

E2EE wie PGP oder SMIME helfen da, aber beide sind weder Pflicht noch in irgendeiner Form Bestandteil von POP oder SMTP oder IMAP oder X500 oder Schlachmichtot. Hats der Gegenüber nicht, funktioniert es auch nicht und die einzelne Mail degeneriert doch wieder zur virtuellen Postkarte.

 

[Falc410]

Wird hier nicht bissel zuviel durcheinandergeworfen? 🤔

Ich glaube dir ist gerade das passiert....du wirfst hier sehr merkwürdige Dinge durch die Gegend - die zwar nicht falsch sind, aber irgendwie komplett am Thema vorbei...

2. SMTP ist natürlich NICHT die Authentifizierung. SMTP kann keine Authentifizierung. Es gab mal irgendwann angeflanschte Erweiterungen. Aber SMTP ist und bleibt Klartext.

Also Punkt 1: Was hat Authentifizierung mit Klartext zu tun? Punkt 2: Ja, das original RFC 1982 hat keine Authentication in SMTP vorgesehen, da hast Recht, d.h. jeder Mailserver hat alle Mails ausgeliefert. Dass das eine schlechte Idee ist, hat man schnell erkannt und deswegen gab es ja früher schon Mechanismen wie Pop-before-SMTP und auch im SMTP RFC von 2008 ist Authentication erwähnt.
"
If these rules are followed, the example in RFC 821 that shows "550
access denied to you" in response to an EXPN command is incorrect
unless an EHLO command precedes the EXPN or the denial of access is
based on the client's IP address or other authentication or
authorization-determining mechanisms."

Also das hat nichts mit Klartext zu tun

SMTP ist, wenn man so will, auf derselben Stufe wie HTTP zu suchen. Kann jeder reinlangen. Eventuelle Integritätsprüfungen und andere "Vorkehrungen" sind ausschließlich am Endpunkt definierbar und sind dort wegen Interopabilität optional.

Ich weiß zwar was du meinst, aber darum geht es doch überhaupt nicht. Davon abgesehen, kannst du deinen SMTP Server natürlich dazu verpflichten, nur TLS zu sprechen um den Transportweg zu verschlüsseln. Dürfte in der Realität halt noch ein paar Probleme geben. Aber es geht nicht um den Transportweg von E-Mails und es geht auch nicht um E-Mailverschlüsselung hier.

Am Ende wird die Mail spätestens am nächsten Hop entschlüsselt, auch über TLS egal in welcher Implementierung. Jeder(!) mit Zugriff auf die Maildaten an einem Unterwegsbahnhof hat Zugriff auf die Mails und kann sie ändern --- was meint ihr wohl, warum Mails per se kein rechtssicheres Kommunikationsmittel sind?

Es geht hier nicht um E-Mails oder um rechtssichere Kommunikation. Es geht einzig und allein darum wie sich ein Client (Programm, Mensch, Script) bei einem SMTP authentifiziert, damit er E-Mails über diesen SMTP Server verschicken darf. Ob die E-Mail verschlüsselt ist mit PGP, ob der Transportweg verschlüsselt ist, das spielt alles keine Rolle. Es geht einzig und allein um die Authentifizierung des Clients gegenüber dem Mailserver. Und wir sprechen hier auch nur vom versenden - hat mit IMAP und POP3 auch nichts zu tun.

Sind ja auch getrennte Komponenten auf einem Mailserver.