App Password

Ein User, ein Account, ein Login ist eine schöne Sache und mit einem Active Directory auch ganz einfach bereit zu stellen. Aber je mehr Dienste den gleichen Anmeldeservice nutzen, desto risikobehafteter ist diese "eine Kennwort". Auf Password Safe habe ich die Wichtigkeit unterschiedlicher Kennworte bei unterschiedlichen Diensten im Internet aufgezeigt. Mit eine Anmeldung reicht nur ein schwaches Glied in der Kette eines Dienstes und wenn dann eine fremde Person das Kennwort erspäht, hat er Zugriff auf alle Ressourcen.

Aktive Azure Security Defaults blockieren die Anmeldung per SMTP ohne OAUTH! oder mit App Password

Auch wenn ich hier BMW als konkretes Beispiel nutze, sollten Sie diese Seite nicht Kritik an BMW selbst missverstehen. Die Thematik taucht in anderen Umgebungen ebenfalls auf.

Ein Kennwort für eine App ist ähnlich der Authentifizierung einer App, wie dies bei Graph API und anderen Cloud-Diensten der Fall ist. Während hier aber die App mit dem Kennwort sich als Benutzer authentifiziert, ist bei Graph noch eine weitere Freischaltung erforderlich.

Die Nutzung von App-Kennworten ist mit Azure Security Defaults nicht mehr möglich!

Auslöser: BMW Connected Drive

Diese Seite habe ich gestartet, als mich ein BMW-Fahrer bat, ihn bei der Einrichtung seines Mailzugangs im Auto zu helfen. Über die Funktion "BMW Connected Drive" kann ein Auto Mails abrufen und dem Fahrer vorlesen. Der Fahrer kann sogar darauf antworten, indem er per Sprache "diktiert" und das Auto mittels der Software von Nuance (Dragon Voice) darauf eine Mail verfasst.

Damit muss ich natürlich erst mal in Erfahrung bringen, was dort technisch dahinter steckt. Leider habe ich auf den BMW-Seiten keine Informationen gefunden und auch keine "Anleitung für Firmen Administratoren" o.ä. aber über Beiträge in verschiedenen Internetforen konnte ich dann mir schnell zusammenreimen, was da passiert: BMW Connected Drive ist u.a. die Integration verschiedener Techniken im Fahrzeug.

  • Eigene SIM-Karte
    Das Fahrzeug ist mit einer eigenen SIM-Karte ausgestattet, über die es permanent mit BMW Services in kontakt steht, z.B.- um Standorte und Telemetriedaten zu melden oder aktuelle Verkehrsmeldungen herunter zu laden oder auf E-Mail-Postfächer zuzugreifen.
    Der Zugriff erfolgt dabei über BMW-Server, die entsprechend konfiguriert sind.
    Es sieht so aus, als wenn im Fahrzeug keine weitere Identifizierung zum Zugriff auf die vom BMW Server abgeholten Mails erforderlich ist.
  • Telefon
    Die eingebaute SIM-Karte wird nicht zum Telefonieren genutzt. Stattdessen verbindet sich der BWM per Bluetooth mit einem vorhandenen Telefon, welches auch in eine Ladehalterung gelegt werden kann. Aber auch hier scheinbar nur Strom und USB bekommt aber die Verbindung per Bluetooth erfolgt.
    Die Kompatibilität mit verschiedenen Telefonen kann unter http://www.bmw.de/de/topics/faszination-bmw/connecteddrive-2013/connecteddrive-services-offers/mobile-endgeraete/kompatibilitaet.html geprüft werden.
  • E-Mail
    BMW kann Mails von IMAP und POP Server abholen und anzeigen. Dazu nutzt es die interne SIM-Karte und verbindet sich mit den BMW-Services, die im Auftrag des Anwender die Daten beim Postfachserver abholen. Das Telefon ist hierbei dann außen vor.
    Parallel kann das Fahrzeug mit einer begrenzen Auswahl an Telefonen auch die Mails vom Telefon laden und anzeigen
    http://www.bmw.com/com/en/insights/technology/connecteddrive/2013/a_to_z/index.html?prm_entryid=bmw-online-office

