Bundesamt für Sicherheit in der Informationstechnik

M 4.328 Sichere Grundkonfiguration eines Samba-Servers

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Nachdem der Samba-Server installiert wurde, muss eine sichere Grundkonfiguration des Dienstes hergestellt werden. Dies betrifft unter anderem die Einstellungen für die Zugriffskontrollen, aber auch Einstellungen, die auf die Performance des Servers Einfluss haben.

Die zentrale Konfigurationsdatei von Samba ist die Datei smb.conf. Normalerweise befindet sich diese im Verzeichnis /etc/samba/. In dieser Konfigurationsdatei wird zwischen einem globalen und mehreren freigabespezifischen Konfigurationsabschnitten unterschieden. Freigabespezifische Konfigurationsabschnitte sind daran erkennbar, dass diese Abschnitte mit einer Markierung beginnen, die nicht "[global]" lautet. Parameter, die im globalen Abschnitt stehen, sind allgemein gültig. Parameter in freigabespezifischen Abschnitten sind hingegen immer nur für die Freigabe gültig, auf die sie sich beziehen. In der Dokumentation, beziehungsweise Manpage, zu smb.conf sind alle Konfigurationsparameter beschrieben.

Im Folgenden werden die wichtigsten Konfigurationseinstellungen beschrieben:

Security Modes

Wesentlich für die Authentisierung von Benutzern ist der Parameter "security". Das Server Message Block (SMB)-Protokoll unterscheidet zwischen zwei Sicherheitsstufen (Security Levels):

  • user-level
  • share-level

In der Sicherheitsstufe share-level wird die Zugriffssteuerung auf Freigabeebene geregelt. Eine Freigabe wird bei dieser Sicherheitsstufe nur durch ein Passwort geschützt. Jeder beliebige Benutzer kann, wenn er das Passwort kennt, auf die Freigabe zugreifen. Die Sicherheitsstufe user-level regelt die Zugriffssteuerung hingegen auf Benutzerebene. Das bedeutet, das für jeden Benutzer individuell bestimmt werden kann, welche Rechte er für eine Freigabe erhält. Bevor der Benutzer die Freigabe nutzen darf, muss er sich authentisieren. Samba setzt diese beiden Sicherheitsstufen auf fünf verschiedene Arten um, die Security Modes (Sicherheitsmodi) genannt werden. Die Sicherheitsstufe user-level ist auf vier verschiedene Arten (user, server, domain und ads Sicherheitsmodus) implementiert, die Sicherheitsstufe share-level nur auf eine Art (share Security Mode). Der Sicherheitsmodus share ist der einzige, bei dem die Zugriffssteuerung auf Freigabeebene geregelt ist. Alle anderen Sicherheitsmodi regeln die Zugriffssteuerung auf Benutzerebene.

Im Folgenden werden die einzelnen Sicherheitsmodi genauer beschrieben:

  • share:
    Dieser Sicherheitsmodus sollte nicht verwendet werden, weil sich einzelne Benutzer nicht unterscheiden lassen. Jeder Freigabe wird ein Passwort zugewiesen.
  • server:
    Dieser Sicherheitsmodus wurde durch den Sicherheitsmodus domain ersetzt und sollte möglichst nicht mehr verwendet werden. Samba delegiert bei diesem Sicherheitsmodus die Authentisierung an ein externes IT-System in einer Art und Weise weiter, wie dies ein IT-System mit installierten Windows 95 oder Windows 98 tun würde. Das bringt viele Nachteile mit sich, beispielsweise:
    • Winbind kann nicht eingesetzt und
    • Accounts können unbeabsichtigt gesperrt werden,
    • Samba kann die Identität des Servers, an den die Authentisierung delegiert wird, nicht verifizieren.

