GUIDs und Authentifizierung

Dieser Artikel entstand aufgrund einer Anfrage eines Interessenten, wie "sicher" denn die Verwendung von GUIDs beim Anfordern von archivierten Mails (Siehe auch exchange@PAM) ist und welche Schwachstellen zu beachten sind. Auch andere Archivsysteme nutzen keine explizite Authentifizierung am Archiv.

Der Regelfall

Normalerweise werden Informationen in einem Netzwerk durch entsprechende Zugangsberechtigungen gesichert, die direkt bestimmten Benutzern oder über Gruppen vergeben werden. Der Anwender selbst identifiziert sich gegenüber dem System über Benutzername, Kennwort oder stärkere Authentifizierungsmaßnahmen (Smartcard, Token, TAN etc.). Diese Verfahren ist so sicher, wie eben Benutzername und Kennwort nicht erraten oder erspäht werden können und soweit eine heterogene Umgebung diese Anmeldung ohne weitere Probleme zulässt.

Die „Probleme“ einer Authentifizierung

Was prinzipiell richtig ist, kann in verschiedenen Situationen aber kompliziert und umständlich werden. Hier gibt es mehrere Beispielen.

  • Inhomogene Authentifizierung und Single Sign On
    Oftmals müssen mehrere Systeme miteinander zusammen arbeiten, welche aber nicht auf den gleichen Anmeldeprozessen basieren. Das kann auf Seite des Betreibers bedeuten, dass für Benutzer mehrere Konten verwaltet werden müssen, während die Anwender ihr Kennwort synchron halten müssen. Oftmals kommt dazu, dass eine Clientanwendung oft nur eine Anmeldefunktion unterstützt und eine zweite Anmeldung an einem anderen System gar nicht erst möglich ist
  • Unterschiedliche Berechtigungen
    In eine ähnliche Richtung gehen Zugriffrechte, die auf einem Element in einem System angewendet werden aber in ein anderes System nicht ohne Medienbruch übertragen werden können. Während NTFS sehr detailierte Berechtigungen vorsieht, unterstützen einige Unix Filesysteme nur „World/Group/user“. Berechtigungen auf CDs oder DVDs sind gänzlich unbekannt. Auch solche Fälle muss eine Anwendung berücksichtigen
  • Anmeldelast
    Wenn eine Verbindung von einem Client zu einem Server nicht aufrecht erhalten wird (TCP-Livetime) dann muss nach einem Verbindungsabbau der Client sich erneut anmelden und der Server diese Anmeldung auch überprüfen. Dies kostet Performance und belastet den Anmeldeserver. Hier sind zumindest kurzzeitige Caches angebracht oder z.B.: Zwischenspeicherung der Session (Session Cookies)
  • Hochverfügbarkeit
    Nutzt eine Anwendung die Anmeldung an einem Server (z.B. WebServer) dann kann der Einsatz einer Serverfarm mit NLB oder eines Load Balancers dazu führen, dass der Client sich mehrfach anmelden muss, da ein Webserver in der Regel keinen Abgleich der Anmeldungen mit seinen Farmpartnern durchführt. Ein effektiver Einsatz ist hier also nur möglich, wenn eine Session immer auf einem System bleibt. Ein umschwenken im Fehlerfall oder eine Lastverteilung ist dann nicht einfach möglich.
  • „Kennwortsicherheit“
    Nicht alle Systeme Verschlüsseln das Kennwort oder übertragen dieses sicher. Wird solche eine Verbindung abgehört, dann ist nicht die komplette Identität des Benutzers kompromittiert.
    Wenn der Internet Explorer dies noch zulassen würde, dann würde auch folgender Link denbar sein: http://user:password@owa.firma.de/exchange/postfachname/Posteingang/betreff.eml. Dieser Link sollte aber nun nicht mehr öffentlich werden, da er jedem den Zugriff auf die Information gewährt und sogar die Zugangsdaten den Zugriff auf andere Elemente erlauben.
  • Beständigkeit
    Benutzernamen, Kennworte, Abteilungszugehörigkeitem und sogar Firmenzugehörigkeiten ändern sich relativ häufig. URLs hingegen können über eine lange Zeit Bestand haben, wenn Zugriffe z.B.: über Aliasnamen erfolgen. So ist ein Zugriff per OWA auf eine Mail im Postfach über „http://owa.firma.de/exchange/postfachname/Posteingang/betreff.eml“ zwar sicher, da eine Anmeldung erfolgen muss, aber für ein Archivsystem nicht gut geeignet. Wird die Mail gelöscht, verschoben oder der Betreff verändert, ist der Zugriff unterbrochen. Ein Zugriff über eine eindeutige permanente Objektkennung wäre hier besser.
    Eine Besonderheit sind nun natürlich Systeme, die aus einem primären Speicher Objekte rausholen und auf einem anderen Speicher ablegen. Damit der Zugriff hier weiter möglich ist, wird an der alten Stelle ein "Link" hinterlassen, welcher natürlich über Jahre hinweg funktionieren muss.