Die Spracherkennung mit Diktieren von SMS und E-Mails ist ebenfalls möglich (http://www.nuance.de/for-individuals/by-product/bmw/faqs/index.htm) und nutzt auch das per Bluetooth verbundene Mobiltelefon. (Kompatibilität erforderlich)

Aus einem Forum (http://www.motor-talk.de/forum/imap-auf-connected-drive-geht-auch-gmail-t2367654.html) habe ich eine Anleitung zur Einrichtung eines IMAP4-Kontos im BMW Fahrzeug gefunden, die ich etwas erweitert habe.

  1. Bei ConnectedDrive einloggen
    http://www.bmw-connecteddrive.com/
  2. "Office" > "Email" > "Einstellungen" > "Ext. Mailbox" > "Neue Mailbox einrichten"
  3. Felder vervollständigen (Servername, Mailboxname, Benutzername bei ConnectedDrive, Passwort)
  4. Auswählen: "POP3", "IMAP" oder "IMAP-SSL"
    Ein Abruf über andere Protokolle (WebDav, WebService oder insbesondere ActiveSync) ist scheinbar nicht verfügbar. Selbst dann wäre fraglich, wie Policies angewendet werden. Gut, dass zumindest IMAP-SSL angeboten wird. Ich konnte nicht prüfen, welchen Stammzertifikaten BMW vertraut.
  5. Einstellungen übernehmen
    Damit werden die Daten gespeichert.

Der Anwender konfiguriert auf einem BMW-Server einen IMAP4-Zugang zum Mailserver und dieser Server ist die Brücke zwischen Fahrzeug und IMAP-Server. Es ist es sehr wahrscheinlich, dass es ein Firmenwagen ist, der natürlich die Nachrichten auf dem Mailserver in der Firma lesen soll. An sich ist es ja kein Problem, IMAP4 auch von extern erreichbar zu machen. Über SSL sollte sowohl die Übertragung der Mails selbst sondern vor allem auch der Anmeldeprozess durch eine Verschlüsselung gesichert werden. In diesem Fall endet aber die Verschlüsselung nicht auf dem Bordcomputer, sondern schon auf dem Server.

Dabei ist mit eingefallen, dass BMW gar nicht das einzige Produkt ist, welches die Preisgabe eines Kennworts auf dem Server des Anbieters erfordert. Mit Office 365 können Sie Exchange auch sagen, dass er z.B. ein fremdes IMAP Postfach lesen und im Exchange Server bereit stellen soll. Und auch all die Blackberry-Anwender ohne eigenen Enterprise Server können den "Blackberry Internet Server" nutzen. Auch hier hinterlegen Sie das Kennwort für das abgefragte IMAP4-Konto auf dem Server. Das ist alles kein Problem, so lange Sie dem Anbieter vertrauen und wenn das IMAP4-Kennwort nicht ausgerechnet auch ihr wichtiges Firmenkennwort ist. Bei Exchange ist das IMAP-Kennwort aber immer auch das Firmenkennwort.

Da stellt sich natürlich die Frage, warum BMW diesen Weg gewählt hat und nicht im Auto einen IMAP-Client oder einen ActiveSync-Client bereit gestellt hat. Alternativ könnte das Fahrzeug vielleicht in Verbindung mit einer App auch direkt auf die Mails im Smartphone zugreifen.

Abhilfe - Alternate Credentials ?

Damit stellt sich natürlich die Frage, wie so ein Konflikt gelöst werden kann. Das Verbot dieser Integration seitens der Firma ist sicher ein möglicher Weg. Sehr viele Firmen veröffentlichen z.B.: überhaupt keinen Zugang per IMAP. Aber IMAP ist ja nur ein Beispiel. Die Welt wird vernetzter und auch ein ActiveSync-Zugang auf einem Smartphone hinterlegt die Anmeldedaten. Kaum jemand wird immer wieder das Kennwort eingeben wollen. Auch ein SkyDrive Pro Account oder Lync oder OutlookAnywhere verbindet sich natürlich mit dem Firmenserver. Auch wenn hier hoffentlich SSL zum Einsatz kommt, ist es dennoch nicht ausgeschlossen, dass doch jemand mitlauscht. Das kann ein Trojaner auf dem Client sein. Dass auf dem Client ein HTTPS-Datenstrom problemlos decodiert werden kann, zeigt z.B. das Werkzeug Fiddler. Ein Trojaner könne aber auch ein Stammzertifikat installieren und so jemand auf dem WAN eine "Man in the Middle" Attacke ermöglichen, wenn Geheimdienste etc. sich nicht gleich ein Zertifikat von einer "Trusted Root" ausstellen lassen. Die meisten Zertifizierungstellen sind nun mal in den USA beheimatet.

Eine Möglichkeit diese Risiken zu reduzieren wäre die Vergabe von Kennworten für eine Applikation und einen ganz genau beschrieben Datenzugriff. Um z.B. Mails abzuholen, könnte eine eigene Anmeldeinformation genutzt werden, die nur auf das Postfach zugreifen darf aber z.B. kein VPN, kein OWA und auch sonst keine anderen Dienste nutzen kann. Zu beachten ist:

  • Der Server muss solche Alternate Credentials unterstützen,
    Exchange gehört nur bedingt dazu. für den Zugang zur VoiceMail per PIN hat Microsoft nämlich schon immer so eine alternativen Authentifizierung vorgesehen. Dies gilt aber nicht für ActiveSync, POP3, IMAP4 o.ä.
    PRTG hingegen hat genau so einen "Zweitzugang", bei dem man sich mit einem Passwort-Hash am Monitoring-Server anmelden kann. Wer diese Daten angreift könnte zwar genau das gleiche bezüglich PRTG tun, aber hätte keinen Zugriff auf das AD-Kennwort
  • Verwaltung des alternativen Kennworts
    Der Benutzer müsste eine Möglichkeit haben, dieses alternative Kennwort einzusehen und ggfls. auch zu ändern.
  • Proxy
    Wenn der Service selbst keine alternativen Credentials unterstützt, könnte eine Firewall oder ein Proxy vielleicht die Authentifizierung des Clients anfordern und dann "on behalf" die Daten vom Backend beziehen. Leider kenne ich bislang noch keinen solchen Proxy.

Der Vorteil einer solchen alternativen Anmeldung für bestimmte Funktionen könnte natürlich auch sein, dass diese in einem Programm hinterlegten Zugangsdaten gerne auch komplex sein können und vor allem z.B. seltener geändert werden müssen. Weiterhin könnte der Server unterscheiden, ob sich der Anwender mit den "echten" oder den alternativen Anmeldedaten authentifiziert und damit die Aussperrung von Konten anders behandeln.

Abhilfe - Shadow-Daten / Reduzierte Daten

Eine andere Überlegung wäre es, die relevanten Daten aus dem Live-System in ein "Schattensystem" zu spiegeln. Stellen Sie sich vor die Replizieren z.B. die Mails der letzten 30 Tage vom internen primären Postfachserver auf einen zweiten Server, der eigene Zugangsdaten hat. für Mails gibt es durchaus einige Tools, die z.B. per IMAP4 die Daten zwischen Postfächern Synchron halten. Der Anwender könnte dann auf den reduzierten Datenbestand des externen Servers mit eigenen Zugangsdaten zugreifen.

Zudem würden auf dem externen Server dann natürlich nur die Postfächer mit angelegt, die auch externen Zugriff benötigen. Alle anderen Postfächer müssten nicht angelegt werden. Allerdings hat das dann auch wieder Auswirkungen auf die Einträge in der GAL. Natürlich müsste auch geklärt werden, ob es nur eine "OneWay"-Replikation ist oder Elemente, die der Anwender dann auf dem externen System ändert, auch wieder zurück repliziert werden. Das gilt insbesondere für neu verfasste Mails, Anlagen, Kennzeichnungen aber auch Termine, Kontakte, Aufgaben etc. Jede Replikation hat das Risiko von Replikationskonflikten.

Sie sehen, dass der Gedanke eine Teilmenge als Replikat für externe Zugriffe bereit zu halten durchaus nicht unproblematisch ist.

Überlegungen zur Umsetzung

Aus meiner Sicht ist es weniger wahrscheinlich, dass Mails auf ein zweites System repliziert werden. Das dürfte für viele andere Daten vergleichbar sein, das jede Duplizierung neben der Arbeit und Konflikte natürlich auch Server, Speicherplatz und Lizenzen benötigt. Es mag sicher auch Daten geben, z.B. ausgewählte Dokumente, die so extern bereit gestellt werden sollen, aber in der Regel haben Administratoren genug damit zu tun, einen Datenbestand zu betreiben. Also bleibt die Frage, wie man den Zugriff auf diese Daten mit einem alternativen Konto erreichen kann, wenn der Service selbst dies nicht ermöglicht. Und da gibt es aus meiner Sicht zwei Optionen:

  • Zweitkonto mit Rechten
    Ich könnte einfach ein zweites AD-Konto anlegen, was deutlich weniger Rechte hat und dieses Konto dem Anwender bekannt machen. Verhindert man dann noch auf der Firewall z.B. dass der Anwender mit dem primären Konto arbeitet, so muss er mit dem sekundären beschränkten Konto auf die Ressourcen Zugreifen.
  • Application Proxy
    Ein speziell auf die Applikation bzw. das Protokoll abgestimmter Proxy nimmt die Authentifizierung mit eigenen Daten vor und greift dann mit einem Dienstkonto nach hinten auf den eigentlichen Service zu. Der Proxy müsste also nur wissen, wie er die Anfragen annimmt, die Authentifizierung voranstellt, sich dann "on behalf" am Backend anmeldet und dann die Befehle (fast) einfach durchreichen. Natürlich müsste schon sichergestellt sein, dass das Backend auch nur die Daten liefert, die diese Benutzer bekommen darf.

Kommen wir mal auf die Ausgangssituation zurück, bei der ein vielleicht nicht vertrauenswürdiges System auf ein IMAP4 Postfach zugreifen soll und dabei nicht das Kennwort des Anwenders verwenden soll, welches dem Anwender dank "Single SignOn" die Türen zu allen Daten öffnet. Die Option mit dem "Zweitkonto" ist durchaus möglich. Man legt ein zusätzliche Active Directory Konto, z.B. "Username-IMAP4" mit einem Kennwort an und erlaubt diesem Benutzer nichts anderes, als sich als Stellvertreter auf ein Postfach anzumelden. Da die Exchange GuI die Vergabe eines Rechts nur für Benutzer erlaubt, die selbst ein Postfach haben, müssen Sie dies per PowerShell machen.

Add-MailboxPermission `
   -Identity <Mailbox> `
   -User imap4user `
   -AccessRights FullAccess

Der Anwender muss nur noch die Anmeldedaten im IMAP4-Client mit "Domain\User\Alias" angeben.

Allerdings muss der Anwender natürlich auch dieses alternative Konto nutzen und es ist ebenfalls ein "Domain Benutzer". Sie sollten also schon sicherstellen, dass ein "Domain Benutzer" nicht auch zu viele Default-Rechte hat.

Die andere Option wäre ein IMAP4-Proxy, der neben der SSL-Funktion auch eine Authentifizierung durchführen muss. Erst nach erfolgter Anmeldung mit abweichenden Anmeldedaten könnte er dann ähnlich der obigen Funktion mit einem privilegierten Konto das eigentliche Postfach öffnen. Der Proxy müsste dann einfach nur noch die IMAP4-Befehle 1:1 durchreichen. Allerdings ist auch das nicht ganz richtig, denn er müsste schon Befehle abfangen, mit denen Ein Wechsel in eine andere Mailbox möglich wären. Der Exchange Server kann die Anwender ja nicht unterscheiden. Zudem müssten Sie natürlich das Thema "Password-Management" lösen.

Ein deutlich erweiterter Ansatz ist natürlich die umgehung des Exchange IMAP4-Diensts hierfür durch einen eigenen IMAP4-Server, der im backend z.B. per MAPI oder EWS auf die Postfächer zugreift. Interessanterweise gibt es da sogar schon ein OpenSource-Projekt, welches dem ein oder anderen Exchange Admin vielleicht schlaflose Nächte bescheren kann, Mit DavMail (http://davmail.sourceforge.net/) gibt es schon einen Proxy, der Client per IMAP4 antwortet und hinten gegen Exchange per EWS die Daten holt. Allerdings erwartet DavMail die Konfiguration der Benutzer mit Kennwort und kann nicht mit EWS-Impersonation umgehen, was die Verwendung als IMAP4 Proxy mit eigenen Anmeldedaten pro Benutzer nicht möglich macht.

Ich will App Passworte!

Jede Lösung hier ist aber immer von dem verwendeten Protokoll abhängig. Im Zeichen von immer mehr Apps und teils "unbekannten" Zugriffen wäre aus meiner Sicht ein zusätzliches Kennwort pro Dienst für die Verwendung in Apps eine durchaus interessante Option, die Hersteller sicher einfach einbauen könnten. Exchange hat es mit der PIN für "Unified Messaging" schon vorgemacht.

Nebenbei kann so ein gesonderter Zugang von dem speziellen System natürlich auch die Belastung der Anmeldedienste des DCs reduzieren (DoS) als auch das Sperren des Hauptkontos durch zu viele Fehlversuche vermeiden. Das System selbst sollte natürlich selbst auch zu viele Fehlversuche durch Drosseln oder temporäres Sperren bestrafen und den Anwender per Mail über den Vorfall darauf hinweisen.

Insofern würde ich mich freuen, wenn ich jeder Anwendung, die Kennworte "speichert"  ein eigenes App-Kennwort zuweisen könnte und mein primäres Zugangsverfahren weniger gefährdet ist oder sogar z.B. durch Zwei-Faktor-Verfahren sicherer (und unbequemer) ist.

App Password bei PRTG

Eine Musterapplikation dabei ist z.B. PRTG. Es unterstützt eine Anmeldung per Hashwert neben der "normalen" Anmeldung.


Hinweis: Die Daten hier sind nicht aus einem realen System.

So muss sich auf der App des Mobilgeräts nicht meine AD-Daten hinterlegen und wenn dieser Hashwert doch mal abgehört wird, dann ist nicht gleich mein Postfach, mein VPN-Zugang, das RDP-Gateway etc. offen. Das gilt um so mehr, wenn bestimmte Tätigkeiten mit einem privilegierten Konto durchgeführt werden müssen, weil das "normale" Konto keine Rechte dazu hat.

App Password bei Microsoft Konto

Als ich das letzte mal mein Microsoft Konto bearbeitet habe, habe ich auch hier die Option gehabt mich mit einem starken Verfahren anzumelden. In der Folge konnte ich dann eigene App-Kennworte für ein Windows 8 Phone und andere Applikationen hinterlegen:

Ich habe noch nicht verifiziert, ob Microsoft die Kennworte dann wirklich mit der ersten Verbindung an einen "Zugang" bindet. Das Kennwort, welches ich in Outlook für den Hotmail-Zugang nutze, konnte ich auch auf dem PDA für den Mailzugang erneut nutzen. Eine Anmeldung an accout.live.com oder SkyDrive war aber nicht möglich. Anscheinend unterscheidet Microsoft schon den Client. Weitere Informationen habe ich dazu nicht gefunden.

App Password bei Office 365 und Azure

Durch den Zukauf der Firma "PhoneFactor" hat Microsoft auch für die Office 365 Cloud eine Zwei-Faktor-Authentifizierung erhalten, die denkbar einfach zu installieren ist.

App Passworte bei Twitter

Wenn Sie sich genau umsehen, dann finden Sie sogar mehr und mehr Webseiten, die pro Applikation Berechtigungen verteilen. So z.B. bei Twitter. Natürlich hat ein Anwender auch einen Anmeldenamen und ein Kennwort für die Nutzung von Twitter aber es wäre doch unsicher diese Anmeldedaten bei den verschiedenen Apps und Clients fest zu hinterlegen. Stattdessen gibt es eine API dass Sie auf dem Client sich einmal mit dem Kennwort anmelden und dieser von Twitter dann ein "Token" bekommt, welches die App weiter nutzen kann, selbst wenn Sie ihr Twitter Kennwort ändern. Damit gewinnen gleich alle:

  • Ihr Kennwort muss nicht in der App gespeichert werden
  • Das Token ist für diese App spezifisch
  • Sie können in Twitter das Token für eine einzelne App auch wieder deaktivieren

In den Kontoeinstellungen von Twitter können Sie unter https://twitter.com/settings/applications genau sehen, welche App ihr Twitter-Konto nutzen darf.

Und hier können Sie je App den Zugriff auch deaktivieren.

Weitere Links