IT-Verantwortliche, die der Empfehlung folgen möchten, Zugänge zum Unternehmensnetz nicht mehr nur durch klassische Passwörter zu schützen, sehen sich mit verschiedenen Herausforderungen konfrontiert. Ein sehr praktikabler Weg ist die Zweifaktor-Authentifizierung mit Einmalpasswörtern. Mit einigen Tipps lässt sie sich überraschend stressfrei verwalten – sogar in der PowerShell.
Passwörter sind nach wie vor der De-facto-Standard für die Authentifizierung. Zwar stehen robustere und weniger anfällige Verfahren bereit, doch diese sind derart unterschiedlich implementiert, sodass sich kein einheitlicher Ansatz etabliert hat. Microsoft unterstützt in seinen Clouddiensten moderne Authentifizierungsverfahren. Der Begriff Authentisierung umfasst dabei Identifizierung und Authentifizierung eines Anwenders – eine Differenzierung, die im Englischen im Begriff "Authentication" zusammenfällt.
Das klassische Active Directory im eigenen Rechenzentrum bietet hingegen keine zeitgemäßen Verfahren, von der wenig geschätzten Smartcard-Anmeldung abgesehen, die bereits unter Windows 2000 verfügbar war. Erweiterte Methoden positioniert Microsoft vor allem im Kontext von M365-Lizenzen. Doch selbst dort zeigt sich ein heterogenes Bild: Die Anmeldeoptionen für Firmenkonten (Entra ID, Work or School Account) unterscheiden sich deutlich von denen für Privatkonten (Microsoft-Account, MSA). Den Überblick zu behalten, ist anspruchsvoll.
Viele Unternehmen verfolgen zudem überholte Passwortstrategien. Kurze Gültigkeitszeiträume und formale Komplexitätsregeln gelten oft noch als Sicherheitsmaßnahme. Entscheidend ist jedoch vor allem die Einzigartigkeit eines Kennworts – insbesondere angesichts umfangreicher Passwortdatenbanken aus früheren Sicherheitsvorfällen. Die von Troy Hunt betriebene Website "Have I Been Pwned" verdeutlicht die Dimension dieses Problems.
Passwörter sind nach wie vor der De-facto-Standard für die Authentifizierung. Zwar stehen robustere und weniger anfällige Verfahren bereit, doch diese sind derart unterschiedlich implementiert, sodass sich kein einheitlicher Ansatz etabliert hat. Microsoft unterstützt in seinen Clouddiensten moderne Authentifizierungsverfahren. Der Begriff Authentisierung umfasst dabei Identifizierung und Authentifizierung eines Anwenders – eine Differenzierung, die im Englischen im Begriff "Authentication" zusammenfällt.
Das klassische Active Directory im eigenen Rechenzentrum bietet hingegen keine zeitgemäßen Verfahren, von der wenig geschätzten Smartcard-Anmeldung abgesehen, die bereits unter Windows 2000 verfügbar war. Erweiterte Methoden positioniert Microsoft vor allem im Kontext von M365-Lizenzen. Doch selbst dort zeigt sich ein heterogenes Bild: Die Anmeldeoptionen für Firmenkonten (Entra ID, Work or School Account) unterscheiden sich deutlich von denen für Privatkonten (Microsoft-Account, MSA). Den Überblick zu behalten, ist anspruchsvoll.
Viele Unternehmen verfolgen zudem überholte Passwortstrategien. Kurze Gültigkeitszeiträume und formale Komplexitätsregeln gelten oft noch als Sicherheitsmaßnahme. Entscheidend ist jedoch vor allem die Einzigartigkeit eines Kennworts – insbesondere angesichts umfangreicher Passwortdatenbanken aus früheren Sicherheitsvorfällen. Die von Troy Hunt betriebene Website "Have I Been Pwned" verdeutlicht die Dimension dieses Problems.
Bild 1 zeigt ein Codebeispiel, das mit wenigen Zeilen das "Have I Been Pwned"-API nutzt, um Passwörter zu prüfen, ohne sie einer Website anzuvertrauen. Das API akzeptiert einen Teil des Hash-werts eines Klartextpassworts und liefert dazu passende Hashwerte kompromittierter Kennwörter zurück. Sie vergleichen diese lokal mit dem vollständigen Hashwert Ihres Passworts. So prüfen Sie dessen Gefährdung, ohne das eigentliche Kennwort preiszugeben.
Bild 1: Mit wenigen Zeilen in der PowerShell lässt sich vertraulich prüfen, ob Passwörter Teil eines Sicherheitsvorfalls waren.
Statt Mitarbeiter regelmäßig zum Passwortwechsel zu zwingen, ist es sinnvoller, ihnen ein zufällig generiertes und gegen bekannte Passwortdatenbanken geprüftes Kennwort vorzugeben. So erhöhen Sie die tatsächliche Sicherheit, ohne zusätzliche Komplexität durch häufige Änderungen zu erzeugen. Bemerkenswert ist, dass auch das BSI in seinen Empfehlungen seit Langem keine kurzen Passwortlaufzeiten mehr vorsieht. Stattdessen positioniert die Behörde die Zwei-Faktor-Authentifizierung (2FA) als zentrale Schutzmaßnahme [1].
Zweiter Faktor erhöht Sicherheit und Hürden
2FA kombiniert Wissen wie Passwort oder PIN mit Besitz, etwa einem FIDO2-Token oder Smartphone. Phish- ing-resistente Verfahren wie Passkeys erhöhen das Sicherheitsniveau deutlich und sind klar zu empfehlen. Passkeys basieren auf dem FIDO2-Standard und nutzen das WebAuthn-Protokoll. Sie lassen sich softwarebasiert oder mit einem dedizierten "Hardware-Security-Key" einsetzen. Token2 und Yubico zählen zu bekannten Herstellern solcher Token. Viele Passwortmanager unterstützen Passkeys inzwischen als reine Softwarevariante, etwa 1Password, Bitwarden oder Proton Pass.
Der Schwerpunkt dieser Verfahren liegt meist auf der Browseranmeldung. In der Praxis wünschen sich Anwender jedoch eine systemweite Unterstützung, beispielsweise für die Anmeldung am Betriebssystem per FIDO2. Genau hier zeigt sich die Fragmentierung: Windows 11 unterstützt mit "Windows Hello for Business" ein eigenes Verfahren, doch selbst Windows Server integriert diese Technik nicht durchgängig.
FIDO2-Token ähneln USB-Sticks und nutzen typischerweise USB-A, USB-C oder NFC. In heterogenen Umgebungen entsteht jedoch schnell ein praktisches Problem: Nicht jedes Endgerät unterstützt jede Schnittstelle. Softwarebasierte Passwortmanager wirken hier oft pragmatischer, erhöhen jedoch die betriebliche Komplexität – insbesondere bei weniger technikaffinen Mitarbeitern.
Einmalpasswörter: universell einsetzbar
Neben Passkeys bieten Einmalpasswörter (One-Time Password, OTP) nach dem TOTP-Standard eine etablierte Alternative. Sie lassen sich in vielen Szenarien einfacher umsetzen. Denn für viele IT-Abteilungen ist nicht allein die Sicherheitsstrategie Treiber für die Einführung eines zweiten Faktors, sondern der Druck durch Cloudanbieter wie Microsoft. Dieser Zwang erhöht zwar kurzfristig den Aufwand, verbessert jedoch das Sicherheitsniveau nachhaltig [2].
OTP zählen zu den verbreitetsten und praxistauglichsten 2FA-Verfahren. Insbesondere TOTP (Time-based One-Time Password) hat sich hier als De-facto-Standard etabliert. Die Technologie basiert auf RFC 4226 (HOTP) und RFC 6238 (TOTP) und wird von nahezu allen großen Diensten unterstützt – von Google über Microsoft bis GitHub. OTP-Verfahren haben jedoch Grenzen: Sie sind nicht Phishing-resistent. Zudem empfinden Nutzer den parallelen Einsatz zweier Geräte häufig als umständlich. Für Administratoren ist ein fundiertes Verständnis der Technologie dennoch essenziell, sowohl für die Einführung als auch für die Integration in eigene Systeme.
Kern jeder OTP-Implementierung ist ein gemeinsames Geheimnis, das sogenannte Secret oder Seed. Dabei handelt es sich um einen kryptografisch starken Schlüssel, den Server und Authenticator-Client – etwa eine Smartphone-App – speichern. Dieses Secret besteht aus einer zufällig erzeugten Bitfolge mit typischerweise 80 bis 160 Bit Länge. Die Sicherheit eines OTP-Verfahrens hängt unmittelbar von der Länge des Secrets ab. Das Einmalpasswort stellt dabei nur eine Komponente der Zwei-Faktor-Authentisierung dar. Als Mindestgröße gelten 80 Bit (10 Byte), bei erhöhten Sicherheitsanforderungen sollten 160 Bit (20 Byte) zum Einsatz kommen.
Entscheidend ist eine kryptografisch sichere Generierung des Secrets. Einfache Zufallszahlengeneratoren sind ungeeignet. Unter .NET verwenden Entwickler dafür die Klassen "RandomNumberGenerator" oder "RNGCryptoServiceProvider". Wir nutzen beispielhaft die verbreitete Open-Source-Bibliothek "Otp.NET.dll" [3] und die PowerShell:
Es gibt zwei Varianten von OTP: HOTP (HMAC-based One-Time Password, RFC 4226) und TOTP (Time-based One-Time Password, RFC 6238). Beide verwenden denselben kryptografischen Mechanismus, unterscheiden sich jedoch in der Art der Generierung des Zählerwerts. HOTP basiert auf einem inkrementierenden Zähler. Mit jeder Codegenerierung erhöht sich dieser Zähler um eins. Der Vorteil: HOTP funktioniert vollständig offline und benötigt keine Zeitsynchronisation. Nachteilig ist jedoch, dass Server und Client den Zählerstand konsistent halten müssen. Werden Codes übersprungen oder mehrfach erzeugt, kann die Synchronisation verloren gehen. HOTP kommt typischerweise mit dedizierter Hardware zum Einsatz, die den Zähler verwaltet und den Code anzeigt. Entsprechende Token existieren unter anderem im Girokarten-Format.
TOTP nutzt hingegen die aktuelle Zeit als Grundlage. Dazu teilt das Verfahren den Unix-Timestamp – Sekunden seit dem 1. Januar 1970 – durch 30 und rundet das Ergebnis ab. So entsteht ein Zeitwert, der sich alle 30 Sekunden automatisch ändert. Der zentrale Vorteil liegt in der impliziten Synchronisation über die Systemzeit. Das kurze Zeitfenster reduziert zudem das Risiko erfolgreicher Man-in-the-Middle-Angriffe deutlich.
Vielen Anwendern wie auch Administratoren ist nicht bewusst, dass dieses Geheimnis zeitlich unbegrenzt gültig ist. Sie können einen Screenshot des QR-Codes erstellen und ausdrucken oder die in Bild 2 dargestellte Zeichenfolge ("Secret Key") in einem Tresor oder Passwortmanager speichern. Was zunächst wie ein Sicherheitsrisiko wirkt, erweist sich in der Praxis als Vorteil: Wechseln Sie das Smartphone ohne Backup, installieren Sie einfach eine beliebige Authenticator-App neu und scannen den gesicherten QR-Code erneut. Die Sicherheit des Verfahrens hängt jedoch vollständig von der vertraulichen Aufbewahrung dieses Seeds ab. Viele Anbieter zeigen das Geheimnis nur einmal während der Einrichtung an. Danach bleibt häufig nur das Löschen und erneute Einrichten des zweiten Faktors.
Bild 2: Der Secret Key ist insofern komfortabel, als dass er sich leicht auf ein neues Gerät verschieben lässt.
Authenticator-Apps für TOTP
TOTP-Clients, meist als Authenticator bezeichnet, lassen sich mit geringem Aufwand implementieren. Das Prinzip ist einfach: Authenticator (Client) und Verifier (Server beziehungsweise Anmeldeseite) berechnen auf Basis eines gemeinsamen Secrets und der aktuellen Uhrzeit einen Prüfcode. Diesen in der Regel sechsstelligen Code gibt der Benutzer zusätzlich zum Passwort ein. Der Server vergleicht diesen Input mit der eigenen Berechnung und entscheidet über die Anmeldung.
Am weitesten verbreitet ist der Google Authenticator, gefolgt vom Microsoft Authenticator und zahlreichen weiteren TOTP-Apps. Ein Blick lohnt sich auch auf "Proton Authenticator" und "Proton Pass". Beide unterstützen TOTP, bieten eine kostenfreie Grundfunktionalität und stehen für mehrere Betriebssysteme zur Verfügung. In der Praxis hat sich TOTP durchgesetzt, da die automatische Zeitsynchronisation die Handhabung deutlich vereinfacht. Moderne Authenticator-Apps unterstützen überwiegend TOTP, während HOTP meist speziellen Szenarien vorbehalten bleibt.
Ein Praxistipp: Sie können den zweiten Faktor problemlos auf mehreren Geräten einrichten. Soll im Unternehmen etwa ein Funktionskonto zur Verwaltung der EntraID-Lizenzen entstehen, das keiner einzelnen Person zugeordnet ist, scannen mehrere berechtigte Mitarbeiter denselben QR-Code. Auch für ein Notfallkonto bietet sich dieses Vorgehen an. In diesem Fall drucken Sie Benutzername, Passwort und Seed aus und hinterlegen die Unterlagen im Safe der Geschäftsführung.
Die Sicherheit von OTP steht und fällt mit dem Schutz des Secrets. Sie sollten es weder unverschlüsselt speichern noch leichtfertig weitergeben. Die genannten Praxisansätze können aus Sicherheitsperspektive kritisch wirken, erweisen sich bei kontrolliertem Einsatz jedoch als hilfreiche Rückfallebene. Doch wie eingangs erwähnt, schützt OTP nicht vor Phishing. Ein Angreifer kann eine gefälschte Anmeldeseite betreiben, den Benutzer zur Eingabe des aktuellen Codes verleiten und diesen unmittelbar weiterverwenden. Wenn Sie ein höheres Schutzniveau benötigen, prüfen Sie moderne Verfahren wie Passkeys, die auf kryptografischer Authentifizierung ohne Codeübertragung basieren.
Bild 3: Ein Beispiel für einen TOTP-Prüfcode – hier im im Proton Authenticator.
Den TOTP-Algorithmus detailliert verstehen
Nach der Generierung des Secrets berechnet das Verfahren den Zeitfaktor. Dazu teilt es wie angesprochen den aktuellen Unix-Timestamp durch 30 und rundet ab. Das 30-Sekunden-Intervall stellt einen praxisgerechten Kompromiss dar: Kürzere Intervalle erhöhen die Sicherheit, erschweren jedoch die Eingabe. Längere Intervalle verbessern die Bedienbarkeit, reduzieren aber das Schutzniveau. Anschließend kommt HMAC (Hash-based Message Authentication Code) zum Einsatz. Dieses Verfahren kombiniert einen Hash-Algorithmus – typischerweise SHA1, SHA256 oder SHA512 – mit einem geheimen Schlüssel. Während einfache Hash-Funktionen anfällig für bestimmte Angriffe sein können, bindet HMAC das Secret in die Berechnung ein und erhöht so die Sicherheit.
Die dynamische Trunkierung nach RFC 4226 sorgt dafür, dass nicht einfach die ersten Bytes des Hashwerts zum Einsatz kommen. Stattdessen bestimmt ein aus dem letzten Byte abgeleiteter Offset, welche vier Bytes in die weitere Berechnung einfließen. Dadurch lässt sich der relevante Abschnitt nicht vorhersagen. Aus diesen vier Bytes entsteht eine 31-Bit-Zahl. Durch die Modulo-Operation mit 1.000.000 erzeugt das Verfahren einen sechsstelligen Code. Für sieben- oder achtstellige Codes verwenden Sie entsprechend 10.000.000 beziehungsweise 100.000.000 als Divisor.
Das Listing "TOTP im Detail" zeigt die Umsetzung des Algorithmus in Power-Shell. In Kombination mit dem zuvor gezeigten Generieren des Seed in der PowerShell erhalten Sie einen funktionsfähigen TOTP-Client.
Listing: TOTP im Detail
# Laden der Otp.NET-Bibliothek
Add-Type -Path .\lib\Otp.NET.dll
# 1. Konvertieren des Base32-kodierten Seed zu einem Byte-Array
Ein OTP-Client muss keine Smartphone-App sein, auch wenn die Erzeugung des zweiten Faktors auf einem separaten Gerät weiterhin zu empfehlen ist. Mit dem PowerShell-Modul "OTP" [4] erzeugen Sie auf einfache Weise Einmalpasswörter zu einem gegebenen Geheimnis (Seed). Die grundlegenden Bausteine haben Sie in den vorherigen Listings bereits kennengelernt.
Das OTP-Modul entstand ursprünglich als Lehrbeispiel. Der Quelltext ist vollständig einsehbar, und die Projektseite bietet weiterführende Dokumentation, die die Funktionsweise im Detail erläutert und zu eigenen Tests einlädt. Das Modul stellt Cmdlets zur Secret-Generierung (New-OTPSecret), zur Codegenerierung (Get-OTPCode) sowie zur Verarbeitung von QR-Codes (Read-OTPQRCode, New-OTPQRCode) bereit. Die Installation des Moduls ist schnell erledigt:
Install-Module -Name "OTP‘ -Scope CurrentUser
Get-OTPCode -Seed "M5K6Z7MDJ6KJ2LHC‘
Das Modul verdeutlicht das Zusammenspiel der beschriebenen Komponenten: kryptografisch sichere Generierung des Secrets, Base32-Kodierung, HMAC-Berechnung und Extraktion des Einmalcodes. Für die Verwaltung mehrerer OTP-Accounts stellt es eine tagbasierte Organisation sowie Console- und GUI-basierte Ausgabeformate bereit.
In Laborumgebungen oder Schulungen ist es oft aufwendig, zahlreiche Testkonten inklusive zweitem Faktor zu pflegen und mehreren Entwicklern, Beratern und Administratoren Zugriff zu gewähren. Mit dem OTP-Modul lesen Sie beliebig viele Seeds ein, zeigen den jeweils aktuellen OTP-Code an und aktualisieren ihn automatisch. Dabei übergeben Sie entweder den alphanumerischen Seed direkt oder lesen Bilddateien mit QR-Codes ein.
Fazit
TOTP hat sich als Standard für die Zwei-Faktor-Authentisierung etabliert. Das Verfahren lässt sich vergleichsweise einfach implementieren, ist breit kompatibel und erhöht das Sicherheitsniveau deutlich gegenüber rein passwortbasierten Systemen. Gerade wegen dieser überschaubaren Komplexität eignet sich TOTP auch für eigene Anwendungen. Dennoch stößt die Technologie an Grenzen: TOTP schützt nicht vor Phishing und setzt eine verlässliche Zeitsynchronisation voraus. Bei erhöhten Sicherheitsanforderungen sollten Sie moderne Alternativen wie Passkeys prüfen, die auf WebAuthn beziehungsweise FIDO2 basieren und eine kryptografische Authentifizierung ohne Codeübertragung ermöglichen.
Für viele Szenarien bleibt TOTP jedoch ein pragmatisches und angemessen sicheres Verfahren. Die breite Unterstützung durch Authenticator-Apps und die einfache Integration sprechen weiterhin für diesen Ansatz. Einen eigenen OTP-Client implementieren Sie mit überraschend wenig Aufwand.