Multi Faktor Authentifizierung (MFA)

Wer beim Zugang zu Systemen nur auf Benutzername und Kennwort vertraut, ist nur bedingt sicher. Erschreckend viele Anwender lassen sich diese Daten einfach entlocken und damit ist der Zugang für den Angreifer offen. Eine Zwei Faktor Authentifizierung und eigene "App-Kennworte" sind die Antwort auf diese Herausforderung.

Die Forderung nach einer MFA ist nicht nur für hochsichere Firmen aktuell. Der normale Anwender ist in der Regel sehr unvorsichtig bzw. leichtgläubig bezüglich der Preisgabe seines Kennworts.

MFA und Device Authentication wird gerne zusammen gefasst, indem sich ein Benutzer nur auf einem zugelassenen gerät anmelden kann. Das Gerät ist quasi der zweite Faktor. Bei MFA geht es aber primär darum, dass die Anmeldung des Benutzers mit einem weiteren Kriterium gesichert wird, damit ein ausgespähtes Kennwort nicht alleine genutzt werden kann, egal ob dies nu auf einem fremden oder prinzipiell zugelassenen Gerät passiert.

Ich hab hierzu einige weitere thematisch verwandte Seiten 

Azure Multi-Factor Authentication 
https://channel9.msdn.com/Series/Azure-Multi-Factor-Authentication/

Kennworte und der zweite Faktor

Die meisten Firmen haben heute schon eine Multi Faktor Authentifizierung  im Einsatz, ohne es explizit zu wissen. Wer heute ActiveSync mit dem Smartphone nutzt und das Telefon mit einer PIN sichert, hat zumindest diesen Zugang schon mit zwei Faktoren gesichert. Ein Angreifer muss das Gerät in Händen halten und die PIN wissen, ehe er an die Daten kommt. Aber das ist dennoch nur die halbe Wahrheit, wenn wenn ich dies habe, dann ist es nur ein kurzer Weg zum auf dem Gerät hinterlegten Kennwort. Wenn ich als Angreifer auf so einem Gerät ein eigenes Root-Zertifikat, z.B. von Fiddler oder eines anderen Proxy-Servers installieren kann, kann ich den HTTPS-Verbindungsaufbau entschlüsseln und in den meisten Fällen das Kennwort erhalten. Ziel muss also die Sicherung des Service sein und nicht allein der Client.

Es gibt schon lange Zwei-Faktor-Verfahren, z.B. über Zertifikate mit Smartcard und Pin oder die Token-Lösungen mit Einmalschlüsseln (z.B. RSA) oder entsprechende Software, die auf dem Smartphone einmal Codes generiert, z.B.

Dies ist aber wieder nur die Seite auf dem Client. Um als Firma selbst vergleichbares einzusetzen, war bislang immer die Installation und der Betrieb entsprechender Server erforderlich. Zumindest wurde mittlerweile ein RFC veröffentlicht, so dass nicht jeder Hersteller sich eine eigene vielleicht unsicherer Logik entwickelt

Zwei Faktor Authentifizierung in der Cloud

Auch die Cloud-Anbieter haben reagiert und bieten in vielen Fällen eine Multi Faktor Authentifizierung an. Hier ein paar Beispiele

Angebot MFA Beschreibung

Google

Ja, nach RFC 6238

Durch den Benutzer aktivierbar
https://myaccount.google.com/?pli=1
http://de.wikipedia.org/wiki/Google_Authenticator

Microsoft Konto
Vormals Passport, LiveID

Ja, nach RFC 6238

Durch den Benutzer aktivierbar
https://account.live.com/proofs/Manage

Office 365

Ja, Phonefactor

MFA Office 365
MFA Benutzer

