Authentifizierung, Autorisierung, CA, Credentials, DES, Hash, ID, Kerberos, Name, One-Time-Pad, PAM, Passwort, PKI, SASL, Shadow, Schlüssel, Single Sign-on, SSH, SSL, Ticket, TLS, TGS, TGT: Der folgende Artikel eignet sich als Wanderkarte durch den Begriffsdschungel.

Das morgendliche Ritual ist allseits bekannt: rein ins Büro, Computer einschalten und abwarten. Das Betriebssystem fragt als Erstes nach dem Benutzernamen und dem Passwort. Dann kann es losgehen – aber schon beim Lesen der Mail beginnt das gleiche Spiel von vorn, wieder sind Name und Passwort fällig. Surfen im Web erfordert manchmal die gleiche Prozedur, wenn der Proxyserver eine Authentifizierung verlangt.

Die Liste lässt sich beinahe beliebig fortsetzen. Datenbankserver, geschützter Bereich auf dem Webserver, Groupware – viele Dienste verwenden eigene Benutzerdatenbanken und Authentifizierungsprotokolle. Kein Wunder, dass sich die geplagten Benutzer eine Einmal-Anmeldung wünschen (Single Sign-on): Nach der Authentifizierung wollen sie auf alle ihnen zustehenden Ressourcen zugreifen, am liebsten ganz ohne die lästige Passworteingabe.

Admins legen mehr Wert auf ein sicheres Netz, das geht aber nicht ohne Authentifizierung. Außerdem wollen sie die Benutzerdaten unkompliziert und zentral verwalten. Wer diese drei Forderungen gleichzeitig erfüllen will, muss einiges über die Interna der Authentifizierung wissen.

Ob das Betriebssystem einen Zugriff erlaubt, hängt von den Rechten des Benutzerkontos ab. Dieser Schritt heißt Autorisierung. Vor dem Zugriff muss sich der Inhaber des Benutzerkontos ausweisen und seine Identität beweisen:

• Der Benutzer muss sich identifizieren, also mitteilen, welches
  Benutzerkonto er beansprucht. Aus dieser Identität (Name oder
  ID) ermittelt das System seine Berechtigungen.
• Ein Zeugnis (Credential) muss nachweisen, dass der User auch
  wirklich derjenige ist, der dieses Konto beanspruchen darf. Die
  übliche Technik zur so genannten Authentifizierung ist die
  Eingabe eines Passworts.

Der Ablauf ist in Abbildung 2 skizziert. Sowohl auf Einzelhosts als auch beim Verkehr im Netzwerk findet eine Kommunikation zwischen zwei Anwendungen statt: Ein Dienst (Server) soll den Zugriff auf Ressourcen bereitstellen und die Benutzeroberfläche oder Shell (Client) muss sich gegenüber dem Dienst mit den Credentials des Benutzers ausweisen. Shell meint in diesem Zusammenhang nicht nur die klassischen Linux-Shells, sondern allgemein ein Anwendungsprogramm, mit dem der Benutzer direkt kommuniziert.

Um zu beweisen, dass man derjenige ist, der man zu sein vorgibt – das Wesen jeglicher Authentifizierung -, gibt es verschiedene Techniken. Tabelle 1 stellt die Prinzipien zusammen. Jedes Verfahren berücksichtigt mindestens eines der dort genannten Merkmale.

Erkennungsdienst

Das traditionelle Verfahren benutzt Kennwörter, die nur den beiden beteiligten Partnern bekannt sein dürfen. Dann kann sich kein Dritter mit dem gleichen Passwort fälschlich als der berechtigte Benutzer ausgeben. Darin liegt auch die Schwäche dieses Systems: Hat jemand erfolgreich ein Passwort ausgespäht, hindert ihn nichts mehr daran, die falsche Identität anzunehmen.