Erst im domain Sicherheitsmodus delegiert Samba die Authentisierung an einen DC weiter, wie es ein Windows NT Server tun würde.

  • user:
    Dies ist die Standardeinstellung von Samba. Mit dieser Einstellung werden Benutzer und Passwörter zur Authentisierung genutzt.
  • domain:
    Samba gibt bei diesem Sicherheitsmodus die Authentisierung an ein externes System weiter. Dieser Sicherheitsmodus bewegt Samba dazu, die Authentisierung mit Windows NT-konformen Mitteln an einen DC zu delegieren. Zur Authentisierung wird das NT LAN-Manager (NTLM)-Verfahren in seinen unterschiedlichen Ausprägungen bis hin zu NTLMv2, das Samba auch unterstützt, eingesetzt. Die Benutzerverwaltung erfolgt über so genannte Remote Procedure Calls (RPCs).
  • ads:
    Mit Windows 2000 hat Microsoft Active Directory eingeführt. Dieses setzt zur Authentisierung bevorzugt Kerberos ein und bietet zur Benutzerverwaltung ein Lightweight Directory Access Protocol ( LDAP )-Verzeichnis an. Samba delegiert beim Sicherheitsmodus "ads" die Authentisierung an ein externes System. Dieser Sicherheitsmodus ist in vielerlei Hinsicht äquivalent zum domain Sicherheitsmodus, nur dass Samba dem Client ausschließlich Kerberos als Authentisierungsmethode anbietet.

Die Sicherheitsmodi domain und ads sind sich sehr ähnlich. Folgende Aspekte sollten bei der Entscheidung für einen der beiden Sicherheitsmodi beachtet werden.

Jedes Active Directory kann Samba-Dienste im domain Sicherheitsmodus als Mitglieder aufnehmen. Dies gilt nicht nur für Domänen im sogenannten Mixed Mode, auch Domänen im Windows-2003-Infrastrukur-Modus sind in der Lage, NT-kompatible Mitglieder aufzunehmen. Der Unterschied ist, dass Domänen im Windows-2003-Infrastrukur-Modus die Aufnahme eines NT4-Backup Domain Controller ( BDC )s nicht erlauben. Da Samba aber kein solcher BDC werden kann (siehe M 2.437 Planung des Einsatzes eines Samba-Servers ), ist dieser Aspekt irrelevant.

Die Sicherheitsrichtlinien des Informationsverbundes können die Benutzung von Kerberos erfordern. Kerberos gilt allgemein als deutlich sicherer als NTLM (NT LAN Manager), wobei NTLMv2 ebenfalls einen durchaus akzeptablen Sicherheitsstandard vorzuweisen hat.

Standardmäßig benutzt Samba zur Authentisierung das NTLM oder NTLMv2 Verfahren. Damit Samba nur NTLMv2 einsetzt, muss der Parameter "ntlm auth = no" in der Konfigurationsdatei smb.conf gesetzt werden.

Ein Vorteil von Kerberos gegenüber NTLM ist die geringere Beanspruchung der DC und die niedrigere Netzlast. Bei einer NT-Domäne muss ein Mitgliedsserver für jede Benutzeranmeldung beim DC nachfragen. Hingegen ist ein Kerberosticket für eine gewisse Zeit gültig und steht für sich alleine. Kann sich ein Benutzer mit einem gültigen Ticket gegenüber dem Samba-Dienst authentisieren, ist eine zusätzliche Authentisierung beim DC nicht nötig. Eine geringere Beanspruchung der Domänencontroller und eine niedrigere Netzlast kann auch durch die Verwendung von Winbind erreicht werden (siehe M 4.333 Sichere Konfiguration von Winbind unter Samba ).

Windows 2003 listet bei Verwendung der NT-kompatiblen RPCs nur die ersten 100 Benutzer auf. Bei der Nutzung von LDAP werden dagegen alle Benutzer angezeigt. Das Auflisten von Benutzern ist eine Operation, die man vermeiden sollte, denn bei großen Domänen kann dieser Vorgang ausgesprochen lange dauern. Ist man jedoch auf das Auflisten der Benutzer angewiesen, so muss der Sicherheitsmodus ads gewählt werden.

Im Active Directory existiert das Konzept der sogenannten Standorte (Sites). Jeder DC und jeder Mitgliedsrechner ist einem Standort zugeordnet. Will sich ein Mitgliedsrechner mit einem DC verbinden, dann sollte dies nur innerhalb des vorgesehenen Standortes geschehen. Die entsprechenden Mechanismen bietet Samba nur im ads Security Mode.