Der große Vorteil einer Multifaktor-Authentifizierung ist nicht nur der Sicherheitsgewinn für Anwender und Anbieter. Das eigentliche Kennwort ist nicht mehr die alleine Information und so kann die Komplexität des Kennworts als auch die Änderungshäufigkeit reduziert werden. Sollte das dann Kennwort tatsächlich von einem Angreifer ermittelt werden, dann hat er immer noch nicht den zweiten Faktor. Sollte dann ihr Dienst z.B. diesen zweiten Faktor als SMS versenden, bekommt der eigentliche Besitzer der Information sogar noch mit, wenn "etwas" eine Anmeldung versucht und kann damit den Account als kompromittiert erkennen und das Kennwort ändern. Bei der klassischen Anmeldung erkennt der Anwender selbst erst einen Missbrauch, wenn Daten anderswo auftauchen, gelöscht oder verändert werden oder jemand anderes die übernommene Identität anderweitig verwendet.

Wichtig ist natürlich, dass der zweite Faktor auch wirklich getrennt wird. Es macht wenig Sinn, wenn Sie auf einem PC das Kennwort im Browser hinterlegt haben und die SMS auf der UMTS-Karte des gleichen Endgeräts ankommt. Ein Dieb hat dann beides auf einmal. Eine SMS kann relativ einfach abgehört werden und wenn zukünftig immer mehr Dienste auch die Replikation von "Nachrichten" über die Cloud unterstützen, dann ist die Meldung vielleicht auch beim Dieb.

Wer einen Kontrollanruf über eine Rufnummer nutze, sollte natürlich daran denken, dass auch Telefone "umgeleitet" werden können. Vor allem sollte das Ziel dann kein Lync-Endpunkt sein, der mit der gleichen Anmeldung funktioniert. Sie können sehr schlecht einen Anruf mit Lync anmelden, wenn der Client gerade in der Anmeldung steckt.

Auch sollten Sie vielleicht nicht alle Konten über diese doppelte Anmeldung führen. Sollte das System gestört sein, z.B. durch einen Angriff auf das SMS-System oder andere Störungen, dann sollte ein Account es zumindest erlauben, die Multifaktor-Authentifizierung temporär zu deaktivieren. Es gibt also durchaus die ein oder andere Besonderheit zu beachten.

Zwei Faktor Authentifizierung mit Office 365

Mit Office 365 können Sie eine Multi Faktor Authentifizierung  dies mit wenigen Maus-Klicks umsetzen. Das funktioniert sogar für alle drei Typen von Anwendern.

Azure Konto Beschreibung Verhalten

Cloud Benutzer

Diese Anwender sind in Office 365 angelegt und nutzen auch dort ein Kennwort

Anwender gibt den Benutzernamen (UPN) ein und der Browser wird auf den Anmeldeserver von Office 365 umgeleitet, um das Kennwort einzugeben. Danach erfolgt die Eingabe des zweiten Faktors

DirSync-User mit eigenem ADFS

Diese Anwender werden von einem On-Premises-AD mit der Cloud synchronisiert und melden sich über einen ADFS-Server On-Prem an

Anwender gibt den Benutzernamen (UPN) ein und der Browser wird auf den ADFS-Server des Kunden umgeleitet, um das Kennwort einzugeben. Danach erfolgt der Rücksprung zur Cloud, welche dann die Eingabe des zweiten Faktors erzwingt, ehe der Zugriff auf den eigentlichen Dienst möglich ist.

DirSync-User mit Azure ADFS

Wer das Azure AD Premium nutzt, kann einen dort betriebenen ADFS-Server zur Authentifizierung einbinden.

Verhalten entspricht dem vorherigen Weg mit dem unterschied, dass der ADFS-Server von Microsoft betrieben wird.

Anwendungsintegration und App-Kennworte

Die Eingabe eines zweiten Faktors gelingt sinnvoll nur, wenn der Anwender interaktiv sich an dem Dienst anmeldet. Das kann ein Browser sein oder ein Eingabedialog beim Start des Programms. Hier wird dies vom Anwender auch noch toleriert. Schwieriger wird es, wenn der Anwender mehrere Programme startet und jedes mal sich mit zwei Faktoren anmelden muss. Ein "Single-SignOn" ist hier dringend anzuraten, um die Akzeptanz zu erhalten.

