Https Interface für LDAP-Passworte: Difference between revisions

From
Jump to navigation Jump to search
No edit summary
No edit summary
Line 5: Line 5:


== Analyse ==
== Analyse ==

Im Folgenden werden wir das Problem analysieren, um die Anforderung an unser System genau spezifizieren zu können:
Im Folgenden werden wir die Problemstellung analysieren, um die Anforderung an unser System genau spezifizieren zu können:
* Szenario - Es existieren Benutzer, welche für verschiedene Systeme angemeldet sind, welche eine Authentifikation benötigen. Die Authentifizierungsdaten bestehen aus einem Benutzernamen und Passworthashes, welche zentral in einem Verwaltungssystem gespeichert werden.
* Szenario - Es existieren Benutzer, welche für verschiedene Systeme angemeldet sind, welche eine Authentifikation benötigen. Die Authentifizierungsdaten bestehen aus einem Benutzernamen und einem Passwort, welche zentral in einem Verwaltungssystem gespeichert werden.
* Verwaltungssystem - Ein Verwaltungssystem speichert die Authentifizierungsdaten. Dazu gehören Benutzername und Passwort. Hier ist das Verwaltungssystem eine LDAP Datenbank. Es muss beachtet werden, dass die Benutzer nicht das Recht haben, die eigenen Passwörter zu ändern.
* Verwaltungssystem - Ein Verwaltungssystem speichert die Authentifizierungsdaten. Dazu gehören Benutzername und Passworthashes verschiedener Hashfunktionen. Dies soll eine große Anzahl von unterschiedlichen Systemen ermöglichen, welche unterschiedliche Hashfunktionen benutzen. Hier ist das Verwaltungssystem eine LDAP Datenbank. Es muss beachtet werden, dass die Benutzer nicht das Recht haben, die eigenen Passwörter zu ändern.
* System - Ein System ist ein Dienst oder eine Anwendung, die Authentifikationsdaten nicht lokal speichert, sondern diese von einem Verwaltungssystem bezieht. Die Systeme haben keine Rechte die Passwörter der Benutzer zu manipulieren, um Konsistenz in den Passworthashes zu gewährleisten. Ein Linuxlogin oder eine SAMBA-Authentifikation sind Beispiele für solche Systeme.
* System - Ein System ist ein Dienst oder eine Anwendung, die Authentifizierungsdaten nicht lokal speichert, sondern diese von einem Verwaltungssystem bezieht. Die Systeme haben keine Rechte die Passwörter der Benutzer zu manipulieren, um Konsistenz in den Passworthashes zu gewährleisten. Ein Linuxlogin oder eine SAMBA-Authentifikation sind Beispiele für solche Systeme.
* Webserver - Der Webserver stellt das Formular zur Passwortänderung bereit. Da der Webserver potentiell unsicher ist, dürfen auf dem Webserver keine kritischen Informationen gespeichert werden.
* Webserver - Der Webserver stellt das Formular zur Passwortänderung bereit. Da der Webserver potentiell unsicher ist, dürfen auf dem Webserver keine kritischen Informationen gespeichert werden.
* Benutzer - Die Benutzer des Szenarios melden sich an jedes System mit der gleichen Benutzer/Kennwort-Kombination an.
* Benutzer - Die Benutzer des Szenarios melden sich an jedes System mit der gleichen Benutzer/Kennwort-Kombination an.
Line 17: Line 18:


Anforderungen:
Anforderungen:
* Die Verfügbarkeit des Verwaltungssystems ist für dieses Szenario besonders wichtig, da die Benutzer bei Ausfall dieses Verwaltungssystems keine Arbeit mehr verrichtet werden können. Unsere Anwendung darf die Verfügbarkeit dieses Systems nicht gefährden.
* Die Verfügbarkeit des Verwaltungssystems ist für dieses Szenario besonders wichtig, da die Benutzer bei Ausfall dieses Verwaltungssystems keine Arbeit mehr verrichten können. Unsere Anwendung darf die Verfügbarkeit dieses Systems nicht gefährden.
* Die Webanwendung muss in dem Sinne sicher sein, dass ein Angreifer durch Abhören beliebiger der Datenleitungen nicht in der Lage ist Informationen zu beziehen, welcher Benutzer sein Passwort ändert oder welche Passwörter eingegeben wurden.
* Die Anwendung (das Formular, sowie die Logik der Passworänderung) muss in dem Sinne sicher sein, dass ein Angreifer durch Abhören beliebiger Datenleitungen nicht in der Lage ist Informationen zu beziehen welcher Benutzer sein Passwort ändert oder welche Passwörter eingegeben wurden.
* Die Webanwendung muss sicher gegen "Man in the middle"-Attacken sein, unter der Annahme, dass der Benutzer vor jedem Login ein durch den Browser angezeigte Zertifikat gründlich prüft.
* Die Webanwendung muss sicher gegen "Man in the middle"-Attacken sein, unter der Annahme, dass der Benutzer vor jeder Passwortänderung ein durch den Browser angezeigtes Zertifikat gründlich prüft.
* Die Webanwendung und jede Logik der Passwortänderung sollte robust gegen "Denial of Service"-Attacken sein. Das bedeutet, dass sich das System möglichst nicht automatisch ausschaltet im Falle, dass viele Anfragen an den Webserver gestellt werden.
* Die Webanwendung und jede Logik der Passwortänderung sollte robust gegen "Denial of Service"-Attacken sein. Dies bedeutet, dass sich das System möglichst nicht automatisch ausschaltet im Falle, dass viele Anfragen an den Webserver gestellt werden.
* Die Benutzer und Systeme haben nicht die Möglichkeit das Passwort in dem Verwaltungssystem zu ändern, sondern müssen dies über die Webanwendung tun.

