• Anzeigen
• Bearbeiten
• Versionen
• Druckansicht
• Rückverweise

Passwörter verwalten

für die Liste aller Seiten

PmWiki hat eine eingebaute Unterstützung für den Schutz mit Passwörtern für verschiedene Bereiche der Wiki-Site. Passwörter können auf Einzelseiten, auf Wikigruppen oder die gesamte Website angewendet werden. Das hier beschriebene Passwortschutz-System ist nur ein kleiner Ausschnitt des kompletten Sicherheitssystems. Weitere Informationen dazu finden sich auf der Seite Sicherheit.

Autoren können PmWiki, wie in Passwörter beschrieben, dazu benutzen um an Einzelseiten und Wikigruppen Passwörter anzuhängen. Der WikiAdministrator kann jedenfalls auch Passwörter in den Dateien für lokale Anpassungen festlegen, so wie weiter unten beschrieben. Anmerkung: Man kann Passwörter nicht zuverlässig in Seiten- oder Gruppenanpassungsdateien setzen. Siehe im FAQ-Abschnitt wegen der Details.

Passwortgrundlagen

PmWiki unterstützt verschiedene Zugangsstufen zu Wikiseiten, Autorisierungsebenen genannt:

• read-Passwörter erlauben das Anschauen der Inhalte von Wikiseiten.
• edit-Passwörter kontrollieren das Bearbeiten und Verändern von Wikiseiten (effektiv gegen Spam).
• attr-Passwörter kontrollieren, wer Passwörter auf Seiten überhaupt setzen darf (und künftig in PmWiki bereit gestellte Eigenschaften).
• upload-Passwörter kontrollieren, wenn das Hochladen von Dateien aktiviert ist, das Hochladen von Dateien und Anhängen.
• Ergänzend können alle verfügbaren Aktionen durch Passwörter autorisiert werden.
• Zum Schluß gibt es noch das admin-Passwort, welches einem Administrator erlaubt, Passwörter jeder Einzelseite oder Gruppe zu überschreiben oder außer Kraft zu setzen.

Seiten haben ihre Passwörter als "Seiteneigenschaften", welche mittels Anhängen an die URL von ?action=attr zugänglich gemacht werden. Passwörter für Gruppen stehen auf einer besonderen, für jede Gruppe existierenden, "GroupAttributes" genannten Seite. Globale, die Website übergreifende Passwörter werden vom $DefaultPasswords-Array (Datenfeld) aus gesteuert. Alle Passwörter werden in einem verschlüsselten Format gespeichert, so dass andere Benutzer auf dem System befindliche Dateien, die eines Passworts bedürfen, nicht durch einfaches Browsen oder Erstöbern erreichen können.

Was bedeuten "leeres Passwort", "kein Passwort" und "gesperrtes Passwort".

• "Kein Passwort" und "leeres Passwort" bedeuten, dass die Aktion ohne ein Passwort eingeben zu müssen ausgeführt werden kann, z. B. das Bearbeiten einer Seite.
• Gesperrtes Passwort bedeutet, es wird ein Passwort angefordert, aber jede Eingabe wird scheitern. Das verschlüsselt gespeicherte Passwort hat nur ein einziges Zeichen (z. B. einen Stern '*'), wogegen das zum Vergleichen aus der Eingabe erzeugte verschlüsselte Passwort 34 Zeichen hat, eine Übereinstimmung kann es nie geben, die Aktion wird also immer abgewiesen. Z. B. wird ein Bearbeiten-Passwort in einer Seite durch den Eintrag
  passwdedit=$1$D95.QF0.$DA6/xUuCY83Sh98CBau7g/

Per Voreinstellung hat PmWiki die folgenden Passworteinstellungen:

• $DefaultPasswords ist mit leeren (also ohne) read-, edit-, und attr-Passwörter eingestellt.
• Das admin- und das upload-Passwort sind zunächst gesperrt.
• Die Main- und die PmWiki-Gruppe haben ein gesperrtes attr-Passwort in ihren jeweiligen GroupAttributes-Seiten, um Autoren daran zu hindern, Passwörter auf Seiten in diesen Gruppen zu setzen. Um diese Passwörter zu verändern, wird Main.GroupAttributes?action=attr oder PmWiki.GroupAttributes?action=attr mit den entsprechenden Rechten gebraucht.
• Die Seiten der Site-Gruppe, mit Ausnahme der SideBar, sind gesichert gegen Bearbeiten; die Site.SideBar-Seite erfordert das admin- oder das site-weite edit-Passwort.