Der Security Mode ads ist sehr kritisch bezüglich der Zeitsynchronisation und eines korrekt funktionierenden Domain Name System ( DNS ). Wenn Samba einen DC sucht, geschieht dies im ads Security Mode über das DNS und nicht über die Network Basic Input/Output System (NetBIOS)-Namensauflösung. Die Authentisierung erfolgt per Kerberos. Die Sicherheit von Kerberos beruht zum Teil darauf, dass die Uhrzeiten auf allen Rechnern im Netz synchron sind. Ist dies nicht der Fall, so schlägt die Authentisierung über Kerberos fehl. Wird der Security Mode ads eingesetzt so sollte überlegt werden, einen Windows-DNS-Server als Nameserver und für den Samba-Dienst als Zeitserver zu verwenden. Dies kann am Samba-Dienst mit einem entsprechenden Eintrag in der Datei /etc/resolv.conf und /etc/ntp.conf realisiert werden.

Älteren Kerberos Bibliotheken bereiten die im Active Directory verwendeten kryptographischen Algorithmen häufig schwerwiegende Probleme. Entweder unterstützen sie das benötigte Hash-Verfahren HMAC-MD5 gar nicht, oder die Implementierungen sind fehlerhaft. Dies kann mitunter zu, durch Kerberos verursachten, Abstürzen des Rechners führen. Insbesondere Hersteller proprietärer Unix-Betriebssysteme liefern teilweise noch zu alte Kerberos Bibliotheken aus.

Der Sicherheitsmodus ads ist im Vergleich zum Sicherheitsmodus domain deutlich fortschrittlicher. Auf Grund der eventuell höheren Komplexität der Installation und Konfiguration von Samba im Security Mode ads wird in kleinen Domänen mit nur einem Standort beziehungsweise LAN die Verwendung des Security Mode domain empfohlen. Soll Winbind mit dem ID-Mapping-Backend ads eingesetzt werden (M 4.333 Sichere Konfiguration von Winbind unter Samba ), so muss Samba im Security Mode ads betrieben werden.

Benutzerbasierter Schutz

Generell sollte nur ausgewählten Benutzern und Benutzergruppen erlaubt werden, sich mit dem Samba-Dienst verbinden zu dürfen. Der Zugriff sollte daher in der Konfigurationsdatei smb.conf mit der Option "valid users" beschränkt werden. Wichtig dabei ist, dass diese Option im Abschnitt [global] der Konfigurationsdatei smb.conf gesetzt wird. Der Parameter kann auch in einem freigabespezifischen Abschnitt der Konfigurationsdatei verwendet werden, dann beschränkt er nur den Zugriff auf diese Freigabe. Ein Beispiel könnte sein:

valid users = @smbusers Administrator

Das oben angeführte Beispiel beschränkt sämtlichen Zugriff auf den Server auf Benutzer der Gruppe "smbusers" und den Benutzer "Administrator". Standardmäßig ist diese Option nicht gesetzt. In diesem Fall kann sich jeder Benutzer, der einen gültigen Account besitzt, am Server anmelden.

Ist ein Benutzer in beiden Listen, valid users und invalid users, eingetragen, so wird dem Benutzer die Anmeldung verwehrt.

Die Sonderzeichen in den Gruppennamen werden folgendermaßen interpretiert:

  • @ Der Name wird zuerst als Network Information Service (NIS) Netgroup interpretiert. Wird keine NIS Netgroup gefunden, wird angenommen, dass es sich um eine Unix-Gruppe handelt.
  • + Der Name wird als Unix Gruppe interpretiert.
  • & Der Name wird als NIS Gruppe interpretiert.

Die Sonderzeichen + und & können in beliebiger Weise kombiniert werden, um die jeweils erwünschte Reihenfolge bei der Namensauflösung zu erzwingen.

Hostbasierter Schutz

Standardmäßig akzeptiert Samba Verbindungen von jedem Host. Daher sollte Samba so konfiguriert werden, dass Verbindungen nur von als sicher geltenden Hosts und Netzen entgegengenommen werden. Samba bietet hierzu eine eigene "tcpwrapper"- Implementierung. Um diese zu nutzen, gibt es für die Konfigurationsdatei smb.conf die Optionen "hosts allow" und "hosts deny". Ein Beispiel könnte sein:

hosts allow = 127.0.0.1 192.168.2.0/24
hosts deny = 0.0.0.0/0

Das oben angeführte Beispiel erlaubt Verbindungen nur von localhost (127.0.0.1) und von den IT-Systemen mit einer Internet Protocol (IP)-Adresse zwischen 192.168.2.1 und 192.168.2.255. Alle anderen Verbindungsversuche weist der Samba-Dienst mit der Nachricht "not listening on called name" zurück.

