Warum der Welt-Passwort-Tag 2026 relevanter ist denn je
Der Welt-Passwort-Tag wurde 2013 von Intel Security ins Leben gerufen und findet jedes Jahr am ersten Donnerstag im Mai statt – 2026 also am 07. Mai. Der Tag soll daran erinnern, dass Passwörter noch immer das schwächste Glied in der Sicherheitskette sind. Daran hat sich wenig geändert, auch wenn die Bedrohungslandschaft komplexer geworden ist.
Laut dem Verizon Data Breach Investigations Report 2026 ist die Ausnutzung von Schwachstellen der häufigste initiale Angriffsvektor (31 %). Credential-Missbrauch als erster Angriffsschritt ist gegenüber dem Vorjahresreport auf 13 % zurückgegangen. Betrachtet man jedoch den gesamten Verlauf eines Einbruchs, bleibt der Diebstahl von Zugangsdaten mit 39 % weiterhin der bedeutendste Risikofaktor – Passwörter verlieren also keineswegs an Relevanz, sie werden nur seltener als allererste Tür genutzt. Der menschliche Faktor war zudem in 62 % aller Einbrüche beteiligt, ein leichter Anstieg gegenüber dem Vorjahr. Die Angriffsmethoden sind automatisiert, skalieren auf Millionen von Versuchen pro Sekunde und nutzen maschinelles Lernen, um Muster zu erkennen. Ein Passwort wie «Sommer2025!» ist damit statistisch keine Stunde sicher.
Als jemand, der tagtäglich Hosting-Systeme betreibt und absichert, sehe ich den Welt-Passwort-Tag daher nicht als Symbol, sondern als praktischen Anlass: Wann hast du zuletzt deine eigenen Zugangsdaten, SSH-Keys und 2FA-Einstellungen überprüft?
Was 2026 wirklich als „sicher“ gilt
Länge schlägt Komplexität
Die alte Faustregel – mindestens 8 Zeichen, Sonderzeichen, Zahlen – ist überholt. Moderne Brute-Force-Angriffe mit spezialisierten GPUs können solche Passwörter in Minuten knacken. Was heute gilt:
Ein Passwort sollte mindestens 16 Zeichen lang sein. Bei dieser Länge steigt der Aufwand für Brute-Force-Angriffe exponentiell, selbst ohne Sonderzeichen. Das Nationale Institut für Standards und Technologie (NIST) hat seine Passwort-Guidelines (SP 800-63B) zuletzt 2025 überarbeitet und empfiehlt seither ausdrücklich: Länge priorisieren, erzwungene Komplexität reduzieren.
Passphrasen statt Zeichensalat
Praktisch und sicher: Passphrasen aus vier oder mehr zufälligen Wörtern. Ein Beispiel:
Trommel-Fenster-Kabeljau-MontagDiese Phrase hat 31 Zeichen, ist gegen Wörterbuchangriffe sehr robust, weil die Kombination zufällig ist, und lässt sich trotzdem merken. Wer einen Passwort-Manager nutzt (dazu gleich mehr), braucht sich Passphrasen ohnehin nicht zu merken – sie eignen sich aber hervorragend als Master-Passwort für den Manager selbst.
Credential Stuffing: die unterschätzte Bedrohung
Viele unterschätzen, wie gefährlich Datenlecks aus anderen Diensten sind. Beim sogenannten Credential Stuffing werden massenhaft Benutzername-Passwort-Kombinationen aus bekannten Leaks automatisiert bei anderen Diensten ausprobiert. Die Datenbank HaveIBeenPwned listet aktuell über 17 Milliarden kompromittierte Konten.
Die Konsequenz daraus ist eindeutig: Jeder Dienst braucht ein eigenes, einzigartiges Passwort. Kein Kompromiss, keine Ausnahmen. Wer das ohne Passwort-Manager verwalten will, scheitert zwangsläufig.
Passwort-Manager: Setup für technische Profis
Unser letzter Beitrag zum Welt-Passwort-Tag hat die populärsten Passwort-Manager vorgestellt. Ich möchte hier etwas tiefer gehen – besonders für alle, die selbst Systeme betreiben.
Bitwarden selbst hosten
Wer Passwörter nicht einem Drittanbieter in der Cloud überlassen möchte, kann Bitwarden als Self-Hosted-Instanz betreiben. Bitwarden stellt dafür offiziell Docker-Images bereit. Auf einem vServer von hosttech ist das Setup schnell erledigt:
# Bitwarden Installations-Script herunterladen
curl -Lso bitwarden.sh \
"https://func.bitwarden.com/api/dl/?app=self-host&platform=linux"
chmod 700 bitwarden.sh
# Installation starten (interaktiver Dialog)
./bitwarden.sh install
./bitwarden.sh startWer lieber eine schlankere Alternative bevorzugt: Vaultwarden ist eine inoffizielle, aber vollständig kompatible Reimplementierung von Bitwarden in Rust – ressourcenschonend und ideal für kleine Setups.
Die Daten des Passwort-Managers sollten natürlich regelmäßig gesichert werden.
SSH-Keys statt Passwörter für Server
Wer Rootserver oder vServer betreibt, sollte SSH-Passwort-Authentifizierung vollständig deaktivieren und ausschließlich auf SSH-Keys setzen. Das ist kein Tipp, das ist Standard. Ein ed25519-Key ist schnell generiert:
ssh-keygen -t ed25519 -C "demo@beispiel.eu"Der öffentliche Schlüssel kommt in die ~/.ssh/authorized_keys des Servers, der private bleibt lokal – am besten ebenfalls mit Passphrase geschützt und im Passwort-Manager hinterlegt. In der /etc/ssh/sshd_config dann:
PasswordAuthentication no
PubkeyAuthentication yesDas eliminiert eine ganze Angriffskategorie auf einen Schlag. Wer Plesk einsetzt, kann SSH-Keys komfortabel über den SSH Keys Manager direkt in der Oberfläche verwalten. Wie das genau funktioniert und was es dabei zu beachten gibt, erkläre ich ausführlich in meinem Beitrag zur SSH-Authentifizierung per SSH-Key in Plesk.
Passkeys: Der Nachfolger des Passworts ist da
Passkeys sind kein Zukunftsprojekt mehr. Die Technologie basiert auf dem FIDO2/WebAuthn-Standard und wird von Apple, Google, Microsoft und zunehmend vielen anderen Diensten unterstützt. Das Prinzip: Statt eines Passworts wird beim Anmelden ein kryptografisches Schlüsselpaar verwendet. Der private Schlüssel verlässt das Gerät nie.
Für Endnutzer bedeutet das: Anmeldung per Fingerabdruck oder Gesichtserkennung, kein Passwort, das gestohlen werden kann. Phishing-Angriffe, die auf Passwort-Eingabe angewiesen sind, laufen ins Leere.
Technisch betrachtet ist ein Passkey resistent gegen:
- Phishing (kein Passwort zum Stehlen)
- Credential Stuffing (kein wiederverwendbares Geheimnis)
- Brute-Force (kein Geheimnis auf Serverseite)
Laut der FIDO Alliance hatten 2024 bereits über 13 Milliarden Nutzerkonten Passkey-Support. Wer Webservices oder Kundenbereiche betreibt, sollte Passkeys als Authentifizierungsoption ernsthaft in Betracht ziehen. Entsprechende Bibliotheken existieren für alle gängigen Sprachen und Frameworks.
Zwei-Faktor-Authentifizierung: Nicht alle Methoden sind gleich
2FA bleibt unverzichtbar, solange Passwörter noch existieren. Aber es gibt Unterschiede in der Sicherheit der verfügbaren Methoden:
| Methode | Sicherheitsniveau | Phishing-resistent? |
|---|---|---|
| SMS-Code | Niedrig | Nein (SIM-Swapping möglich) |
| E-Mail-Code | Niedrig bis mittel | Nein |
| TOTP (z. B. Authenticator-App) | Hoch | Teilweise |
| Hardware-Token (FIDO2/U2F) | Sehr hoch | Ja |
| Passkey | Sehr hoch | Ja |
Mein Rat: TOTP ist das Minimum. Apps wie Aegis (Android) oder Raivo (iOS) speichern die TOTP-Seeds lokal und verschlüsselt – deutlich besser als cloudbasierte Authenticator-Apps, die Sync über Drittserver betreiben.
Im myhosttech Kundencenter ist 2FA per TOTP verfügbar. Wer das noch nicht aktiviert hat: Jetzt ist der richtige Zeitpunkt. Wie du dabei vorgehen musst, erfährst du in unserem FAQ-Beitrag oder in diesem Video:
Verantwortung als Hosting-Kunde und -Anbieter
Wer bei hosttech Webhosting, einen Rootserver oder einen vServer betreibt, trägt Sicherheitsverantwortung – nicht nur für sich, sondern auch für die Daten von Kundinnen und Kunden, Besucherinnen und Besuchern oder Mitarbeitenden.
Konkret bedeutet das:
Für Webhosting-Kunden: Plesk-Zugangsdaten, FTP-Accounts und Datenbankpasswörter regelmäßig überprüfen. Schwache Datenbankpasswörter sind ein klassischer Einstiegspunkt für automatisierte Angriffe auf WordPress und andere Content-Management-Systeme.
Für Server-Betreiber: SSH-Keys statt Passwörter, Fail2Ban oder ähnliche Tools aktivieren, Root-Login deaktivieren und einen dedizierten Admin-User nutzen.
Für alle: Zugangsdaten für kritische Systeme niemals per E-Mail oder Chat teilen. Und: Passwörter in geteilten Dokumenten oder Tabellenkalkulationen sind keine Lösung – auch wenn es in der Praxis noch immer vorkommt.
Fazit
Passwort-Sicherheit ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Der Welt-Passwort-Tag am 07. Mai 2026 ist ein guter Moment, um die eigene Situation ehrlich zu bewerten: Welche Konten nutzen noch schwache oder wiederverwendete Passwörter? Wo fehlt die 2FA? Wo kann ein SSH-Key ein Passwort ersetzen? Die Grundlagen sind bekannt, die Umsetzung entscheidet.
FAQ zu sicheren Passwörtern
Wie lang sollte ein sicheres Passwort 2026 sein?
Mindestens 16 Zeichen – das ist die aktuelle Empfehlung des NIST (National Institute of Standards and Technology). Bei dieser Länge steigt der Rechenaufwand für Brute-Force-Angriffe so stark, dass selbst spezialisierte Hardware Jahre bräuchte, um sie zu knacken. Wer Passphrasen aus vier oder mehr zufälligen Wörtern verwendet, liegt ebenfalls auf der sicheren Seite und hat zusätzlich den Vorteil, dass die Phrase leichter zu merken ist.
Was ist Credential Stuffing, und wie schützt man sich davor?
Beim Credential Stuffing werden Benutzernamen und Passwörter aus bekannten Datenlecks automatisiert bei anderen Diensten ausprobiert. Der einzige wirksame Schutz ist, für jeden Dienst ein einzigartiges Passwort zu verwenden – kombiniert mit einem Passwort-Manager, der die Verwaltung übernimmt. Zusätzlich empfiehlt sich die Aktivierung von 2FA, damit ein gestohlenes Passwort allein nicht ausreicht.
Was sind Passkeys, und sollte ich sie nutzen?
Passkeys sind ein moderner Ersatz für Passwörter auf Basis des FIDO2/WebAuthn-Standards. Statt eines Passworts wird ein kryptografisches Schlüsselpaar verwendet. Der private Schlüssel verlässt das Gerät nie. Passkeys sind resistent gegen Phishing und Credential Stuffing. Sie werden bereits von vielen großen Diensten unterstützt. Wer die Option hat, Passkeys zu aktivieren, sollte das tun.
Welche 2FA-Methode ist die sicherste?
Hardware-Token nach dem FIDO2/U2F-Standard (z. B. YubiKey) sind die sicherste Option, weil sie vollständig phishing-resistent sind. Als praktische Alternative für den Alltag empfiehlt sich TOTP über eine Authenticator-App – deutlich sicherer als SMS-Codes, die durch SIM-Swapping angreifbar sind. SMS-basierte 2FA ist besser als keine 2FA, aber nicht mehr zeitgemäß als einzige Absicherung.
Wie sichere ich meinen Server richtig ab?
Der erste Schritt ist die Deaktivierung der SSH-Passwort-Authentifizierung zugunsten von SSH-Keys – am besten mit ed25519-Schlüsseln. Zusätzlich sollte der direkte Root-Login deaktiviert und ein dedizierter Admin-User mit eingeschränkten Rechten genutzt werden. Tools wie Fail2Ban blockieren automatisierte Brute-Force-Versuche. Wer diese Konfiguration lieber auslagert, findet bei hosttech entsprechende Managed-Server-Angebote.
