Passwort-Speicherung Sicherheitsanalyse

Aktuelle Implementierung

Algorithmus: bcrypt (golang.org/x/crypto/bcrypt)
Cost Factor: bcrypt.DefaultCost (Wert: 10)
Speicherung:
- Feld: password_hash TEXT NOT NULL in SQLite
- Format: bcrypt Hash-String (enthält automatisch Salt + Hash)
- Beispiel: $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
Passwortrichtlinie:
- Mindestens 8 Zeichen
- Großbuchstaben erforderlich
- Kleinbuchstaben erforderlich
- Zahlen erforderlich
- Sonderzeichen erforderlich
Validierung:
- Altes Passwort wird bei Änderung geprüft
- bcrypt.CompareHashAndPassword() für Login-Validierung

bcrypt ist ein sicherer, bewährter Algorithmus
- Speziell für Passwort-Hashing entwickelt
- Verlangsamt Brute-Force-Angriffe durch anpassbare Rechenzeit
- Wird von OWASP und anderen Sicherheitsorganisationen empfohlen
Automatisches Salting
- bcrypt generiert für jedes Passwort einen eindeutigen Salt
- Verhindert Rainbow-Table-Angriffe
- Salt wird im Hash-String mitgespeichert
Passwörter werden nie im Klartext gespeichert
- Nur gehashte Werte in der Datenbank
- Einweg-Hashing (nicht reversibel)
Passwortrichtlinie vorhanden
- Erzwingt starke Passwörter
- Mindestanforderungen erfüllt

Cost Factor könnte erhöht werden
- Aktuell: Cost 10 (DefaultCost)
- Empfohlen 2024/2025: Cost 12-14
- Begründung:
  - Cost 10 war vor ~10 Jahren Standard
  - Moderne Hardware ist schneller
  - Cost 12-14 bietet besseren Schutz gegen Brute-Force
  - Trade-off: Etwas langsamere Login-Zeit (~100-500ms), aber deutlich sicherer
Fehlende Sicherheitsfeatures (optional, aber empfohlen):
- ❌ Rate Limiting für Login-Versuche (verhindert Brute-Force)
- ❌ Passwort-Historie (verhindert Wiederverwendung)
- ❌ Passwort-Ablaufzeit
- ❌ Account-Lockout nach fehlgeschlagenen Versuchen
- ❌ 2FA/MFA Support

Die aktuelle Implementierung ist grundsätzlich sicher und entspricht modernen Standards, aber:

Soll ich den Cost Factor erhöhen?