Die Netzadresse 127.0.0.1 muss erlaubt werden, damit folgende Applikationen von Samba ordnungsgemäß funktionieren:

  • smbpasswd:
    smbpasswd verbindet sich als SMB-Client standardmäßig mit der Adresse 127.0.0.1 um das Passwort eines Benutzers zu wechseln.
  • swat:
    Die Statusseite des Samba-Webkonfigurationsprogramms swat verbindet sich mit nmbd und smbd auf der Adresse 127.0.0.1 um festzustellen, ob diese laufen. Kann swat diese Prozesse nicht erreichen, so wird deren Status nicht korrekt angezeigt und Samba kann nicht zuverlässig gestartet, gestoppt und neugestartet werden.

Netzschnittstellen

Standardmäßig bindet sich Samba an alle verfügbaren Netzadressen des Systems. Samba sollte so konfiguriert werden, dass es sich nur an als sicher geltende Netzadressen bindet. Unerwünschte Pakete werden dann nicht an Samba Prozesse weitergeleitet.

Hierzu gibt es für die Konfigurationsdatei smb.conf die Optionen "interfaces" und "bind interfaces only". Ein Beispiel könnte sein:

interfaces = lo eth0
bind interfaces only = yes

Im oben genannten Beispiel bindet sich Samba nur an die Adressen der Netzschnittstellen lo und eth0. Versucht sich jemand beispielsweise über das Netzgerät ppp0 mit dem Samba-Dienst zu verbinden, lehnt bereits das Betriebssystem den Aufbau einer Transmission Control Protocol (TCP)-Verbindung ab. Dabei erhält der Client die Meldung, dass der Aufbau einer TCP-Verbindung abgelehnt wurde. Diese Information kann einem Angreifer unter Umständen nützlich sein. Zusätzlich sollte daher die in M 4.331 Sichere Konfiguration des Betriebssystems für einen Samba-Server beschriebene Maßnahme zur Konfiguration eines lokalen Paketfilters umgesetzt werden.

Über einen Paketfilter kann erreicht werden, dass eingehende unerwünschte Pakete einfach ignoriert werden.

Pakete von Adresse 127.0.0.1 (Interface lo) sollten erlauben werden, damit Programme der Samba-Umgebung ordnungsgemäß funktionieren. Weitere Informationen hierzu sind im Abschnitt hostbasierter Schutz zu finden.

Freigaben

Der Parameter "follow symlinks" steuert, ob Samba einem symbolischen Link im Unix-Dateisystem folgt oder ob der Benutzer eine Fehlermeldung erhält. Standardmäßig ist dieser Parameter auf "yes" gesetzt. Die Standardeinstellung des Parameters sollte beibehalten werden, auch wenn smbd beim Auflisten von Verzeichnissen geringfügig langsamer arbeitet.

Der Parameter "wide links" steuert, ob der Benutzer symbolischen Links im Unix-Dateisystem folgen kann, deren Ziel außerhalb des freigegebenen Verzeichnisbaums liegt. Dazu gehören Dateien und Verzeichnisse am anderen Ende der Links, solange die Berechtigungen des Dateisystems dafür vorliegen. Die Standardeinstellung für diesen Parameter ist "yes". Dieser Parameter wird ignoriert, falls "follow symlinks = no" gesetzt ist. Bei "wide links = no", kann es sein, dass smbd merklich langsamer arbeitet, da jeder Link überprüft werden muss. Wird dieser Parameter auf "yes" gesetzt, kann verhindert werden, dass ein Benutzer beispielsweise über einen symbolischen Link auf Informationen im Ordner /etc/ zugreifen kann. Schreiben die Sicherheitsrichtlinien vor, dass Benutzer keinen Zugriff auf Informationen außerhalb der Freigaben haben dürfen, so wird empfohlen "wide links = no" zu setzen.

Falls hohe Anforderungen an die Performance gestellt werden und trotzdem verhindert werden muss, dass auf Dateien außerhalb der Freigaben zugegriffen werden kann, bietet Samba noch eine zusätzliche Möglichkeit, wenn auch mit erhöhten Administrationsaufwand.