Aus diesen Gründen nutzen sehr viele Programme die Möglichkeit, den Zugriff über mehr oder weniger kryptische Zeichen zu gestalten. Besonders beliebt sind dabei GUIDs, d.h. "Global unique IDs".

Beispiele für URLs mit GUID

Mehrere Firmen nutzen die Möglichkeit, dass der Anwender sich nur einmal oder sogar gar nicht gesondert authentifizieren muss, indem der Anwender entweder direkt eine personalisierte URLs oder eine generische URL bekommt

  • Microsoft Downloads:
    Beispiel: http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=46f72df1-e46a-4a5f-a791-09f07aaa1914
    Solche Links können sehr lange halten oder auf neue Versionen umgelenkt werden, selbst wenn sich Produktnamen, Zuständigkeiten etc. ändern.
  • 1und1 Konfiguration mit SessionKey
    Melden Sie sich einmal an der Konfigurationsseite von 1und1 an. Sie werden erkennen, dass oben in der URL ein Sessionkey "drin" ist, der allerdings eine bestimmte Zeit lang gilt.
  • GMX Mailpostfach mit „SessionKey“
    Auch die Nutzung eines GMX-Postfachs arbeitet so
  • Youtube
    Auch Links auf die Video sind einfach nur Links auf eine Art Indexnummer. Allerdings ist diese sehr kurz. Die gleiche Funktion erfüllen Webseiten wie kickme.to, die lange Links in Kurze umsetzen.

Je nach Implementierung kann man auf die Inhalte zugreifen, wenn man „nur“ die URL komplett kennt oder der Zugriff funktioniert nur solange, wie der Server die Session als gültig anerkennt. Im Bezug auf die Sicherheit stellen sich zwei Fragen:

  • Wahrscheinlichkeit eines „Erraten" ?
  • Wie sicher ist die URL hinsichtlich "Ausspähung"

Sicherheit: Wahrscheinlichkeit eines „Erraten" ?

Ehe wir uns über das Erraten Gedanken machen, muss natürlich sichergestellt sein, dass eine GUID eindeutig ist. Die Eindeutigkeit ist auf Grund der Größe der GUIDs meiner Meinung nach als ausreichend wahrscheinlich anzusehen: Sie besteht aus 16 Byte (128 Bit), so dass es rund 3,4028236e+38 Werte (2 hoch 128) gibt. Selbst in einem Archivsystem mit 250 Mio. Elementen (2*28) wäre die Wahrscheinlichkeit einer Treffers immer noch 1: 2^100. Als Vergleich. Die Anzahl der Möglichkeiten beim Lotto (6 aus 49) sind weniger als 2^24. Da die GUIDs zentral generiert werden, ist es sogar möglich eine Dublette zu erkennen und zu umgehen.