Ein admin-Passwort kann benutzt werden, um die "gesperrten" Passwörter zu überwinden, darüber hinaus funktioniert gar kein Passwort. Natürlich kann der Administrator die gesperrten Passwörter setzen. Dann funktionieren diese Passwörter.

Site-weite Passwörter setzen

Eines der ersten Dinge, die ein Administrator nach dem Installieren tun sollte, ist ein admin-Passwort setzen. Um das websiteweite Administrator-Passwort auf "meingeheimnis" zu setzen, kann der Administrator die folgende Zeile in die Datei local/config.php setzen:

Beachten Sie, dass dafür der pmcrypt()-Aufruf notwendig ist – PmWiki speichert und behandelt alle Passwörter intern als verschlüsselte Strings. Siehe den Abschnitt 'Passwörter verschlüsseln' weiter unten wegen Details, wie man das Klartext-Passwort aus der config.php-Datei eliminieren kann.

Um die ganze Site nur für solchen Benutzer bearbeitbar zu machen, die ein Bearbeiten-Passwort kennen, fügt man eine Zeile wie die Folgende in die local/config.php-Datei ein:

Ähnlich kann man für jede der verfügbaren Aktionen ein site-weites Passwort setzen, d. h. $DefaultPasswords['read'], $DefaultPasswords['edit'] und $DefaultPasswords['upload'] zur Kontrolle des Standard-read-, -edit-, und -upload-Passworts für die ganze Site. Diese Standardpasswörter werden bei Seiten und Gruppen verwendet, für die kein Passwort gesetzt ist, und als zusätzliches Passwort für Seiten, für die ein Passwort gesetzt ist. Auch darf jedes der $DefaultPasswords ein Array verschlüsselter Passwörter enthalten.

Das heißt, dass sowohl "alpha" als auch "beta" zum Betrachten von Seiten verwendet werden können, aber nur "beta" erlaubt jemandem das Bearbeiten der Seiten. Da PmWiki Passwörter, die einmal eingegeben wurden, während einer Sitzung behält, erlaubt das "beta"-Passwort sowohl Betrachten als auch Bearbeiten, während das "alpha"-Passwort nur Betrachten erlaubt. Eine Person ohne eines der Passwörter könnte Seiten noch nicht einmal ansehen.

Um eine Aktion zu sperren, sodass nur Admins sie ausführen können, benutzen Sie '@lock' als Wert, ohne pmcrypt:

Passwörter durch Referenzen setzen

Dies ist ein unbeabsichtigtes Feature.

Passwörter durch Referenzen zu setzen, erlaubt dem Administrator, das Passwort für einen ganzen Satz von Seiten zu ändern, das geht so einfach wie das Ändern von site-weiten Passwörtern. (Andernfalls müsste man die Attribute jeder Seite individuell ändern.) Man gibt in den Seiten- oder Gruppen-Attributen ein:

und in der lokalen Konfigurationsdatei setzt man das eigentliche Passwort mit Zeilen wie diesen:

Beachten Sie, dass Passwörter, die durch Referenzen in einer Konfigurationsdatei gesetzt werden, gegenwärtig nicht als site-weite Passwörter verwendet werden können. Doch können Sie Ihr @_site_level ausdrücklich im Gruppenattribut aller Gruppen einsetzen – mit dem gleichen Effekt. Einmal als Gruppenattribut eingesetzt wird das Passwort auf alle Seiten der Gruppe angewendet, es sei denn, es wird überschrieben, wie jedes anderen Passwort auch.

Identitätsbasierte Autorisierung (Benutzername/Passwort-Logins, AuthUser)

Anders als viele Systeme, die identitätsbasierte Systeme zu Kontrolle der Seitenzugriffe einsetzen (d. h. sie benutzen einen separaten Benutzenamen und ein Passwort für jeder Person), kommt PmWiki mit einem passwortbasierten System aus, wie es oben beschrieben wurde. Generell sind passwortbasierte Systeme einfacher zu verwalten, da sie den administrativen Overhead des Erstellens von Benutzerkonten, des Restaurierens verlorengegangener Passwörter, und des Verzahnens der Benutzernamen mit erlaubten Aktionen vermeiden.