Verschiedentlich geht noch die Sage um, Linux würde verschlüsselte Passwörter zwecks Authentifizierung speichern. In Wahrheit wird ein Passwort weder gespeichert noch verschlüsselt. Die Abbildungen 3a und 3b stellen die Zusammenhänge dar.

Ändern Admin oder Anwender ein Passwort, benutzt die »crypt()«-Funktion das neue Passwort als Schlüssel, nimmt einen zufällig gewählten Salt-Wert zwischen 0 und 4095 dazu und berechnet aus einer fest vorgegebenen Zeichenkette einen Hashwert.

Abbildung 1: In den meisten Firmen müssen sich die Benutzer gegenüber vielen Instanzen authentifizieren, schlimmstenfalls mit verschiedenen Namen und Passwörtern. Es gilt, die Verfahren, Protokolle und Accounts zu vereinheitlichen.

Abbildung 2: An einer Authentifizierung sind mindestens zwei Instanzen beteiligt: Der Benutzer und der Dienst, gegenüber dem er sich ausweist.

Hash mich

Den Hash legt das Linux-System als Credential in einer Passwort-Datenbank ab (Abbildung 3a), meist in »/etc/passwd« oder »/etc/shadow«. Im Unterschied zur Verschlüsselung ist die Hash-Berechnung nicht umkehrbar, die Einträge der Passwd-Datei sind also nicht entschlüsselbar. Der Algorithmus heißt daher auch Falltürfunktion (Trapdoor).

Der in Abbildung 3b gezeigte Handshake erlaubt es, ein neu eingegebenes Passwort zu prüfen ohne das Original zu kennen. Das Login-Programm unterwirft das neue Passwort der gleichen Prozedur wie in Abbildung 3a, vergleicht den neuen Hash mit dem gespeicherten Wert aus der Datenbank und gewährt bei Gleichheit den Zugang zum System.

Obwohl niemand die Passwörter entschlüsseln kann, ist das System anfällig für Brute-Force-Attacken. Der Angreifer probiert sehr viele Passwörter, schickt sie durch die gleiche Trapdoor-Funktion und vergleicht das Ergebnis. Die Credentials sind daher besonders zu schützen, als Minimum per Shadow-Suite. Die Hashwerte liegen dann nicht in der für alle Benutzer lesbaren Datei »/etc/ passwd«, sondern in der geschützten »/etc/shadow«.

Abbildung 3a: Das klassischen Passwort-Verfahren benutzt Hashing, um aus dem Passwort und dem zufällig gewählten Salt einen Credential-Wert zu berechnen und zu speichern. Dieser Vorgang heißt Trapdoor- oder Einweg-Funktion.

Abbildung 3b: Bei der Passwort-Authentifizierung berechnet das System aus dem angegebenen Passwort und dem gespeicherten Salt einen Hash und vergleicht ihn mit den gespeicherten Credentials.

Zudem empfiehlt sich ein stärkeres Hash-Verfahren als das herkömmliche DES (Digital Encryption Standard), das maximal 56 Bit (acht 7-Bit-Zeichen) für die Passwörter erlaubt. Sicherer arbeitet MD5 (Message Digest, Version 5), er gestattet bis zu 256 Stellen für das Passwort. Ein weiterer Angriffspunkt ist das Ausspähen des Passworts, entweder direkt auf dem Hostsystem oder während einer unverschlüsselten Übertragung. Dagegen helfen verschiedene Techniken, zum Beispiel Einmal-Passwörter in der Art der TANs bei Bankgeschäften.

Diese können zwar immer noch während der Übertragung ausgespäht werden, sind für den Angreifer jedoch wertlos, da sie nur für einen einzelnen Login-Vorgang gelten. Gefährlich wird es erst wieder, wenn ein Benutzer die Liste seiner Einmal-Passwörter auf der Arbeitsstation speichert und ein Angreifer an diese Liste herankommt. Mehr Information zu One-Time-Password-Systemen bieten[1],[2] und[3].

