fixed ssl provider section view/edit permission

This commit is contained in:
2025-11-21 02:30:11 +01:00
parent dbb8049c7e
commit e3a2ccb82d
9 changed files with 706 additions and 51 deletions

View File

@@ -0,0 +1,74 @@
# Passwort-Speicherung Sicherheitsanalyse
## Aktuelle Implementierung
### Wie werden Passwörter gespeichert?
1. **Algorithmus**: `bcrypt` (golang.org/x/crypto/bcrypt)
2. **Cost Factor**: `bcrypt.DefaultCost` (Wert: **10**)
3. **Speicherung**:
- Feld: `password_hash TEXT NOT NULL` in SQLite
- Format: bcrypt Hash-String (enthält automatisch Salt + Hash)
- Beispiel: `$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy`
4. **Passwortrichtlinie**:
- Mindestens 8 Zeichen
- Großbuchstaben erforderlich
- Kleinbuchstaben erforderlich
- Zahlen erforderlich
- Sonderzeichen erforderlich
5. **Validierung**:
- Altes Passwort wird bei Änderung geprüft
- `bcrypt.CompareHashAndPassword()` für Login-Validierung
## Entspricht es aktuellen Sicherheitsstandards?
### ✅ **Gut implementiert:**
1. **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
2. **Automatisches Salting**
- bcrypt generiert für jedes Passwort einen eindeutigen Salt
- Verhindert Rainbow-Table-Angriffe
- Salt wird im Hash-String mitgespeichert
3. **Passwörter werden nie im Klartext gespeichert**
- Nur gehashte Werte in der Datenbank
- Einweg-Hashing (nicht reversibel)
4. **Passwortrichtlinie vorhanden**
- Erzwingt starke Passwörter
- Mindestanforderungen erfüllt
### ⚠️ **Verbesserungspotenzial:**
1. **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
2. **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
## Empfehlung
Die aktuelle Implementierung ist **grundsätzlich sicher** und entspricht **modernen Standards**, aber:
1. **Sofort umsetzbar**: Cost Factor von 10 auf 12-14 erhöhen
2. **Mittelfristig**: Rate Limiting für Login-Versuche implementieren
3. **Langfristig**: Zusätzliche Sicherheitsfeatures (2FA, Passwort-Historie)
Soll ich den Cost Factor erhöhen?