14. November 2015

Wider den Kontrollverlust: Mehr-Faktor-Authentisierung zum Schutz der eigenen Daten

Kontrollverlust

Der Untertitel hätte auch Wider den Kontrollverlust heißen können.

Denn nicht nur gleitet uns angesichts ansteigender Überwachungsszenarien und Diskussionen über Routerzwang und Netzneutralität die Kontrolle aus den Händen. Bisweilen geben wir die Kontrolle auch freimütig selber ab. Ich rede hier nicht von der Medieninkompetenz, die wir auf den sozialen Netzwerken betreiben. Vielmehr geht es mir – meinem Beruf entsprechend – um die Datensicherheit in den Unternehmensnetzwerken.

Hier wird es für Unternehmen zusehends attraktiver, die Authentisierungsinfrastruktur zu outsourcen.

Sowohl für das Unternehmen, das seine Mitarbeiter authentifizieren möchte, als auch für die andere Seite. Die klassischen Player am Markt haben für sich das Geschäftsmodell entdeckt, Mehr-Faktor-Authentisierung als gehostete Dienste zu betreiben. Für die Kunden wirkt das ebenfalls attraktiv:

Die IT-Abteilung muss keinen OTP-Server installieren oder keine PKI aufsetzen. Man kann die (virtuellen) Server sparen und muss sich nicht mehr um Software-Updates und Security-Patches kümmern. Und vielleicht kann man so auch schließlich die IT-Abteilung verschlanken.

Doch möchte man Zwei-Faktor-Authentisierung richtig betreiben, muss man sein Augenmerk auf drei Punkte legen:

Der Algorithmus

Einmalpasswort-Authentisierung basiert auf einem symmetrischen Algorithmus. Der Token (als der Besitz) und das Serverbackend (wie bpsw. privacyIDEA) müssen den gleichen Algorithmus und das gleiche Schlüsselmaterial verwenden, um ein Einmal-Passwort zu berechnen. Ein solcher Algorithmus muss sicherstellen, dass von dem aktuellen Einmalpasswort oder einer Reihe älterer Einmalpassörter nicht auf das nächste Einmalpasswort geschlossen werden kann. Auf jeden Fall muss auch verhindert werden, dass man mit einer Liste von alten Einmalpasswörtern sogar den geheimen Schlüssel berechnen könnte. In einem solchen Fall könnte ein Angreifer den geheimen Schlüssel berechnen und sich eine Kopie des Besitzfaktors erzeugen. Die Idee des Besitzes, anhand dessen der Benutzer authentifiziert werden soll, wäre also dahin. Es gäbe keinen eindeutigen Besitz mehr.

Der Algorithmus muss also gewährleisten, dass solche Angriffe nicht leicht möglich sind.

Standardisierte Algorithmen wie HOTP oder TOTP bieten den Vorteil, dass man sich von den Stärken und den Grenzen oder Schwächen der Algorithmen selber überzeugen kann und somit in der Lage ist, die richtigen Entscheidungen zu treffen. Hierzu hatte ich einen Artikel über HOTP oder TOTP verfasst.

Proprietäre Algorithmen verhindern, dass man sich über die Verlässlichkeit und die Grenzen des Algorithmus selber ein Urteil bilden kann. Man muss die Kontrolle aus der Hand geben und komplett auf die Aussage des Herstellers vertrauen. "Security by Obscurity" war in der IT-Sicherheit noch nie die richtige Wahl!

Anforderung: Der verwendete Algorithmus sollte ein offener, standardisierter Algorithmus sein.

Das Schlüsselmaterial

OTP-Token arbeiten mit einem symmetrischen Schlüssel – X.509-Zertifikate mit einem asymmetrischen. Es gibt also einen symmetrischen geheimen oder einen asymmetrischen privaten Schlüssel, der für die Authentisierung verwendet wird. Es gilt, diesen geheimen Schlüssel zu schützen. So lange kein anderer an diesen Schlüssel kommt, ist es möglich, den Benutzer sicher zu authentifizieren. Genauer gesagt, ist es möglich sicherzustellen, dass der Benutzer im Besitz des geheimen Schlüssels ist.