Der Parameter "root directory" gibt an, in welches Verzeichnis Samba nach der Initialisierung wechselt. Dazu wird der chroot() Systemaufruf verwendet. Standardmäßig gilt "root directory = /". Wird dieser Parameter beispielsweise auf "root directory = /var/fileserver/" gesetzt, so kann keiner der von Samba gestarteten Prozesse in Zukunft auf Dateien außerhalb von "/var/fileserver/" zugreifen. Davon betroffen sind auch einige Dateien, die für eine ordnungsgemäße Ausführung von Samba benötigt werden. In diesem Fall muss sichergestellt werden, dass folgende Dateien für Samba unter /var/fileserver/ zur Verfügung stehen:

  • Die Datei etc/passwd
  • Falls auf die Druckfunktionen von Samba zurückgegriffen wird, jegliche Binärdateien oder Konfigurationsdateien die für die Druckfunktion benötigt werden.

Außerdem kann es sein, dass noch weitere Dateien für Samba unter /var/fileserver/ zur Verfügung gestellt werden müssen. Dies hängt vom eingesetzten Betriebssystem ab.

[netlogon] Freigabe

Über die [netlogon] Freigabe kann Samba für Clients beispielsweise Windows-NT kompatible Richtlinien oder Anmeldeskripte bereitstellen. Wird eine [netlogon] Freigabe konfiguriert, so muss sichergestellt werden, dass unberechtigte Benutzer keinesfalls Dateien in dieser Freigabe modifizieren können. Dies kann beispielsweise durch den freigabespezifischen Parameter "read only = yes" erreicht werden.

Benutzerdatenbanken

Samba kann Benutzer nicht mit Hilfe der Mechanismen des darunter liegenden Unix-Betriebssystems authentisieren. Samba muss die in der Windows-Welt verwenden Hash-Werte (LAN Manager (LM) und/oder NTLM-Hashes) der Benutzerpasswörter separat speichern. Zur Abspeicherung der Hash-Werte verwendet Samba sogenannte Backends. Zusätzlich zu den Hash-Werten kann Samba, je nach verwendetem Backend, weitere Informationen über die Benutzer speichern.

Als Backend kann eine einfache Textdatei, eine Datenbank, oder ein LDAP- Verzeichnisdienst, das beispielsweise von OpenLDAP bereitgestellt wird, verwendet werden. In Samba 3.0.0 bis 3.0.23 konnten mehrere Backends gleichzeitig verwendet werden. Frühere sowie spätere Versionen von Samba unterstützen diese Funktion nicht. Backends sind:

  • smbpasswd:
    Bei diesem Backend werden die Kontoinformationen in einer einfachen Textdatei abgespeichert. Im Gegensatz zu den Backends tdbsam und ldapsam kann dieses Backend keine der Microsoft Windows NT/200x SAM (Security Account Manager) Informationen abspeichern. Bei Neuinstallationen wird von der Verwendung dieses Backends daher abgeraten.
  • tdbsam:
    Es wird empfohlen dieses Backend anstatt des Backends smbpasswd zu verwenden, auch wenn dies noch nicht die Standardeinstellung ist. Die Kontoinformationen werden in einer Trivial Database (TDB)-Datei abgelegt.
  • ldapsam:
    Bei diesem Backend werden die Kontoinformationen in einem LDAP-Verzeichnis abgelegt. Dieses Backend bietet sich vor allem in großen Netzen an und vor allem dann, wenn ein Samba Primary Domain Controller/BDC-Setup eingesetzt wird.

Es muss sichergestellt werden, dass ein Benutzer keine Hash-Werte aus dem Backend auslesen kann. Bei den Backends smbpasswd und tdbsam sollte daher nur der Benutzer "root" Lese- und Schreibzugriff auf die Datei haben, in denen die Benutzerinformationen abgelegt werden. Alle anderen Benutzer sollten keinerlei Zugriffsrechte auf diese Datei besitzen. Wird das ldapsam Backend eingesetzt, sollten die Zugriffsrechte in äquivalenter Form mittels Access Control Lists ( ACL s) umgesetzt werden.