Schlüssel und Tunnel

Eine weitere Möglichkeit, Passwörter gegen das Mitlesen im Netz zu schützen, ist die verschlüsselte Datenübertragung. Grundsätzlich sind symmetrische und asymmetrische Verfahren zu unterscheiden (siehe Abbildung 4). Bei der symmetrischen Verschlüsselung benutzen beide Partner den gleichen Key. Diese Algorithmen arbeiten sehr schnell und eignen sich daher für große Datenmengen. Allerdings muss zuvor ein Schlüsselaustausch zwischen den Beteiligten stattfinden. Wenn jemand diesen Tausch abhört und den symmetrischen Schlüssel erfährt, kann er den Datenverkehr zwischen beiden Partnern problemlos entschlüsseln.

Solche Keys dienen deshalb meist als Sitzungsschlüssel, während für die Kontaktaufnahme und Authentifizierung asymmetrische Verfahren zum Einsatz kommen (Abbildung 4, unterer Teil). Der Client verschlüsselt dabei seine Daten mit dem öffentlichen Key des Servers, sodass nur dieser allein in der Lage ist, mit seinem (geheim gehaltenen) privaten Schlüssel den Datenstrom zu dechiffrieren.

Wichtig ist die Verbreitung der öffentlichen Schlüssel und deren Glaubwürdigkeit. Hierbei helfen PKIs (Public Key Infrastructures,[4]). Asymmetrische Verfahren sind – die nötige Sorgfalt vorausgesetzt – dann sehr sicher. Eine der bekanntesten Anwendungen ist die Secure Shell, unter Linux meist in Form der OpenSSH[5].

Jeder Host benötigt ein eigenes Schlüsselpaar aus privatem und öffentlichem Key, das meist schon bei der Installation der Software generiert wird. Bei dem einleitenden Handshake authentifiziert sich der Zielhost mit seinem privaten Schlüssel.

Der Client generiert anschließend einen Sitzungsschlüssel, verschlüsselt ihn mit dem öffentlichen Schlüssel des Servers und sendet ihn an den Server. Damit öffnet er einen sicheren Tunnel (Abbildung 5, Mitte), über den anschließend die Datenkommunikation abläuft. Die Benutzer-Authentifizierung erfolgt danach über einen Passwortdialog oder ebenfalls mittels asymmetrischer Kryptographie. Beide Versionen laufen über die gesicherte Verbindung des SSH-Tunnels und sind somit für Außenstehende nicht entzifferbar.

Abbildung 4: Bei symmetrischen Verfahren (oben) dient ein Key sowohl zum Ver- als auch zum Entschlüsseln. Die asymmetrischen Varianten (unten) benutzen dafür zwei verschiedene Schlüssel, einen privaten und einen öffentlichen.

Abbildung 5: Die Secure Shell verwendet asymmetrische Kryptographie, um den Server gegen den Client und den Benutzer gegen den Server zu authentifizieren. Beide Partner brauchen dazu ein eigenes Schlüsselpaar.

Sichere Shell

Nach der Authentifizierung stellt der Server dem Client eine Shell zur Verfügung. Das SSH-Protokoll hat noch viele weitere nützliche Funktionen, etwa Dateien sicher von Host zu Host transportieren, beliebige TCP-Protokolle tunneln oder X11-Oberflächen vom Server zur Arbeitsstation umlenken[6].

Ähnliche Authentifizierungstechniken setzt auch OpenSSL[7] ein. Es implementiert das Secure-Sockets-Layer-Protokoll und dessen Nachfolger TLS (Transport Layer Security, [8], [9]). SSL/TLS liegt zwischen der Transport- und der Anwendungsschicht von TCP/IP und ist daher gut in vorhandene Strukturen zu integrieren. Bekanntestes Beispiel ist die sichere Kommunikation mit Webservern (Abbildung 6). SSL-Techniken sind auch in anderen Serverdiensten implementiert, unter anderem für den Postempfang mit IMAPS (IMAP über SSL/TLS).