Allerdings erweitert PmWikis authuser.php-Skript das passwortbasierte System um den Zugriff auf Seiten, auf der Basis einer Benutzername-Passwort-Kombination zu erlauben. Siehe AuthUser wegen weiterer Details über die Zugriffskontrolle auf Seiten, basierend auf Benutzeridentität.

Sicherheitslöcher ...

Administratoren müssen sorgfältig planen, wo Passwörter angewendet werden, um das Öffnen unbeabsichtigter Sicherheitslöcher zu vermeiden. Wenn Ihr Wiki offen ist (jeder kann lesen und schreiben), scheint das nicht beunruhigend zu sein, außer ein böswilliger oder verwirrter Benutzer kann ein Ansehen-Passwort für eine Gruppe setzen und die Gruppe vollständig unzugänglich für alle andern Benutzer machen. Als das Allerwenigste sollte auch ein offenes Wiki ein site-weites "admin"-Passwort und ein site-weites "attr"-Passwort in der config.php-Datei gesetzt haben. Die sample-config.php-Datei, die mit PmWiki ausgeliefert wird, zeigt, dass (nur) die PmWiki- und die Main-Gruppe "attr" standardmäßig gesperrt haben, aber wenn jemand eine neue Gruppe anlegt, ist "attr" frei. Administratoren müssen jedes Mal daran denken, das "attr"-Passwort für jede neue Gruppe zu setzen (wenn es gewünscht ist). Eine einfachere Lösung ist, diese Zeilen in die config.php-Datei zu schreiben:

$DefaultPasswords['admin'] = pmcrypt('youradminpassword');
$DefaultPasswords['attr'] = pmcrypt('yourattrpassword');

Passwörter verschlüsseln in config.php

Einen Pferdefuß hat es, die pmcrypt()-Funktion in der config.php-Datei direkt zu verwenden, um Passwörter zu setzen, schließlich kann jeder, der die Möglichkeit hat, in die config.php-Datei hineinzusehen, das unverschlüsselte Passwort sehen. Wenn zum Beispiel die config.php-Datei

enthält, ist das "meingeheimnis"-Passwort als Klartext für andere zu sehen. Allerdings kann ein Wikiadministrator eine verschlüsselte Form des Passwortes direkt eintragen und benutzen, indem er ?action=crypt an irgend einen URL einer Wikiseite im Ziel-Wiki anfügt (oder springen Sie eben zu PasswordsAdmin?action=crypt in Ihrem eigenen Wiki). Diese Aktion präsentiert ein Formular, in das man sein Passwort einträgt und das eine verschlüsselte Version des Passwortes erzeugt und anzeigt für den Gebrauch in der config.php-Datei. Wenn also das Passwort "meingeheimnis" übergeben wird, liefert PmWiki einen String zurück, der etwa so aussieht:

dazu eine Zeile, die man fast eins zu eins in die config.php-Datei kopieren kann:

Beachten Sie, dass in dieser verschlüsselten Form der Funktionsname "pmcrypt" und die Klammern entfernt sind, da das Passwort bereit verschlüsselt ist. Auch muss das Passwort in einfache Anführungszeichen gesetzt werden. In diesem Beispiel ist das Passwort, das der Administrator benutzt, noch immer "meingeheimnis", aber wenn jemand in die config.php-Datei sieht, wird er das Passwort durch bloßes Ansehen des verschlüsselten Passwortes nicht herausbekommen. ?action=crypt liefert für ein und dasselbe Passwort verschiedene Verschlüsselungen – das ist normal, und macht es um so schwieriger, das eigentliche Passwort herauszubekommen.

Bitte beachten Sie, dass Sie das Passwort mit ?action=crypt auf dem Wiki erzeugen, wo es gebraucht werden soll. Ein Passwort, das auf einem System erzeugt wurde, kann auf einem anderen System funktionieren – oder auch nicht.

Passwörter entfernen

Um ein Sitepasswort vollständig zu entfernen, so wie das standardmäßig gesperrte Passwort für 'upload', setzt man einen leeren String ein:

