Wichtige Änderung: Microsoft stellt Basic Authentication für SMTP ein

Handlungsbedarf für diaLIMS-Nutzer: Aktualisierung erforderlich

Hintergrund zur Änderung:
Microsoft hat angekündigt, die Unterstützung für Basic Authentication in Exchange Online schrittweise einzustellen, um die Sicherheit zu erhöhen und moderne Authentifizierungsverfahren zu fördern. Ab September 2025 wird insbesondere die Basic Authentication für SMTP AUTH endgültig deaktiviert. (Quelle: https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online)

Auswirkungen auf diaLIMS-Nutzer:
diaLIMS ermöglicht den Versand von E-Mails und unterstützt dabei verschiedene Authentifizierungsmethoden wie LOGIN, PLAIN, DIGEST-MD5 und NTLM. Wenn Sie derzeit den Mail-Versand aus diaLIMS über Microsoft-Exchange-Server mit einem der genannten Verfahren nutzen, wird dies ab September 2025 nicht mehr funktionieren.

Notwendige Maßnahmen:
Damit der E-Mail-Versand weiterhin funktioniert, ist die Umstellung auf OAuth erforderlich. Seit der diaLIMS-Version 14.1 wird OAuth für den Mailversand unterstützt. Wir empfehlen Ihnen daher dringend, rechtzeitig ein Upgrade auf mindestens diese Version einzuplanen und durchzuführen.

Fazit und Ausblick:
Die bevorstehende Deaktivierung der Basic Authentication durch Microsoft erfordert proaktive Schritte, um den reibungslosen Betrieb von diaLIMS sicherzustellen. Bitte planen Sie zeitnah das notwendige Update ein, um Unterbrechungen im E-Mail-Versand zu vermeiden. Wenn Sie für den Mail-Versand andere Dienste verwenden, prüfen Sie bitte, ob dort auch eine Deaktivierung der Basic Authentication geplant ist und planen Sie rechtzeitig ein Upgrade Ihres diaLIMS-Systems ein.

Für Unterstützung oder weitere Informationen stehen wir Ihnen gerne zur Verfügung.
 

Nehmen Sie gerne Kontakt mit uns auf.
 

Weitergehende Informationen für technisch Interessierte

Authentifizierungs- bzw. Autorisierungsverfahren

Bei der Anmeldung an E-Mail-Servern (IMAP, POP3, SMTP) gibt es mehrere gängige Authentifizierungs- bzw. Autorisierungsverfahren, die sich hinsichtlich Sicherheit, Komplexität und Verbreitung unterscheiden. Hier ein Überblick über die üblichsten Verfahren und deren Unterschiede: 

1. PLAIN / LOGIN (auch oft als "Basic Auth" bezeichnet)

• Funktionsweise: Benutzername und Passwort werden Base64-codiert (nicht verschlüsselt!) übertragen.
• Sicherheit: Nur sicher, wenn über eine TLS/SSL-gesicherte Verbindung verwendet.
• Verbreitung: Sehr verbreitet, da einfach zu implementieren.
• Unterschied PLAIN vs. LOGIN: Beide übertragen das Passwort Base64-codiert, aber in leicht unterschiedlicher Form:
  • PLAIN: alles in einer Zeile (authzid\0authcid\0password)
  • LOGIN: Benutzername und Passwort werden in zwei getrennten Schritten gesendet.

2. CRAM-MD5 (Challenge-Response Authentication Mechanism)

• Funktionsweise: Der Server sendet eine Challenge, der Client antwortet mit einem Hash aus Challenge + Passwort.
• Sicherheit: Passwort wird nicht direkt gesendet, daher sicherer als PLAIN.
• Verbreitung: Seltener geworden, wird nicht mehr von allen Clients/Servern unterstützt.
• Nachteile: Keine Unterstützung für moderne Passwortmanager oder Zwei-Faktor-Authentifizierung.

3. DIGEST-MD5

• Funktionsweise: Ähnlich wie CRAM-MD5, aber komplexer und mit mehr Optionen (z. B. Schutz vor Replay-Angriffen).
• Sicherheit: Etwas besser als CRAM-MD5, aber auch angreifbar (veralteter Hash-Algorithmus).
• Verbreitung: Veraltet und wird kaum noch unterstützt.

4. NTLM (NT LAN Manager)

• Funktionsweise: Microsoft-spezifisches Challenge-Response-Verfahren, nutzt Windows-Zugangsdaten.
• Sicherheit: Besser als PLAIN, aber proprietär.
• Verbreitung: Vor allem in Windows-/Exchange-Umgebungen.
• Hinweis: Wurde zunehmend durch Kerberos und OAuth ersetzt.

5. OAuth 2.0 (z. B. XOAUTH2)

• Funktionsweise: Statt Passwort sendet der Client ein Token, das vom Benutzer zuvor über ein sicheres Verfahren (Browser, App) autorisiert wurde.
• Sicherheit: Sehr hoch, unterstützt auch Zwei-Faktor-Authentifizierung.
• Verbreitung: Wird zunehmend Standard bei großen Anbietern wie Google, Microsoft, Yahoo usw.
• Vorteile:
  • Kein Passwort wird übertragen.
  • Kann mit Ablaufzeiten und Scopes granular gesteuert werden.
• Nachteile: Etwas komplexer in der Implementierung.

Verbindungssicherheit

Die Verbindungssicherheit ist ein eigenständiger, aber extrem wichtiger Aspekt beim Zugriff auf Mailserver. Es geht darum, wie die Verbindung zwischen Client und Server verschlüsselt wird, unabhängig vom verwendeten Anmeldeverfahren (z. B. PLAIN, OAuth etc.).

Hier eine Übersicht der gängigsten Varianten zur Verbindungssicherung:

Varianten der Verbindungssicherheit bei E-Mail-Protokollen

1. Unverschlüsselte Verbindung

• Bezeichnung: Klartext / Plain / Keine Verschlüsselung
• Port-Beispiele:
  • SMTP: 25
  • POP3: 110
  • IMAP: 143
• Status: Veraltet und unsicher, sollte nicht mehr verwendet werden.
• Problem: Anmeldedaten und Inhalte werden im Klartext übertragen.

2. SSL (Secure Sockets Layer) / „Implicit SSL“

• Funktionsweise: Die Verbindung wird vom ersten Byte an verschlüsselt.
• Bezeichnung: Meist als „SSL“ bezeichnet, obwohl meist TLS verwendet wird (SSL ist technisch veraltet).
• Port-Beispiele:
  • SMTP über SSL: 465
  • POP3 über SSL: 995
  • IMAP über SSL: 993
• Status: Sehr verbreitet (aber meist intern bereits TLS).
• Sicher: Ja – direkte TLS-verschlüsselte Verbindung.

3. STARTTLS („Explicit TLS“)

• Funktionsweise: Verbindung wird zunächst im Klartext gestartet, dann mit einem STARTTLS-Befehl auf eine TLS-gesicherte Verbindung „umgeschaltet“.
• Port-Beispiele (gleichen Ports wie Klartext):
  • SMTP mit STARTTLS: 25 oder 587
  • POP3 mit STARTTLS: 110
  • IMAP mit STARTTLS: 143
• Status: Sehr verbreitet, Standard bei modern konfigurierten Mailservern.
• Sicher: Ja – sofern STARTTLS erfolgreich erzwungen wird.