Der Webbrowser als Client generiert – wie von SSH bekannt – einen Sitzungsschlüssel und verschlüsselt ihn mit dem öffentlichen Key des Webservers. Diesen Schlüssel extrahiert er aus dem Zertifikat, das ihm der Server übermittelt hat. Es enthält neben dem Schlüssel weitere Informationen über den Server und ist von einer vertrauenswürdigen Stelle (CA, Certification Authority) unterzeichnet. Browser wie Mozilla und Firefox enthalten die Zertifikate der wichtigsten CAs bereits im Lieferzustand. Diese PKI-gestützte[4] Authentifizierung des Servers gegenüber dem Client entspricht der vierten Zeile in Tabelle 1.

Vertrauensfrage

Die asymmetrische Schlüsselverfahren bringen zwei Herausforderungen mit sich: Erstens müssen sie die Vertrauenswürdigkeit der öffentlichen Schlüssel sicherstellen. Das ist primär ein Problem der Organisation sowie der Infrastruktur und damit auch ein Kostenfaktor. Die Risiko- und Kostenanalyse muss hier besonders berücksichtigen, zu welchen Folgeschäden ein eingeschmuggelter Schlüssel führen kann – eventuell werden solche Manipulationen erst sehr spät bemerkt.

Abbildung 6: Bei HTTPS (HTTP über SSL) authentifiziert sich zunächst der Webserver gegenüber dem Browser. Danach benutzen beiden einen Sitzungsschlüssel, mit dem sie alle übertragenen Daten symmetrisch chiffrieren.

Die zweite Aufgabe ist der Schutz der privaten Schlüssel. Der potenzielle Schaden ist hier besonders groß. Der Schutz vor dem Ausspähen betrifft im Wesentlichen das sichere Speichern. Restriktive Zugriffsrechte auf die Datei oder entsprechende Bereiche einer Benutzerdatenbank verstehen sich von selbst.

Viele Implementierungen schützen private Keys mit einer Passphrase, die sich der Benutzer merken muss. Immerhin braucht er sie meist nur einmal einzutippen und darf den Schlüssel danach mehrfach benutzen, zum Beispiel wenn er den SSH-Agent benutzt. Ein solcher Schlüsselverwalter hält einen entschlüsselten Private Key im RAM, um ihn für weitere Authentifizierungsvorgänge einzusetzen.

Die Vielfalt der Authentifizierungstechniken trifft auf eine Vielfalt von Anwendungen und Protokollen, die eine Benutzerauthentifizierung verlangen. Um dem Admin die Wahl zu lassen, müsste jeder Dienst jedes Authentifizierungsverfahren implementieren. Das betrifft sowohl die so genannten System-Entry-Applikationen wie Login, Xdm/Kdm/Gdm oder »su«, zum anderen auch Netzdienste wie Mail- oder Webserver.

Die Vielfalt meistern

Der Aufwand ist nur dank PAM-Framework zu beherrschen[18]. Die Pluggable Authentication Modules trennen den Authentifizierungsvorgang von der Anwendung, die die Dienste von PAM nur nutzt. PAM ist modular aufgebaut und besteht aus diversen Bibliotheken, die je ein Verfahren umsetzen.

Einen weiteren Schritt Richtung Vereinheitlichung, diesmal bei den Netzwerkprotokollen, unternimmt SASL (Simple Authentication and Security Layer,[10]). In einem einheitlichen Framework einigen sich Client und Server zu Beginn einer Verbindung auf ein Authentifizierungsverfahren, das sie anschließend unabhängig vom Anwendungsprotokoll durchführen.

Abbildung 7: Bevor sich ein Kerberos-fähiger Client authentifiziert, holt er sich von der TGS-Komponente des Kerberos-Servers ein dienstspezifisches Ticket.