Es kann auch das Sonderpasswort "@nopass" (wird in der $AllowPassword Variablen festgelegt) mittels ?action=attr gesetzt werden. Dadurch wird eine nicht passwortgeschützte Seite in einer passwortgeschützten Gruppe erstellt oder eine nicht passwortgeschützte Gruppe innerhalb einer passwortgeschützten Website.

Ein Passwort ungültig machen oder aufheben

Wenn ein Passwort kompromittiert ist und der Wikiadministrator das Passwort schnell ungültig machen möchte, ist das Folgende in der ''local/config.php''-Datei eine schnelle Lösung:

$ForbiddenPasswords = array('secret', 'tanstaafl');
if (in_array(@$_POST['authpw'], $ForbiddenPasswords)) 
    unset($_POST['authpw']);

Das hindert "secret" und "tanstaafl" daran, je wieder als ein gültiges Autorisierungspasswort angenommen zu werden ohne Rücksicht darauf, welche Seite es nutzt.

Siehe auch

• das $HandleAuth-Array, das das geforderte Authentifikationsniveau setzt, das für eine Aktion erforderlich wird und
• Cookbook:RequireAuthor (nur in englisch)

Aktionen schützen (Beispiel)

Jede verfügbare Aktion kann durch ein Passwort geschützt werden. Kochbuchautoren, die Skripten mit eigenen Aktionen bereitstellen, können dies auch benutzen, aber ich begrenze das Beispiel auf eine (standardmäßig) nicht geschützte ?action=source. Diese Aktion zeigt die Wikiquelle der aktuellen Seite. Manchmal möchte man das nicht, insbesondere um E-Mail zu schützen oder man benutzt ein paar bedingte Texte, die nicht einfach vor Jedem aufgedeckt werden sollen oder nur von Personen, die das Recht haben, die Seite zu bearbeiten.

Es gibt einige Lösungen dafür:

1. Sie begrenzen "source" nur auf Verfasser und fügen das zur local/config.php-Datei hinzu:
   $HandleAuth['source'] ='edit';
2. Um "source" mit einem eigenen Passwort zu versehen, fügen Sie das hinzu:
   $HandleAuth['source'] ='source';
   $DefaultPasswords['source'] = pmcrypt('secret'); # siehe oben

Wenn Sie das Passwort zusätzlich in die Attributes-Seite setzen möchten:

$PageAttributes['passwdsource'] = "$['Set new source password']";

Im allgemeinen gilt: Fügen Sie einem Aktionsnamen in dem $PageAttributes-Array den Präfix 'passwd' hinzu, zeigt das an, Sie möchten für das gegebene Feld, dass es beim Speichern verschlüsselt wird.

Der volle Satz von Schritten zum Hinzufügen einer neuen Passworthandhabung für eine Aktion wie "diff" wäre:

# Füge ein neues (verschlüsseltes) Feld zur 'attr'-Seite hinzu
$PageAttributes['passwddiff'] = "$['Set new history password']";

# lösche das Standardpasswort für 'diff'
$DefaultPasswords['diff'] = '';

# Sage PmWiki, dass das 'diff'-Passwort die Aktion 'diff' erlaubt
$HandleAuth['diff'] = 'diff';

# Sage PmWiki, dass das 'read-Passwort
# (oder alternativ das 'edit'-Passwort)
# auch reicht, um 'diff' zu ermöglichen.
# natürlich geht auch das 'admin'-Passwort.

$AuthCascade['diff'] = 'read';    ## or 'edit'

FAQ

 $HandleAuth['upload'] = 'edit';
// Um u. a. eine WikiSandbox vorm Ändern ihres 'attr'-Rechts zu schützen außer durch den 
// Admin (aber den Verfassern das Ändern ihrer eigenen Seiten/Gruppen zu erlauben)
// And to prevent a WikiSandbox from having it's 'attr' permissions changed 
// except by the admin (but allowing editors to change it on their own pages/group)
if(($group=="Site") || ($group=="Main") || ($group=="Category") || 
                       ($group=="SiteAdmin") || ($group=="PmWiki") ) {
          // setze 'attr' auf das 'admin'-Passwort für alle Main-Admin-Seiten 
          $HandleAuth['attr'] = 'admin';  
} else { 
          // Wer Bearbeiten kann, kann auch Attribute setzen
          $HandleAuth['attr'] = 'edit';  
}

für die Liste aller Seiten