Da unter Windows die Hash-Werte gleichbedeutend mit Klartextpasswörtern sind, sollten die Benutzer keinen Zugriff darauf bekommen. Um die Konsequenzen dieser Aussage zu verdeutlichen, wird im Folgenden kurz das NTLM- und NTLMv2- Authentisierungsverfahren von Windows erläutert. Das Prozedere, mit dem Windows-Rechner verschlüsselte Authentisierung ausüben, ist eine Anwendung eines symmetrischen Verschlüsselungsalgorithmus und wird durch ein ein Challenge-Response-Verfahren realisiert. Grob skizziert läuft das Verfahren folgendermaßen ab:

  • Bevor ein SMB-Client eine Verbindung zu einem Server aufbaut, muss der Benutzer seinen Benutzernamen und sein Passwort eingeben. Anschließend wendet der Client eine Hash-Funktion auf das eingegebene Passwort an und speichert den daraus resultierenden Hash-Wert.
  • Der Client baut eine Verbindung mit dem Server auf und erhält als Antwort eine Zufallszahl, auch Herausforderung (Challenge) genannt.
  • Der Client verschlüsselt mit einem symmetrischen Verschlüsselungsalgorithmus die Herausforderung und benutzt dabei den Hash-Wert des Benutzerpassworts als Schlüssel.
  • Der Client schickt den Benutzernamen und die verschlüsselte Herausforderung an den Server (Response).
  • Der Server liest aus seiner Benutzerdatenbank den Hash-Wert aus dem Passwortfeld des Benutzers aus. Unter Windows werden in der Benutzerdatenbank nicht die Klartextpasswörter der Benutzer, sondern nur die Hash-Werte der Passwörter abgespeichert. Anschließend verwendet der Server den ausgelesenen Hash-Wert um die vom Client erhaltene Antwort (Response) zu entschlüsseln. Stimmt das Ergebnis mit der Zufallszahl überein, die der Server in Schritt 2 an den Client übermittelt hat, so ist die Authentisierung erfolgreich. Andernfalls schlägt eine Authentisierung fehl.

Falls ein Angreifer Zugriff auf den Benutzernamen und den Hash-Wert von dessen Passwort erhält, könnte er folgendermaßen verfahren: Werden einem SMB-Client der Benutzername und der Hash-Wert eines Benutzerpassworts als Passwort übergeben, wendet der SMB-Client normalerweise noch einmal eine Hash-Funktion auf das eingegebene Passwort an, bevor er die Antwort an den Server schickt. Eine Authentisierung würde in diesem Fall fehlschlagen. Verwendet ein Angreifer aber einen SMB-Client (zum Beispiel eine modifizierte Version von smbclient), der ohne vorhergehende Anwendung einer Hash-Funktion auf das eingegebene Passwort den Benutzernamen und das Passwort zum Server schickt, so kann er sich erfolgreich authentisieren. Daher sind die Hash-Werte der Klartextpasswörter unter Windows gleichbedeutend mit den Klartextpasswörtern.

Prüffragen:

  • Werden Schreibzugriffe auf die Freigabe [netlogon] unterbunden?

  • Ist sichergestellt, dass der Sicherheitsmodus share nicht verwendet wird?

  • Ist sichergestellt, dass der Sicherheitsmodus server nicht verwendet wird?

  • Verwendet Samba ausschließlich Kerberos zur Authentisierung, falls die Sicherheitsrichtlinien des Informationsverbundes dies erfordern?

  • Setzt Samba ausschließlich die Version 2 des NTLM -Verfahrens ( NTLMv2 ) zur Authentisierung ein?

  • Wird Samba im Sicherheitsmodus ads betrieben, falls der Informationsverbund das Konzept von Standorten benutzt?

  • Können nur ausgewählte Benutzer und Benutzergruppen auf den Samba-Dienst zugreifen?

  • Ist Samba so konfiguriert, dass es Verbindungen nur von als sicher geltenden Hosts und Netzen entgegennimmt?

  • Ist Samba so konfiguriert, dass es sich nur an als sicher geltende Netzadressen bindet?

  • Wird verhindert, dass Benutzer Zugriff auf Informationen außerhalb der Freigaben haben, falls die Sicherheitsrichtlinien des Informationsverbundes dies erfordern?

  • Wird von der Verwendung des smbpasswd-Backends abgesehen?

  • Ist sichergestellt, dass Benutzer keine Hash-Werte der Benutzerpasswörter unberechtigt aus dem verwendeten Backend auslesen können?

Stand: 11. EL Stand 2009