Passwortalterung mit länger Ablaufzeit
Beschreibung
Passwortalterung mit länger Ablaufzeit ist eine Schwachstelle, die auftritt, wenn ein Produkt Passwortrotationsrichtlinien mit Ablaufzeiträumen implementiert, die übermäßig lang sind und die Wirksamkeit des Alterungsmechanismus reduzieren. Während das System technisch Passwortänderungen erfordert, bietet der verlängerte Zeitrahmen (wie jährlicher oder mehrjähriger Ablauf) Angreifern reichlich Gelegenheit, kompromittierte Anmeldedaten auszunutzen, bevor eine erzwungene Rotation erfolgt. Diese Schwäche stellt einen Mittelweg zwischen dem Fehlen von Passwortalterung und der Implementierung angemessen kurzer Ablaufzeiträume dar, kann aber ein falsches Sicherheitsgefühl vermitteln, indem sie suggeriert, dass Passwortverwaltungskontrollen existieren, obwohl deren Wirksamkeit minimal ist.
Risiko
Übermäßig lange Passwortablaufzeiträume erhöhen das Schwachstellenfenster für anmeldedatenbasierte Angriffe. Wenn Passwörter nur jährlich oder weniger häufig ablaufen, haben Angreifer, die Anmeldedaten durch Diebstahl, Knacken oder Social Engineering erhalten, verlängerte Zeiträume, um den Zugang auszunutzen, bevor erzwungene Rotation erfolgt. Passwort-Cracking-Angriffe profitieren von längeren Zeitrahmen, da Rechenressourcen über Monate statt Wochen angewendet werden können. Die psychologische Auswirkung auf Benutzer ist ebenfalls problematisch - seltene Passwortänderungen können zu Nachlässigkeit bei der Passwortsicherheit führen und die Wiederverwendung derselben Passwörter über längere Zeiträume fördern. Für Compliance-getriebene Umgebungen können lange Ablaufzeiträume technisch Anforderungen erfüllen, während sie keine bedeutenden Sicherheitsvorteile bieten.
Lösung
Richten Sie Passwortablaufzeiträume an Risikostufen und Branchenbest-Practices aus. Für Standard-Benutzerkonten erwägen Sie 90-Tage-Rotation, wo Compliance Alterung erfordert, mit 30-Tage-Zeiträumen für privilegierte Konten. Erkennen Sie jedoch, dass moderne Sicherheitsrichtlinien (NIST SP 800-63B) empfehlen, von zeitbasiertem Ablauf zu ereignisbasiertem Anmeldedatenwechsel überzugehen, ausgelöst durch vermutete Kompromittierung. Implementieren Sie kompromittierte Anmeldedaten-Erkennung, die Passwortänderungen erzwingt, wenn Breaches entdeckt werden, die Benutzeranmeldedaten betreffen. Aktivieren Sie Multi-Faktor-Authentifizierung als kompensierenede Kontrolle, die die Abhängigkeit von Passwortalterung reduziert. Für Hochsicherheitsumgebungen kombinieren Sie angemessene Ablaufzeiträume (60-90 Tage) mit anderen Kontrollen wie passwortloser Authentifizierung, Hardware-Tokens und kontinuierlicher Authentifizierung. Dokumentieren Sie risikobasierte Begründungen für gewählte Ablaufzeiträume.
Häufige Auswirkungen
| Auswirkung | Details |
|---|---|
| Zugriffskontrolle | Bereich: Zugriffskontrolle Mit zunehmendem Passwortalter steigt die Wahrscheinlichkeit einer Kompromittierung im Laufe der Zeit. Verlängerte Ablaufzeiträume ermöglichen Angreifern mehr Zeit, Passwort-Hashes zu knacken, gestohlene Anmeldedaten auszunutzen und dauerhaften unbefugten Zugriff auf Systeme und Daten aufrechtzuerhalten. |
Beispielcode
Anfällige Konfiguration (Verschiedene)
Die folgenden Beispiele demonstrieren übermäßig lange Passwortablaufeinstellungen:
// Anfällig: 5-Jahre-Passwortablauf
public class VulnerablePasswordPolicy {
// Übermäßig lang - bietet minimalen Sicherheitsvorteil
private static final int PASSWORD_EXPIRATION_DAYS = 1825; // 5 Jahre!
public boolean isPasswordExpired(User user) {
if (user.getPasswordLastChanged() == null) {
return false; // Nie geändert = läuft nie ab?
}
LocalDateTime expiration = user.getPasswordLastChanged()
.plusDays(PASSWORD_EXPIRATION_DAYS);
return LocalDateTime.now().isAfter(expiration);
}
}
# Anfällig: Active Directory-Richtlinie mit 365-Tage-Ablauf
# Dies bietet minimalen Sicherheitsvorteil bei jährlicher Störung
Set-ADDefaultDomainPasswordPolicy -Identity "contoso.com" `
-MaxPasswordAge "365.00:00:00" ` # 1 Jahr - zu lang!
-MinPasswordAge "1.00:00:00"
# Anfällig: LDAP/OpenLDAP-Richtlinie mit langem Ablauf
# slapd.conf
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=example,dc=com"
# Standard-Richtlinie mit übermäßigem Ablauf
dn: cn=default,ou=policies,dc=example,dc=com
objectClass: pwdPolicy
pwdMaxAge: 31536000 # 365 Tage in Sekunden - zu lang!
pwdExpireWarning: 604800 # 7 Tage Warnung
# Anfällig: PAM-Konfiguration mit jährlichem Ablauf
# /etc/login.defs
PASS_MAX_DAYS 365 # Zu lang für sinnvolle Sicherheit
PASS_MIN_DAYS 0
PASS_WARN_AGE 7
Korrigierte Konfiguration (Verschiedene)
// Korrigiert: Risikobasierter Passwortablauf
public class SecurePasswordPolicy {
// Standard-Benutzer: 90 Tage (konfigurierbar)
private static final int STANDARD_USER_EXPIRATION_DAYS = 90;
// Privilegierte Konten: 30 Tage
private static final int PRIVILEGED_USER_EXPIRATION_DAYS = 30;
// Service-Konten: 90 Tage mit Überwachung
private static final int SERVICE_ACCOUNT_EXPIRATION_DAYS = 90;
public int getExpirationDays(User user) {
if (user.hasRole(Role.ADMIN) || user.hasRole(Role.PRIVILEGED)) {
return PRIVILEGED_USER_EXPIRATION_DAYS;
}
return STANDARD_USER_EXPIRATION_DAYS;
}
public boolean isPasswordExpired(User user) {
if (user.getPasswordLastChanged() == null) {
return true; // Initiale Passwortänderung erzwingen
}
// Zuerst auf Breach-ausgelösten Ablauf prüfen
if (breachDetectionService.isCredentialCompromised(user)) {
return true; // Sofortiger Ablauf bei Breach
}
int expirationDays = getExpirationDays(user);
LocalDateTime expiration = user.getPasswordLastChanged()
.plusDays(expirationDays);
return LocalDateTime.now().isAfter(expiration);
}
// Moderner Ansatz: Ereignisbasierter Ablauf
public void handleBreachDetection(String breachedCredentialHash) {
List<User> affectedUsers = userRepository
.findByPasswordHashIn(breachedCredentialHash);
for (User user : affectedUsers) {
user.setForcePasswordChange(true);
user.setPasswordExpiredReason("Anmeldedaten in Datenbreach gefunden");
notificationService.sendBreachNotification(user);
}
}
}
# Korrigiert: Active Directory mit angemessenem Ablauf
# Privilegierte Konten: 30 Tage
# Standard-Konten: 90 Tage (oder kein Ablauf mit MFA erwägen)
# Standard-Domain-Richtlinie für normale Benutzer setzen
Set-ADDefaultDomainPasswordPolicy -Identity "contoso.com" `
-MaxPasswordAge "90.00:00:00" ` # 90 Tage
-MinPasswordAge "1.00:00:00" `
-PasswordHistoryCount 24 `
-ComplexityEnabled $true
# Feinkörnige Richtlinie für Admins erstellen
New-ADFineGrainedPasswordPolicy -Name "AdminPasswordPolicy" `
-Precedence 10 `
-MaxPasswordAge "30.00:00:00" ` # 30 Tage für Admins
-MinPasswordAge "1.00:00:00" `
-PasswordHistoryCount 24 `
-ComplexityEnabled $true
# Auf Admin-Gruppe anwenden
Add-ADFineGrainedPasswordPolicySubject `
-Identity "AdminPasswordPolicy" `
-Subjects "Domain Admins"
# Korrigiert: Moderner Ansatz - Breach-Erkennung über zeitbasierten Ablauf
# password-policy.yml
password_policy:
# Zeitbasierter Ablauf (für Compliance)
standard_users:
max_age_days: 90
warning_days: 14
privileged_users:
max_age_days: 30
warning_days: 7
# Ereignisbasierter Ablauf (moderner Ansatz)
breach_detection:
enabled: true
sources:
- haveibeenpwned
- internal_siem
action: force_immediate_change
# Kompensierende Kontrollen
mfa:
required: true
allows_extended_expiration: true # Mit MFA kann auf 180 Tage verlangert werden
# Für Compliance-Reporting
compliance:
pci_dss:
enabled: true
max_age_days: 90
Die Korrektur implementiert risikobasierte Ablaufzeiträume mit kürzeren Zeitrahmen für privilegierte Konten und fügt Breach-Erkennung für ereignisbasierte Passwortrotation hinzu.
Ausgenutzt in der Praxis
Verlängerte Persistenz durch veraltete Anmeldedaten (Mehrere APT-Kampagnen)
Fortgeschrittene Bedrohungsakteure haben den Netzwerkzugang über Jahre aufrechterhalten, indem sie Anmeldedaten verwendeten, die früh während der Intrusion gestohlen wurden und aufgrund übermäßig länger Ablaufrichtlinien nie rotiert wurden. Jährliche Passwortrotation bedeutete, dass Angreifer 11 Monate garantierten Zugang nach der Kompromittierung hatten, bevor erzwungene Rotation ihre Operationen storen könnte.
Compliance-getriebene falsche Sicherheit (Gesundheitssektor, Mehrere Vorfälle)
Gesundheitsorganisationen, die minimale HIPAA-Passwortanforderungen mit jährlicher Rotation erfüllten, erlitten Breaches, bei denen Angreifer das lange Fenster zwischen Passwortänderungen ausnutzten. Untersuchungen enthüllten, dass technische Compliance falsche Sicherheit bot, während sie minimalen tatsächlichen Schutz bot.
Service-Konto-Ausnutzung (Finanzsektor, 2019)
Service-Konten von Finanzinstituten mit jährlicher Passwortrotation wurden kompromittiert und über viele Monate für Lateral Movement verwendet. Das lange Ablaufsfenster ermöglichte Angreifern, dauerhaften Zugang herzustellen, Daten zu exfiltrieren und größere Angriffe vorzubereiten, ohne anmeldedatenbasierte Erkennung auszulösen.
Tools zum Testen/Ausnutzen
-
CrackMapExec — Identifiziert Konten mit lange unveränderten Passwörtern und testet Anmeldedaten-Gültigkeit über Zeit.
-
PingCastle — Active-Directory-Sicherheitsbewertungstool, das Passwortrichtlinienschwächen einschließlich übermäßiger Ablaufzeiträume identifiziert.
-
Specops Password Auditor — Kostenloses Tool zur Analyse von Active-Directory-Passwortrichtlinien und Identifizierung schwacher Konfigurationen.
CVE-Beispiele
Passwortalterungs-Konfigurationsschwächen werden typischerweise keine individuellen CVEs zugewiesen, da sie Richtlinienentscheidungen statt Software-Schwachstellen darstellen. Länge Ablaufzeiträume wurden jedoch als beitragende Faktoren in Breach-Untersuchungen und Compliance-Feststellungen genannt.
Referenzen
-
MITRE Corporation. "CWE-263: Password Aging with Long Expiration." Common Weakness Enumeration. https://cwe.mitre.org/data/definitions/263.html
-
NIST. "Digital Identity Guidelines: Authentication and Lifecycle Management." SP 800-63B. https://pages.nist.gov/800-63-3/sp800-63b.html
-
NCSC UK. "Password Policy: Updating Your Approach." https://www.ncsc.gov.uk/collection/passwords
-
PCI Security Standards Council. "PCI DSS Password Requirements." https://www.pcisecuritystandards.org/