Mit Office 365 ist das relativ einfach möglich, da der Anwender sich ja nicht direkt an einem Dienst anmeldet, sondern der Dienst den Anwender zum Anmeldeserver (ADFS) sendet und sich so ein Anmeldeticket holt. Alle Dienste, die diesem Ticket nun vertrauen, können direkt vom Anwender genutzt werden, zumindest solange diese in der gleichen Browsersession betrieben werden.

Aber es gibt natürlich auch Programme, die sich nicht eines Browsers bedienen und keine Unterstützung für eine Multifaktor-Authentifizierung haben oder eine solche nicht sinnvoll nutzbar ist. Dazu zählen z.B. OneDrive Business, Lync Telefone oder ActiveSync auf Smartphones. Diese nutzen aber das Konto des Benutzers und hierfür gibt es bei den meisten Systemen die Option, eigens "App-Kennworte" zu vergehen. Das sind lange Kennworte, Office 365 nutzt dazu 16 Buchstaben, die man nie in einem Kennwortdialog jedes mal eingeben möchte. Sie sind aber wunderbar zur einmaligen Eingabe für solche Applikationen. Wenn also ein "Nicht Browser"-Client sich am Authentifizierungsdienst anmeldet, dann lässt er auch die Anmeldung mit solch einem App-Kennwort ohne weiteren Faktor zu.

Anwendungen und MFA

Die Aktivierung von Multifaktor-Authentifizierung hat unterschiedliche Auswirkungen auf die Clients. Alle Zugriffe über einen Webbrowser sind in der Regel problemlos. Interessant sind also eher Programme, die über eine AIP zugreifen.

Programm MFA Bemerkung

SharePoint Zugriff per Browser

OK

 

Onedrive Business

AppPassword

 

Sharepoint Designer

 

OWA Zugriff per Browser

OK

 

OWA für IPad

 

 

ActiveSync / EAS Clients

AppPassword

 

Office 2013 (Win)
(Outlook, Excel, Lync, Word)

AppPassword

Mit dem Nov 2014 Updates wurde die MFA-Unterstützung verteilt, ist aber noch nicht aktiv.

Outlook 2011 Mac

 

 

Office 2013 (IOS)

OK

Ab Okt 2014 Update 

Office 2013 (OS X)

OK

Ab Okt 2014 Update 

Azure WebSeite

OK

 

Office 365 PowerShell

Nicht möglich

Laut http://blogs.office.com/2014/02/10/multi-factor-authentication-for-office-365/ kann die PowerShell nicht mit AppPasswords genutzt werden.

 

MFA Lizenzierung und Funktionen

