Warum man Zwei-Faktor-Authentisierung im Haus und mit Open Source betrieben sollte Gegen den Kontrollverlust: Alles meins!

Uns gleitet nicht nur durch zunehmende Überwachungsszenarien die Kontrolle aus den Händen. Manche Unternehmen geben die Kontrolle auch selber ab, nämlich die Datensicherheit in ihren Netzwerken. Outsourcing ist kein Königsweg, erklärt Cornelius Kölbel*.

Anbieter zum Thema

FNT GmbH

Cohesity GmbH

Schwarz IT KG

Es wird für Unternehmen offenbar zusehends attraktiver, die Authentisierungs-Infrastruktur an Dienstleister auszulagern. Player am Security-Markt haben die Business-Chance entdeckt, Mehr-Faktor-Authentisierung als gehostete Dienste zu betreiben. Für die Kunden wirkt das attraktiv; denn ihre IT-Abteilung muss keinen Server für One-Time-Passwörter (OTP) installieren. Man kann sich die (virtuellen) Server sparen und muss sich nicht mehr um Software-Updates und Security-Patches kümmern. Und vielleicht kann man so auch die IT-Abteilung „verschlanken“.

Was den zweiten Faktor der Authentisierung ausmacht

Zwei-Faktor-Authentisierung ist endlich in den Köpfen der meisten IT-Entscheider angekommen. Der Anwender hat nicht nur ein Passwort, ein Wissen, das so flüchtig ist, dass es gern notiert (und damit kopierbar) wird. Vielmehr kommt als zweiter Faktor der Besitz hinzu, zum Beispiel ein Token mit einem Einmal-Passwort. Doppelte Sicherheit! Doch möchte man Zwei-Faktor-Authentisierung richtig betreiben, muss man sein Augenmerk auf drei Punkte legen: den Algorithmus, das Schlüsselmaterial und den Code.

Kriterium 1: der Algorithmus

Einmal-Passwort-Authentisierung basiert auf einem symmetrischen Algorithmus. Der Token (als der Besitz) und das Server-Backend müssen den gleichen Algorithmus und das gleiche Schlüsselmaterial verwenden, um ein Einmal-Passwort zu berechnen. Ein solcher Algorithmus muss sicherstellen, dass sich von dem aktuellen Einmal-Passwort oder einer Reihe älterer nicht auf das nächste Einmal-Passwort schließen lässt.

Auf jeden Fall gilt es ferner zu verhindern, dass man mit einer Liste von alten Einmal-Passwörtern sogar den geheimen Schlüssel berechnen könnte. In einem solchen Fall könnte ein Angreifer an den geheimen Schlüssel kommen und sich eine Kopie des Besitzfaktors (Token) erzeugen. Die Idee, den Benutzer anhand seines Besitzes zu authentifizieren, wäre dahin; denn es gäbe keinen eindeutigen Besitz mehr.

No Security by Obscurity

Der Algorithmus muss also gewährleisten, dass solche Angriffe nicht leicht möglich sind. Standardisierte Algorithmen wie HOTP oder TOTP (Ereignis- beziehungsweise Zeit-basiertes One Time Password) bieten einen Vorteil: Sie sind offen dokumentiert. Ergo kann sich ein Unternehmen von den Stärken und den Grenzen oder Schwächen dieser Algorithmen selber überzeugen und die richtigen Entscheidungen treffen.

Proprietäre Algorithmen hingegen verhindern, dass sich ein IT-Sicherheits-Verantwortlicher selbst ein Urteil über die Verlässlichkeit und die Grenzen des Algorithmus bilden kann. Man gibt die Kontrolle aus der Hand und muss komplett auf die Aussage des Herstellers vertrauen. „Security by Obscurity“ war in der IT-Sicherheit noch nie die richtige Wahl. Daraus folgt eine Anforderung: Der verwendete Algorithmus sollte ein offener, standardisierter Algorithmus sein.

(ID:43727298)