Im Hinblick auf das „Erraten“ ist natürlich ebenfalls die immense Anzahl möglicher GUIDs ein sehr effektiver Schutz. Die Wahrscheinlichkeit, eine „passende GUID“ zu erraten ist in den meisten Fällen um vieles geringer, als die Wahrscheinlichkeit eine gültige Benutzername/Kennwort- Kombination zu erraten. Erst sehr komplexe Kennworte sind ähnlich schwer zu knacken. Wenn ein Angreifer so Zugriff auf das Postfach erhält, dann kann er natürlich alle Links auslesen und auch erreichen. Das Problem besteht aber ohne Archivierung ebenfalls.

Hinzu kommt, dass ein „Offline Cracking“ in der Regel nicht möglich ist, sondern ein potentieller Angreifer permanent das Zielsystem mit zufälligen URLs beaufschlagen muss. Es ist relativ einfach möglich, solche Angriffe zu erkennen (Logdateien des Webservers) oder mit Programmen zu verhindern, z.B.: indem die Anzahl der Anfragen pro Client pro Zeit limitiert wird.

Wie sicher ist die URL hinsichtlich "Ausspähung"

Anders sieht es natürlich aus, wenn die GUID oder die komplette URL „öffentlich“ wird. Normalerweise erhält nur ein bereits an einem System authentifizierte Benutzer überhaupt den Zugriff auf die Daten, um die URL mit der GUID zu erhalten. Hier ist wieder „Benutzername/Kennwort“ die primäre Schwachstelle.

Ohne gesonderte Authentifizierung muss der Zugriff auf die URL selbst gesichert werden, so dass die URL nicht auf dem Kabel abgehört wird. Gerade bei der Übertragung per http ist hier die Verschlüsselung mit SSL vorzuziehen, da ansonsten die Verbindungsdaten und Inhalte sehr einfach mitzuschneiden sind (z.B. mit Programmen wie Packetyzer, NetMon3, Cain&Abel und anderen).

Eine gewissen Sensibilität müssen natürlich auch die Anwender an den Tag legen. Wer eine URL mit einer GUID eines archivierten Elements an andere Personen weiter leitet, erlaubt diesen damit natürlich auch den Zugriff auf diese Information. Allerdings ist der Zugriff dann auf genau dieses eine Element beschränkt und nicht auf das komplette Postfach oder fremde Daten.

Ein solches Verfahren erlaubt sogar eine einfachere Nutzung eines Archivsystems, da der Anwender damit ein archiviertes Objekt nicht erst zurückholen muss, ehe er es weiter versendet. Als weiterer Schutz kann der Zugriff auf bestimmte Systeme oder Benutzer beschränkt werden. Damit kann jemand extern mit dieser URL nichts anfangen, da der Server nicht erreichbar ist.

Alternativen ?

Natürlich können Webserver immer noch zusätzlich eine Authentifizierung einführen, so dass nur der Besitzer einer Mail auch die Mail im Archiv lesen kann. Dies stört dann jedoch auch die Funktion, wenn eine archivierte Mail "weiter" geleitet wird. Enthält die Weiterleitung nur den Link in das Archiv, dann kann der Empfänger die Mail nicht lesen, da er zwar die URL hat aber keine Berechtigungen. Das Archivsystem kann nie erkennen, dass die Anforderung von jemandem kommt, der die Mail zurecht über eine Weiterleitung erhalten hat.

Die Verwendung von GUIDs habe aber noch weitere Aspekte. Die Funktion ist auf lange Jahre gewährleistet, selbst wenn zukünftig das Mailsystem gewechselt, die Anmeldefunktion (Active Directory) geändert oder der Client getauscht werden sollte. Die URLS werden weiter funktionieren. Selbst wenn der Mitarbeiter ausgeschieden ist, die Firma umorganisiert wurde oder andere Veränderungen die Basis einer Authentifizierung entzogen haben.