Wohl fast so alt wie der Computer ist das Prinzip, digitale Informationen mit dem Benutzernamen und Passwort zu schützen. Mittlerweile wissen die meisten, dass es keine gute Idee ist, das Passwort unter der Tastatur aufzubewahren oder bei sämtlichen Diensten dasselbe Passwort zu verwenden. Unser Sicherheitsbedürfnis scheint zudem erfüllt zu sein, wenn wir Gross-, Kleinbuchstaben und Sonderzeichen bei der Erstellung unseres Passwortes verwenden. Aber sind unsere Daten so ausreichend geschützt oder wiegen wir uns tatsächlich in falscher Sicherheit?
Ein Unternehmen betreibt eine Website. Um diese immer aktuell und attraktiv zu halten, setzt es ein Content-Management-System ein. Zu jenem haben viele Mitarbeitende Zugang, unter anderem auch das technisch versierte Topmanagement. Durch eine Sicherheitslücke lesen Angreifer die Benutzerdatenbank des CMS aus. Wie konnte es dazu kommen?
Es war zuvor niemandem aufgefallen, dass die Kennwörter in dieser Datenbank nur unzureichend geschützt bzw. verschlüsselt waren. Der CEO hatte dasselbe Kennwort, nicht nur für die Verwaltung der Website, sondern auch für seinen privaten Mail-Account, genutzt. Durch diesen privaten Account liessen die Angreifer das Kennwort des Unternehmenskontos des CEOs zurücksetzen und hatten anschliessend uneingeschränkten Zugang zu allen Unternehmensdaten. Niemand hinterfragte den Passwort-Reset kritisch, da die Anfrage über den privaten Mailaccount des CEOs kam.
Zugegeben, das Ganze klingt nach einem wohl konstruierten Schulungsbeispiel, war aber für eine namhafte US-Sicherheitsfirma bitterer Ernst und kostete das Unternehmen nicht nur die Reputation.
Wie sieht eine sichere Authentisierung aus?
Was können wir aus diesem Beispiel in Bezug auf die eigene Authentisierungsmethode lernen? Grundsätzlich waren die Gründe und Details des Angriffs vielfältig. Trotzdem war die Katastrophe letzten Endes auf menschliches Versagen zurückzuführen… und auf die Nutzung eines Authentisierungssystems, das dies tolerierte:
- Ein einzelnes Passwort reichte, um Zugang zu mehreren Accounts zu erlangen. Dies darf mit einer starken Authentisierungslösung nicht möglich sein.
- Das Passwort konnte problemlos von jeder Person verwendet werden. Egal, ob es durch Verlust oder durch mutwillige Weitergabe abhandengekommen war. Die Identität muss «dem Benutzer ans eigene Bein gekettet», also nicht übertragbar, sein.
- Nicht jedes Passwort, das wir einer Datenbank anvertrauen, wird auch sorgfältig gehütet. Das Verfahren muss einen nicht statischen, vorhersehbaren oder konservierbaren Faktor enthalten.
Resignieren? Niemals!
Ein möglicher Ansatz das Problem zu lösen, beschreibt das MFA (Multifactor Autentication) respektive 2FA Paradigma. Dabei besitzt der Benutzer eines Accounts zwei «Geheimnisse», um seinen Account zu nutzen. Von diesen ist in der Regel eines ein Passwort. Es ist etwas, das ausser dem Benutzer niemand weiss – eben «something you know». Der zweite Faktor, ein «something you have», ist etwas, das der Benutzer hat, aber nicht weitergeben oder kopieren kann. In der Vergangenheit wurde dafür meist ein One-Time-Pad Token in Form eines Schlüsselanhängers verwendet. Moderne Verfahren binden sich heutzutage mittels Mobile-App oder Anrufverifizierung jeweils an das persönliche Mobiltelefon eines Benutzers. Eine erfahrungsgemäss sehr sichere Methode die Weitergabe des Geheimnisses zu unterbinden. Wer gibt denn sein persönliches Smartphone gerne für mehr als ein paar Minuten aus der Hand? Auch interessant sind Faktoren wie Zertifikate, die Benutzer fix an ihr Endgerät, z. B. ein spezielles Tablet oder Notebook binden.
Mehrere Faktoren steigern aber die Komplexität und werfen in der Praxis ein neues Problem auf: Was muss ein IT-Verantwortlicher tun, um das breite Portfolio an Services durch eine MFA-konforme Authentisierung zu schützen? Schliesslich bieten die wenigsten Applikationen von Hause aus eine MFA-Funktion an. Und wenn doch, besitzt jeder Benutzer bald einen bunten Strauss an Tokens, Apps und SMS-Calls für die verschiedenen Zugänge zu «seinem» Mail, CRM, Remoteaccess, etc. Es braucht also einen Authentifizierungspunkt, der die Authentisierung des Benutzers mit beiden Faktoren entgegennimmt, verarbeitet und dann an den Endpunkt weitergibt.
Passwort-Sicherheit im Mietmodell
An dieser Stelle setzen wir mit dem Leuchter CLOUD Gateway Service auf Basis von Citrix Netscaler an: Auf der «Vorderseite» des Gateways logt sich der Benutzer an einem Web-Panel ein: mit Benutzername, Passwort und seinem weiteren Authentisierungsfaktor. Der Leuchter CLOUD Gateway Service prüft die Eingabe der primären Zugangsdaten in Echtzeit mittels Radius- oder LDAP-Abfragen im Directory (z. B. ActiveDirectory). Durch den Einsatz von Technologien wie Microsoft Azure MFA oder Gemalto Safenet Authentication ist der Leuchter CLOUD Gateway Service fähig, unterschiedlichste Formen des 2. Faktors, also «something you have», zu verarbeiten. Dabei kann es sich um etwas Benutzergebundenes wie ein Mobile-App-Token, ein SMS oder eine «by Phonecall»-Authentication handeln oder auch um etwas Gerätespezifisches wie ein Computerzertifikat. Die Übertragung der Benutzerdaten bleibt jederzeit durch die SSL-Verbindung geschützt. Kann sich der Benutzer erfolgreich ausweisen, leitet der Leuchter CLOUD Gateway Service ihn direkt in die Applikation weiter. Der Schutz der SSL-Verbindung bleibt dabei erhalten.
Abschliessend werden folgende Begriffe zum besseren Verständnis erläutert:
Authentisierung:
Eingabe von Login-Daten in ein EDV-System zur Behauptung der Identität
Authentifizierung:
Überprüfung der Behauptung durch das EDV-Systems inkl. Ergebnis der Prüfung
Autorisierung:
Prüfung der Rechte und deren Einräumung bzw. Verweigerung.
