75 lines
2.5 KiB
Markdown
75 lines
2.5 KiB
Markdown
# 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?
|
|
|