Auf der Seite Multi-Factor Authentication für Office 365 (http://msdn.microsoft.com/en-us/library/dn383636.aspx) gibt es eine wichtige Tabelle, welche MFA-Funktionen in welchem Paket enthalten sind. Es gibt hier nämlich drei Stufen

  • Office 365 Subscription
    Die hierunter aufgelisteten (und auf der MSXFAQ beschriebenen) Funktionen stehen allen Kunden und Nutzern einer Office 365 Subscription ohne weitere Kosten zur Verfügung.
  • Azure Subscription
    Wer eine Azure Subscription z.B. für das Hosting von WebServices oder VMs in der Cloud abgeschlossen hat, kann hier für die Azure Administratoren ebenfalls MFA nutzen
  • Azure Multi-factor Authentication
    Allerdings bietet Microsoft noch eine erweiterte Funktion von MFA an, die aber gesondert zu lizenzieren ist.

Die normale MFA-Funktion für Office 365 Anwender und Azure Administratoren ist in den meisten Fällen schon viel mehr, als die Mehrheit der Firmen heute On-Prem nutzen.


Quelle: http://msdn.microsoft.com/library/azure/dn249471 (Jan 2015)

Azure MFA erweitert die Funktionen aber z.B. Um:

  • Eigene Ansagen und Rufnummernanzeige beim Telefonanruf
  • TrustedIP
    Damit können Sie z.B. die IP-Adresse ihrer Firmenstandorte Allowlisten, damit beim Zugang auf die Cloud aus internen Netzwerken kein zweiter Faktor erforderlich ist.
  • Fraud Alert
    Wenn jemand das Kennwort eines Anwenders können sollte und sich so anmeldet aber der zweite Faktor nicht stimmt, dann bekommt der Mitarbeiter und z.B. die Security Abteilung eine Information über einen möglichen Einbruchsversucht
  • MFA für On-Prem
    Die "große Version" von MFA erlaubt ihnen auch die Installation des MFA-Connector auf ihren lokalen Servern, um dann auch lokale oder interne Applikationen entsprechend zu schützen.

Die Funktionen sind im Azure AD Premium enthalten, welche über eine EA-Vereinbarung lizenziert werden kann. Insofern sind die Preise abhängig von Rabattstaffeln und bestehenden Verträgen. Auf der Azure WebSeite werden aber dennoch Preise genannt:


Quelle: http://azure.microsoft.com/de-de/pricing/details/multi-factor-authentication/  Stand Jan 2015

Wenn ich es richtig verstanden habe, dann wird aber durch die Aktivierung dieser Funktion über Azure ab dem ersten Benutzer die Basis-MFA-Funktion von Office 365 und Azure für alle nicht lizenzierten Anwender entfernt. Sie müssen dann wohl alle Anwender lizenzieren, die MFA nutzen sollen. Allerdings ist das Angebot immer noch sehr interessant aus meiner Sicht, wenn sie schon die Verbindung zu Office 365 haben. für knapp 1€/Monat betreiben Sie sicher keinen eigenen Server mit einem 3rd Party Software und einen zusätzlichen Hardwaretoken.

Selbst Firmen die bislang gar nichts mit Office 365 am Hut haben, könnten sich einfach nur die MFA-Funktion für ausgewählte Personen dazu kaufen.

MFA mit "On-Prem Lösungen"

Firmen, die bereits eine eigene Infrastruktur für einen zweiten Faktor nutzen, können natürlich auch Office 365 damit absichern. In der Cloud muss dazu aber gar nichts geändert werden. Es ist nur erforderlich, dass Sie die Anmeldung mittels einem, ADFS-Server ausführen, den sie selbst On-Prem oder z.B. als VM in Azure mit der gewünschten Verfügbarkeit bereit stellen und den Zugang auf diesen Server mit ihrer eigenen MFA-Lösung absichern. Entsprechende Module können Sie von den Drittherstellen beziehen und im ADFS-Server integrieren.

Wenn ein Hersteller noch kein Modul für den ADFS-Server bereit stellt, dann können Sie natürlich auch den Zugang über einen Reverse-Proxy davor absichern, d.h. der Client kommt erst dann zum ADFS-Server, wenn er sich an Reverse-Proxy mit ihrer eigenen MFA-Lösung authentifiziert hat. ADFS selbst bietet zumindest Clientzertifikate als weiteren Faktor an

Wenn Sie dies so aktivieren, dann müssen die oben aufgeführten Benutzer oder Mitglieder von Gruppen ein Zertifikat zusätzlich vorweisen. Sie melden sich am ADFS-Server also erst per Benutzername und Kennwort an und dann fordert ADFS das Zertifikat an.

Das MFA aus dem Azure AD liefert auf jeden Fall auch so ein Modul mit. Damit können Sie ihren On-Prem-ADFS-Server mit MFA-Funktionen ausstatten und damit Dienste besser absichern, die gar nicht bei Office 365 laufen.

Windows Azure Multi-Factor Authentication Server
http://channel9.msdn.com/Blogs/Windows-Azure/Windows-Azure-Multi-Factor-Authentication-Server

Windows Azure Multi-Factor Authentication Overview
http://channel9.msdn.com/Blogs/Windows-Azure/WA-MFA-Overview

Windows Azure Multi-Factor Authentication
http://channel9.msdn.com/Blogs/Windows-Azure/Windows-Azure-Multi-Factor-Authentication

Kemp Webcast: Securing Exchange and Lync 2013 with Multi-Factor Authentication
https://www.youtube.com/watch?v=bXQaGvbt4VI

Weitere Links