Bekannt ist vor allem die Cyrus-SASL-Implementierung[11]. Zunächst für den Cyrus-IMAP-Server entwickelt arbeitet sie beispielsweise auch mit dem SMTP-Server Postfix zusammen[12]. Cyrus-SASL lässt sich sogar mit PAM kombinieren. Die Implementierung von SASL ist allerdings oft kompliziert, besonders wenn einzelne Programme gegen verschiedene SASL-Versionen gelinkt sind.

Rundum geschützt

In bestehenden Netzen tummeln sich oft Anwendungen, die trotz aller modernen Techniken vertrauliche Informationen im Klartext durchs Netz senden. Mit Zusatzsoftware ist auch diesen ignoranten Applikationen beizukommen. Neben den bereits erwähnten SSL/TLS und SSH bietet sich vor allem IPsec (Internet Protocol Security) an[13]. IPsec arbeitet als Teil der IP-Schicht und ist folglich transparent für alle Anwendungen. Besonders mit der gelungenen Implementierung im Linux-Kernel 2.6 ist eine rasche Verbreitung zu erwarten[14].

In größeren und besonders schützenswerten Netzen kann sich der Einsatz von Kerberos lohnen[15],[16],[17]. Die grundlegenden Abläufe dieser aufwändigen Sicherheitsarchitektur sind in Abbildung 7 zusammengestellt. Meldet sich ein Benutzer an, sendet das Login-Programm eine Anforderung an das KDC (Key Distribution Center) auf dem Kerberos-Server.

Das KDC stellt ein TGT aus (Ticket Granting Ticket), das die Arbeitsstation in ihrem Credential- Cache ablegt. Das Ticket ist nur begrenzte Zeit gültig, meist acht Stunden. Es bildet die Grundlage für weitere Tickets, die der TGS ausstellt (Ticket Granting Service, ebenfalls auf dem Kerberos-Server).

Per Ticket authentifiziert sich der Benutzer bei beliebigen Kerberos-fähigen Diensten. Ein kerberisierter Dienst sucht zunächst auf der Arbeitsstation nach einem passenden Ticket. Nur wenn er nicht fündig wird, fordert er den Benutzer dazu auf, sein Passwort einzutippen. Damit ist echtes Single Sign-on möglich.

Alle Kerberos-Authentifizierungsprozesse laufen verschlüsselt ab, ein Ausspähen von Passwörtern ist nicht zu befürchten – vorausgesetzt, dass im gesamten gesicherten Netz kein Dienst Kennwörter ungesichert überträgt. Die größte Herausforderung bei Kerberos ist der Schutz des Kerberos-Servers selbst. Dessen Host braucht alle erdenklichen Sicherheitsvorkehrungen. Idealerweise läuft auf diesem Rechner außer Kerberos kein anderer Dienst. Allerdings ist ein funktionierender Zeitservice erforderlich, da Kerberos sensibel auf Uhrzeitabweichungen reagiert.

Große Auswahl

Linux-Admins haben die Wahl zwischen den unterschiedlichsten Authentifizierungsverfahren mit teilweise hervorragenden Sicherheitsfeatures. Klar ist, dass sich nicht jedes Verfahren mit jedem anderen kombinieren lässt. Insbesondere stößt der Administrator in gewachsenen Strukturen an Grenzen, wenn beispielsweise nicht für alle Anwendungen und Dienste kerberisierte oder PAM-fähige Versionen bereitstehen.

Beim Zentralisieren von Benutzer-Credentials ist darauf zu achten, dass die zentrale Speicherung keine neuen Sicherheitslücken aufreißt, sei es durch ungeschützten Transport von Credentials im Netz oder ungenügenden Schutz der Passwort-Datenbank. Die größte Lücke reißt aber auf, wer auf moderne Verfahren verzichtet und Passwörter im Klartext durchs Netz schickt. (fjl)