Passwortverwaltung

Passwort-Hashing mit PBKDF2-SHA256, Zurücksetzen über Admin-CLI und -API, tokenbasierte Selbstbedienung sowie Speicherung der Zugangsdaten in SQLite oder PostgreSQL konfigurieren.

Neu in v2.4.0

Potatos Authentifizierung arbeitet mit PBKDF2-SHA256 und 100.000 Iterationen sowie einem Salt pro Nutzer, also dem Verfahren, das NIST für die sichere Speicherung von Passwörtern empfiehlt. Diese Seite beschreibt, wie Passwörter gespeichert werden, wie sie sich zurücksetzen lassen und wie Zugangsdaten Serverneustarts überdauern.

Umsetzung der Sicherheit

Passwörter werden im Format salt$hash gespeichert:

32 Zeichen langer Hex-Salt, pro Nutzer eindeutig
64 Zeichen langer SHA-256-Hash aus salt + password
Vergleich in konstanter Zeit über hmac.compare_digest, um Timing-Angriffe zu verhindern

Vorhandene Klartextpasswörter in user_config.jsonl-Dateien werden beim Laden automatisch mit eindeutigen Salts neu gehasht, eine manuelle Migration entfällt.

Standardkonfiguration

Standardmäßig authentifiziert Potato im Arbeitsspeicher. Annotatoren müssen in der Konfiguration aufgeführt sein:

yaml

authentication:
  method: in_memory
  require_password: true
 
user_config:
  users:
    - username: "annotator1"
      password: "initial-password"   # will be hashed on first load
    - username: "annotator2"
      password: "initial-password"

Dauerhafte Zugangsdaten

Zugangsdaten im Arbeitsspeicher gehen beim Neustart verloren. Für dauerhafte Speicherung eignet sich eine Datei oder eine Datenbank.

Speicherung in einer Datei

yaml

authentication:
  method: in_memory
  user_config_path: /shared/path/to/user_config.jsonl

Potato schreibt die gehashten Zugangsdaten in diese Datei und liest sie beim Neustart wieder ein. Passwörter, die während einer Sitzung gesetzt oder geändert werden, bleiben so erhalten.

Datenbank als Backend

SQLite (ohne zusätzliche Abhängigkeiten):

yaml

authentication:
  method: database
  database_url: "sqlite:///auth/users.db"

PostgreSQL (setzt psycopg2-binary voraus):

yaml

authentication:
  method: database
  database_url: "postgresql://user:password@localhost:5432/potato_auth"

Die Datenbanktabellen werden beim ersten Start automatisch angelegt.

Hinweis: method: database und user_config_path schließen sich gegenseitig aus, es lässt sich nur eine der beiden Speicherstrategien nutzen.

Passwörter zurücksetzen

Admin-CLI

Ein Passwort auf der Kommandozeile zurücksetzen:

bash

# Reset a specific user's password
potato reset-password config.yaml --username annotator1
 
# Prompted for new password interactively

Admin-API

Programmatisch mit einem API-Key zurücksetzen:

bash

curl -X POST http://localhost:8000/admin/reset_password \
  -H "X-API-Key: $ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"username": "annotator1", "new_password": "new-secure-password"}'

Selbstbedienung per Token

Potato kennt einen Ablauf, den Nutzer selbst anstoßen. Sie rufen /forgot-password auf, geben ihren Benutzernamen ein und erhalten ein einmalig gültiges Token. Unter /reset/<token> setzen sie dann ein neues Passwort.

Tokens sind 24 Stunden gültig und lassen sich nur einmal verwenden. Potato verschickt keine E-Mails, der Administrator gibt den Link selbst weiter.

In der Konfiguration aktivieren:

yaml

authentication:
  method: database
  database_url: "sqlite:///auth/users.db"
  allow_password_reset: true
  reset_token_ttl_hours: 24

Ablauf für Administratoren:

bash

# Generate a reset token for a user
curl -X POST http://localhost:8000/admin/generate_reset_token \
  -H "X-API-Key: $ADMIN_API_KEY" \
  -d '{"username": "annotator1"}'
 
# Returns: {"reset_url": "https://your-server.com/reset/abc123..."}
# Share this URL with the annotator

Betrieb ohne Passwörter

Für Vorführungen im Unterricht, kurze Studien oder Aufgaben mit externer Authentifizierung (MTurk, Prolific) lassen sich Passwörter ganz abschalten:

yaml

authentication:
  method: in_memory
  require_password: false

Annotatoren melden sich mit einem beliebigen Benutzernamen an, eine Passwortabfrage erscheint nicht. Für sensible Daten oder Aufgaben mit geprüfter Identität ist das nicht zu empfehlen.

Einzelheiten stehen unter Passwortloser Login.

Vollständige Referenz

yaml

authentication:
  method: in_memory       # in_memory | database | oauth | clerk
 
  # In-memory options
  require_password: true
  user_config_path: path/to/users.jsonl   # optional persistence
 
  # Database options (mutually exclusive with user_config_path)
  database_url: "sqlite:///auth/users.db"
 
  # Self-service reset
  allow_password_reset: true
  reset_token_ttl_hours: 24
 
user_config:
  users:
    - username: "researcher"
      password: "secure-passphrase"
      role: admin
    - username: "annotator1"
      password: "initial-pass"
      role: annotator

Weiterführende Informationen

SSO & OAuth-Authentifizierung — Anmeldung über Google, GitHub oder institutionelles SSO
Passwortloser Login — Zugang nur über den Benutzernamen für offene Aufgaben
Produktionseinrichtung — HTTPS und Konfiguration des Reverse Proxy
Admin-Dashboard — Annotatorenkonten verwalten

Implementierungsdetails stehen in der Quelldokumentation.