{"id":246,"date":"2019-10-14T13:14:45","date_gmt":"2019-10-14T13:14:45","guid":{"rendered":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/?p=246"},"modified":"2020-05-06T13:53:48","modified_gmt":"2020-05-06T13:53:48","slug":"lets-talk-about-security-digital-identity","status":"publish","type":"post","link":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/lets-talk-about-security-digital-identity\/","title":{"rendered":"Let’s Talk About Security \u2013 Digital Identity"},"content":{"rendered":"\n

Das Thema Sicherheit ist in der heutigen Zeit wichtiger denn je. Beinahe alles wurde digitalisiert und befindet sich in einem eigenen Netzwerk oder ist mit dem Internet verbunden. Somit ist es theoretisch m\u00f6glich, von einem Client s\u00e4mtliche Server anzusprechen, die mit dem Internet verbunden sind. Wenn man es mit der Realit\u00e4t vergleichen w\u00fcrde, stehen s\u00e4mtliche Geb\u00e4ude auch irgendwo auf der Welt und k\u00f6nnten betreten werden, wenn es nicht die Sicherheitsvorkehrungen geben w\u00fcrde. Genau solche Sicherheitsvorkehrungen gibt es im Internet auch, um das unerlaubte Eindringen zu verhindern.<\/p>\n\n\n\n

Ich bin anf\u00e4nglich sehr blau\u00e4ugig an das Thema herangegangen und habe gedacht, beim Programmieren einer Internetseite w\u00fcrde es ausreichen eine Login-Maske zu erstellen. Somit h\u00e4tte ich alle anderen ausgesperrt und es h\u00e4tten nur die Nutzer Zugriff auf die Seite, denen ich den Zutritt vorher erlaubt h\u00e4tte. Doch dann wurde ich mit Man-in-the-Middle, DOS-Angriffen und Zertifikaten konfrontiert. Zum Gl\u00fcck gibt es Organisationen wie die OWASP<\/a> (Open Web Application Security Project), die es sich zur Aufgabe gemacht haben, die Sicherheit im World Wide Web zu verbessern. Daf\u00fcr stellen sie kostenfrei Informationen, Werkzeuge und Methoden zur Verf\u00fcgung, mit denen sich jeder ein gewisses Grundwissen aneignen kann. Auf der Internetseite der OWASP gibt es eine Auflistung der Top-10-Sicherheitsl\u00fccken, die in vielen der aktuellen Applikationen vorhanden sind. Diese Sicherheitsl\u00fccken werden dort erl\u00e4utert und Ma\u00dfnahmen erkl\u00e4rt, wie sie so gut wie m\u00f6glich geschlossen werden k\u00f6nnen. Dabei geht es von der SQL-Injektion und der unsicheren Authentifizierung bis zum Upload von Dateien.<\/p>\n\n\n\n

\"Mauszeiger
Abbildung 1: Let’s Talk About Security<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n

Um besser auf die Sicherheitsl\u00fccken und m\u00f6glichen Sicherheitsvorkehrungen einzugehen werde ich dem Entwickler Sebastian Sicher bei der Programmierung seiner Website folgen. Auf der Internetseite k\u00f6nnen sich Schlosser registrieren, die einen Schl\u00fcsseldienst anbieten. Sebastian hat die Internetseite grundlegend erstellt und befasst sich nun mit der Authentifizierung der Benutzer \u2013 der Digital Identity. Dabei geht es darum zu beweisen, dass es sich bei der Person, die das System nutzen m\u00f6chte, auch wirklich um die Person handelt, die die Berechtigung dazu besitzt. Daf\u00fcr wird ein Session Management genutzt, welches die Aufgabe besitzt, die Sitzung des Nutzers zu \u00fcberpr\u00fcfen, damit dieser sich nicht st\u00e4ndig neu anmelden muss, w\u00e4hrend er am System arbeitet. Es wurde auch ein Standard (NIST 800-63b) vom NIST<\/a> (National Institute of Standards and Technology) aufgesetzt, welcher den Nutzer bei der Einrichtung einer Digital Identity leitet. Sebastian hat f\u00fcr die Authentifizierung ein Login-Fenster erstellt, dass dazu dient, sich zu registrieren und anzumelden. Damit die Website von Sebastian nicht gehackt werden kann, gehe ich hier auf ein paar wichtige Punkte ein, die bei der Authentifizierung beachtet werden sollten und die aus QA-Sicht wichtig sind.<\/p>\n\n\n\n

Das simpelste Beispiel f\u00fcr die Authentifizierung, welches man finden kann, ist ein einfaches Passwort. Das vom Benutzer erstellte einfache Passwort speichert Sebastian in seinem System ab und \u00fcberpr\u00fcft es, wenn der Benutzer sich anmelden m\u00f6chte. Dabei ist allgemein bekannt, dass ein komplexes Passwort genutzt werden sollte, damit dieses nicht \u00fcber das Bruteforce-Verfahren zu schnell ermittelt werden kann. Das NIST gibt dabei mehrere Empfehlungen oder Richtlinien vor, die eingehalten werden sollten, damit die Passw\u00f6rter sicher sind. So wird empfohlen, dass ein Passwort mindestes 8, wenn nicht sogar 12 Zeichen lang sein sollte, da die Anzahl an Zeichen die Varianten f\u00fcr das Bruteforce-Verfahren exponentiell steigert. Weiterhin sollten keine Standardw\u00f6rter verwendet werden, selbst wenn Sonderzeichen hineingesetzt werden. Ein Beispiel w\u00e4re das Wort \u201ePasswort\u201c zu \u201ePa\u00a7\u00a7w0r1\u201c zu \u00e4ndern. Die meisten Brutefore-Algorithmen erkennen solche Konstrukte schnell. Sonderzeichen erbringen heute nicht mehr dieselbe Effizienz wie fr\u00fcher, da die Verfahren zum Entschl\u00fcsseln eines Passwortes s\u00e4mtliche Sonderzeichen mit einbeziehen. Es wird daher eher empfohlen, f\u00fcr ein sicheres Passwort lange und kryptische Passphrasen zu verwenden.<\/p>\n\n\n\n

Der wichtigere Punkt an dieser Stelle ist allerdings die Speicherung der Passw\u00f6rter auf Sebastians System. Bei kleineren Anwendungen k\u00f6nnen die Passw\u00f6rter in JSON-Dateien abgelegt werden, doch unser Entwickler m\u00f6chte eine gro\u00dfe und weiterreichende Applikation erstellen. Da die Strukturen hier somit komplexer werden, werden die Passw\u00f6rter in einer Datenbank gespeichert. Weil Sebastian keine gr\u00f6\u00dferen Sicherheitskenntnisse besitzt, speichert er die Passw\u00f6rter in seiner Datenbank ohne Verschl\u00fcsselung ab. Er vermutet, dass sowieso niemand auf sein System k\u00e4me, ohne dass er sich offiziell registriert h\u00e4tte. Die Top-10-Sicherheitsl\u00fccken von OWASP zeigen allerdings, dass Datenbank-Leaks zu einer der h\u00e4ufigsten Sicherheitsschwachstellen geh\u00f6ren. Er muss daher davon ausgehen, dass die Angreifer auf die Daten der Datenbank zugreifen k\u00f6nnen. Dadurch, dass sie dort unverschl\u00fcsselt gespeichert wurden, k\u00f6nnte sich ein Angreifer problemlos die Login-Informationen aller User seiner Website aneignen. Darum ist es sehr wichtig, alle Passw\u00f6rter verschl\u00fcsselt zu speichern. Hierzu k\u00f6nnen verschiedene Hash-Algorithmen, z. B. SHA256, WHIRLPOOL oder TIGER2 verwendet werden. Diese Algorithmen liefern eine Zeichenkette, die nach heutigem Wissenstand nicht entschl\u00fcsselt werden kann.<\/p>\n\n\n\n

\"Ausschnitt
Abbildung 2: Zeichenkette zur Verschl\u00fcsselung<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n

Somit w\u00e4ren die Passw\u00f6rter gesichert, auch wenn sie gestohlen werden. Leider werden viele dieser Algorithmen mit der Zeit effizienter \u201egeknackt\u201c. Man kann die Hashes zwar nicht entschl\u00fcsseln, aber es ist m\u00f6glich, mit Hilfe von Rainbow-Tabellen die Passw\u00f6rter aus den Hashes zur\u00fcckzuverfolgen. Rainbow-Tabellen sind eine Auflistung von unz\u00e4hligen Passw\u00f6rtern, die mit dem speziellen Algorithmus codiert wurden. Dem entsprechend ist es m\u00f6glich, mit dem Hash \u00fcber solche Rainbow-Tabellen die Passw\u00f6rter zu finden. Hier ist beispielsweise eine solche Rainbow-Tabelle<\/a>.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Beispiel Passwort R\u00fcckf\u00fchrung:<\/p>\n\n\n\n

NTLM Hash: 2b5cec7f00f89013efd8d2b0b5f6ac23
Entschl\u00fcsseltes Passwort: NecoPasswort<\/p>\n\n\n\n

<\/div>\n\n\n\n

Daher ist es wichtig, dass ein sicherer Algorithmus zur Verschl\u00fcsselung gew\u00e4hlt wird. Der Hash-Algorithmus NTLM kann mit den heutigen Verfahren bei einer L\u00e4nge von 8 Zeichen innerhalb von wenigen Minuten gel\u00f6st werden. Um solche R\u00fcckf\u00fchrungen \u00fcber Rainbow-Tabellen zu erschweren, ist es f\u00fcr Sebastian notwendig, weitere Vorkehrungen zur Verschl\u00fcsselung zu verwenden. Hier f\u00e4llt die Wahl auf die SALT & PEPPER-Variante.  Das Passwort, welches der Nutzer zum Login verwendet, wird mit einem SALT-String erg\u00e4nzt und daraufhin gehashed. Dadurch wird das Passwort komplexer und kann nicht mit einfachen Rainbow-Tabellen entschl\u00fcsselt werden. Es wird empfohlen, f\u00fcr jeden Benutzer einen eigenen SALT-String zu erzeugen, um eine h\u00f6here Varianz zu bekommen. Die Schwachstelle vom SALT ist, dass sie genauso wie die Passwort-Hashes auch in der Datenbank gespeichert werden. Sie k\u00f6nnen zwar in unterschiedlichen Tabellen gespeichert werden, doch sobald ein Angreifer sich Zugriff auf die Datenbank verschafft hat, ist es dem Angreifer m\u00f6glich, die SALTs auszulesen und zum Entschl\u00fcsseln zu verwenden. Daher kommt noch eine zweite Stufe der Verschl\u00fcsselung hinzu \u2013 der PEPPER. Der PEPPER-String funktioniert auf dieselbe Weise wie der SALT. Es wird ein String vor dem Hashen des Passwortes hinzugef\u00fcgt, um die R\u00fcckf\u00fchrung zu erschweren. Der PEPPER wird allerdings nicht in der Datenbank gespeichert, sondern im Quellcode hartkodiert. Somit ist es Angreifern, die nur auf die Datenbank zugreifen k\u00f6nnen, nicht m\u00f6glich, zusammen mit den Hashes auch den PEPPER aus dem Quellcode zu lesen.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"Code-Beispiel
Abbildung 3: Code-Beispiel SALT & PEPPER-Variante<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n

Sebastian hat damit seine Passwort-Hashes gesalzen und gepfeffert. Was noch angemerkt werden muss, ist, dass die Sicherheit eines Passwortes damit nicht gesteigert wird. Es wird einem Angreifer aber erschwert, mit Hilfe von Rainbow-Tabellen die Passw\u00f6rter der Nutzer zu entschl\u00fcsseln.<\/p>\n\n\n\n

Ein anderer Weg f\u00fcr Sebastian, um den Zugriff auf seine Website zu sichern, ist die Verwendung von Multi-Faktor-Authentifizierung (MFA) f\u00fcr das Login. MFA-Verfahren sind heutzutage bereits sehr verbreitet. Microsoft Azure mit seinem SMS-Code, Banken mit ihrer Chip-TAN oder der Google Authenticator. Sie alle erzeugen einen Code, sobald ein Login getriggert wurde. Diese Codes werden \u00fcber einen separaten Kanal \u00fcbertragen und bieten daher eine sehr geringe Angriffsfl\u00e4che, um die Codes auszulesen. Somit hat Sebastian eine doppelte Absicherung daf\u00fcr, dass nur legitimierte Nutzer sich auf seinem System einloggen k\u00f6nnen. Unter Umst\u00e4nden w\u00e4re es m\u00f6glich, \u00fcber den Weg von SQL-Injections die Passw\u00f6rter zu stehlen, doch ein Login w\u00e4re unm\u00f6glich, solange der Angreifer nicht zus\u00e4tzlich \u00fcber den MFA-Code verf\u00fcgt.<\/p>\n\n\n\n

Aus der QA-Sicht ist es wichtig zu ermitteln, wie die Passw\u00f6rter auf einem System gespeichert sind und sich die folgenden Fragen zu stellen:<\/p>\n\n\n\n