Revision as of 10:18, 25 September 2007

PROBLEMSTELLUNG

Die benutzerseitige Authentifizierung gegenüber anderen Diensten erfolgt oft über Passworte. Systeme speichern und übertragen heute keine Passworte im Klartext sondern als Hash. Unsere Aufgabe bestand darin, ein sicheres Web-Interface zu erstellen, welches bei Passwortänderung alle Hashwerte, die für verschiedene Systeme (Windows/Unix) benötigt werden, in eine LDAP-Datenbank einträgt. Das System sollte modular und erweiterbar sein.


Analyse

Im Folgenden werden wir die Problemstellung analysieren, um die Anforderung an unser System genau spezifizieren zu können:

  • Szenario - Es existieren Benutzer, welche für verschiedene Systeme angemeldet sind, welche eine Authentifikation benötigen. Die Authentifizierungsdaten bestehen aus einem Benutzernamen und einem Passwort, welche zentral in einem Verwaltungssystem gespeichert werden.
  • Verwaltungssystem - Ein Verwaltungssystem speichert die Authentifizierungsdaten. Dazu gehören Benutzername und Passworthashes verschiedener Hashfunktionen. Dies soll eine große Anzahl von unterschiedlichen Systemen ermöglichen, welche unterschiedliche Hashfunktionen benutzen. Hier ist das Verwaltungssystem eine LDAP Datenbank. Es muss beachtet werden, dass die Benutzer nicht das Recht haben, die eigenen Passwörter zu ändern.
  • System - Ein System ist ein Dienst oder eine Anwendung, die Authentifizierungsdaten nicht lokal speichert, sondern diese von einem Verwaltungssystem bezieht. Die Systeme haben keine Rechte die Passwörter der Benutzer zu manipulieren, um Konsistenz in den Passworthashes zu gewährleisten. Ein Linuxlogin oder eine SAMBA-Authentifikation sind Beispiele für solche Systeme.
  • Webserver - Der Webserver stellt das Formular zur Passwortänderung bereit. Da der Webserver potentiell unsicher ist, dürfen auf dem Webserver keine kritischen Informationen gespeichert werden.
  • Benutzer - Die Benutzer des Szenarios melden sich an jedes System mit der gleichen Benutzer/Kennwort-Kombination an.

Annahmen:

  • Alle Akteure sind potentielle Angreifer und alle Systeme, sowie der Webserver sind gefährdet.
  • Das Verwaltungssystem und somit die LDAP Datenbank ist sicher, was durch logische Positionierung der Geräte in einer Demilitarisierten Zone erreicht werden kann. Diese Annahme muss getroffen werden, da durch ein korrumpiertes Verwaltungssystem keine Datensicherheit für die Benutzer mehr gewährleistet werden kann.

Anforderungen:

  • Die Verfügbarkeit des Verwaltungssystems ist für dieses Szenario besonders wichtig, da die Benutzer bei Ausfall dieses Verwaltungssystems keine Arbeit mehr verrichten können. Unsere Anwendung darf die Verfügbarkeit dieses Systems nicht gefährden.
  • Die Anwendung (das Formular, sowie die Logik der Passworänderung) muss in dem Sinne sicher sein, dass ein Angreifer durch Abhören beliebiger Datenleitungen nicht in der Lage ist Informationen zu beziehen welcher Benutzer sein Passwort ändert oder welche Passwörter eingegeben wurden.
  • Die Webanwendung muss sicher gegen "Man in the middle"-Attacken sein, unter der Annahme, dass der Benutzer vor jeder Passwortänderung ein durch den Browser angezeigtes Zertifikat gründlich prüft.
  • Die Webanwendung und jede Logik der Passwortänderung sollte robust gegen "Denial of Service"-Attacken sein. Dies bedeutet, dass sich das System möglichst nicht automatisch ausschaltet im Falle, dass viele Anfragen an den Webserver gestellt werden.
  • Die Benutzer und Systeme haben nicht die Möglichkeit das Passwort in dem Verwaltungssystem zu ändern, sondern müssen dies über die Webanwendung tun.