Oben beschrieb ich bereits, dass deswegen der Algorithmus den geheimen Schlüssel nicht preisgeben darf.

Anforderung: Aber darüber hinaus sollte der geheime Schlüssel nicht kopierbar sein.

D.h. der geheime Schlüssel sollte, wenn möglich, in Hardware existieren. Weiterhin sollte der geheime Schlüssel von Ihnen selber erzeugt worden sein.

Die meisten Hardware-Token-Hersteller erzeugen den Schlüssel heutzutage in der Fabrik. D.h. Sie als Kunde erhalten die Hardware, in der bereits ein geheimer Schlüssel enthalten ist. Da ein Backend wie privacyIDEA ebenfalls den geheimen Schlüssel kennen muss, wird vom Hersteller eine Datei mit den geheimen Sclüsseln mitgeliefert. In diesem Fall können Sie aber nicht endgültig sicher sein, ob der geheime Schlüssel in der Lieferkette vom Hersteller über den Distributor und Reseller zu Ihnen tatsächlich geheim geblieben. Angreifer, die die Lieferung abgefangen und die Datei kopiert haben oder direkt beim Hersteller eingedrungen sind, können sich nun unbemerkt als die jeweiligen Benutzer authentisieren.

Anforderung: Der geheime Schlüssel sollte von Ihnen erzeugt werden.

Kunden, die Ihren Zwei-Faktor-Authentisierungsservice hosten lassen, können niemals sicher sein, wie und wo eine weitere Kopie eines geheimen Schlüssels existiert. Der Anbieter der Authentisierungs-Hosting Lösung kann die besten und edelsten Absichten haben. Wenn er Opfer eines Angriffs oder einer gesetzlichen Verpflichtung gegenüber Geheimdiensten oder anderen Regierungsstellen wird, sind Sie als Kunde evtl. der letzte der davon erfährt.

Anforderung: Sie sollten Ihre Authentisierungslösung selber betreiben.

In meinem Vortrag gehe ich genauer auf das Thema der Besitzfaktoren und des Schlüsselmaterials ein.

Der Code

Die Software, die letztendlich im Backend darüber entscheidet ob einer Authentisierungsanfrage eines Benutzers stattgegeben wird oder nicht, kann es in verschiedenen Ausführungen geben. Software enthält viele Zeilen Code, die verschlungene Wege gehen, die demjenigen, der die Software einsetzt, evtl. nicht immer klar sind. Wie die jüngste Vergangenheit zeigt, kann Software auch Hintertüren enthalten und Funktionen bieten, die nicht beabsichtig waren – jedenfalls nicht von Ihnen als Anwender und Kunde.

Daher muss nicht nur der verwendete Algorithmus und das Schlüsselmaterial unter Ihrer Kontrolle sein. Ebenso sollten Sie in der Lage sein, zu bewerten oder bewerten zu lassen, was die Software tut. Dies geht evtl. mit Code Escrow und dem Unterzeichnen von NDAs. Letztendlich geht es aber nur, wenn der Quelltext der Software per se offen liegt.

Anforderung: Aus diesem Sicherheitsaspekt heraus ist Open Source Software als Authentisierungslösung zu bevorzugen.

privacyIDEA ist eine komplett offen liegende Open Source Software, für die wir – die NetKnights GmbH – Enterprise Support anbieten.

Aktuellste Beiträge
18. November 2024
privacyIDEA in Ohio
Die NetKnights war als Aussteller und Sponsor auf der OLF Conference 2024 in Ohio. Dort wurde privacyIDEA vor einem internationalen Publikum diskutiert, neue Kontakte geknüpft und internationale Kunden wiedergetroffen.
1. November 2024
Zeit für einen Monatsrückblick im Hause NetKnights. Viel ist passiert: Wir haben die Version 3.10.1 von privacyIDEA releast, unseren ersten privacyIDEA Summit veranstaltet und unser Entwicklungs-Team hat Zuwachs bekommen.

Suche

Drücken Sie "Enter" zum Starten der Suche