09.01.2016, 09:45
Hallo liebe Sponsor-Board-Mitglieder,
sofern ihr Betreiber einer eigenen Webseite seid, wird euch folgende Vortragsreihe sicherlich interessieren.
Das Hauptthema dieser Reihe wird sich um die Behandlung der übertragenen Daten über oder an eine Webapplikation drehen.
Worum geht es speziell?
Wenn Daten übertragen werden, müssen diese notwendigerweise abgesichert werden, um z.B. Fremdzugriffe auf die Datenbank zu unterbinden, Schadcode herauszufiltern oder um konsistente Daten in der Datenbank zu halten.
Der gängige Übertragungsweg bei Webapplikationen ist hierbei immer eine Anfrage des Clients an den Server, dieser verarbeitet die Daten, sendet in manchen Fällen Requests an die Persistenzschicht, erhält ein ResultSet an Daten, verarbeitet diese und sendet, je nach dem wie man sein Übertragungsmodell wählt, eine Antwort als HTML-, XML- oder JSON- Struktur.
Der heutige Teil dieser Serie behandelt das Thema der Einwegverschlüsselung, also Zeichenketten, die nicht mehr entschlüsselt werden können.
Es gibt mehrere Varianten, wie man seine Daten in der Datenbank halten kann und damit arbeitet. Der große Teil spielt sich hier jedoch meist im Plain-Text ab, was zu unsicheren Daten führt, denn sobald ein Fremdzugriff auf die Datenbank stattfindet, z.B. du SQL-Injection, dann erhält der Angreifer diese Daten klar und deutlich und muss nur noch lesen. Das Ziel einer korrekten Datenhaltung ist jedoch nicht, einfach die Daten zu speichern und abzulegen, sondern diese so zu manipulieren, dass sie einerseits weiterhin verwendbar sind, andererseits aber auch dem Angreifer eine Hürde geben, diese Daten nicht verwenden zu können, ohne Wissen über ihre Manipulationsweise zu erhalten.
Der gängige Fall, mit dem jeder Web-Entwickler zu tun hat ist die einfache Login-Kommunikation. Der Benutzer gibt seinen Benutzernamen und sein Passwort an, welche dann an den Server zur Verarbeitung schickt. Der Server wickelt diese Daten ab und setzt, je nach Struktur, einen Sessionwert auf dem Server oder liefert dem Benutzer ein Cookie oder setzt beides.
Die alte Methodik, um Passwörter in der Datenbank abzulegen, war die Funktionsweise der MD5-Verschlüsselung. Hierbei wird aus der übergebenen Zeichenkette eine 32-Zeichen lange Kette erzeugt, die nicht mathematisch umkehrbar ist. Diese Vorgehensweise nennt man Einweg-Verschlüsselung. Da es immer mehr Häufungen gegeben hat, dass Kollisionen in dieser Verschlüsselungsmethode gefunden wurden, wurde im Netz der Ruf nach einer anderen Verschlüsselung gefordert. Dementsprechend wuchs der Verwendungsgrad der Verschlüsselung SHA1.
Was sind Kollisionen?
Kollisionen entstehen dadurch, dass die gegebene Verschlüsselungsmethode bestimmte Grenzen aufweist. Im Falle von MD5 ist dies z.B. eine Länge von 32 Zeichen, was bedeutet, dass alle Zeichenketten auf diese Länge gestumpft werden. Das verwendete englische Alphabet hat hierbei 26 Schrift-Zeichen + 10 Zahlen, also pro Stelle 36 Zeichen. Dies entspricht einer möglichen Kombinationszahl von 36^32. Da dies ein endlicher Wert ist und nicht dynamisch, kann eine Zeichenkette auftauchen, die z.B. dem Hashwert des Wortes 'test' entspricht. Diesen Fall nennt man Kollision.
Sicherheit der Verschlüsselung
Da MDA5 bereits seit langem als unsicher gilt, SHA1 seit neuster Zeit ebenfalls und die Entwickler von SHA1 raten, zur neuen SHA3-Version überzugehen, gilt es zu klären, in wieweit Einweg-Verschlüsselungen sicher sind.
Man kann davon ausgehen, dass je nach Bekanntheitsgrad der Verschlüsselung, ebenfalls eine entsprechende Dunkelziffer an sogenannten Rainbow-Tables besteht. Diese Tabellen können verwendet werden, um ein einweg-Verschlüsseltes Passwort zu "cracken". Dabei werden eine Vielzahl an Kombinationen probiert, bis man aus der verschlüsselten Kombination einen Hashwert erzeugt, der gleich dem gesuchten ist. Hierbei spielt weniger die Länge des Passwortes eine Rolle, als die Länge des gesuchten Hashwertes. Natürlich ist dies ein Zusammenspiel aus beiden Seiten, jedoch ist die Zahl der möglichen Kombinationen aus 32 Stellen wie bei MD5, wesentlich geringer, als wenn man eine Verschlüsselung wählt, die z.B. 64 Stellen besitzt.
Wie mache ich meine Passwörter also sicher?
Da man bei der Webentwicklung auf bestehende Funktionen der Verschlüsselungsmethoden zurückgreift, da diese meist sehr kompliziert umzusetzen sind, kann man dennoch beherzt auf alte Funktionen wie MD5 und SHA1 zurückgreifen. Es gibt zwei Methoden, trotz der Unsicherheit dieser Verschlüsselungen, diese dennoch sicher zu machen. Diese nennen sich "Salt" oder "Pepper"
Beim "salten" ergänzt man das zu verschlüsselnde Passwort um eine vorher definierte, zufällige Zeichenfolge mit mehreren Zeichen. Dadurch erschwert man es dem Angreifer, einen Wörterbuchangriff durchzuführen, da das Passwort mit dem Salt nicht unbedingt im verwendeten Wörterbuch vorhanden ist. Dabei reicht eine Zeichenfolge von "ab" als Salt nicht unbedingt aus.
Was haben wir also bisher erreicht? Wir haben unsere Passwörter, welche bisher nur unzureichend gesichert waren und mit absehbaren Umfang entschlüsselt/"gecrackt" werden konnten, mithilfe von einem "Salt" abgesichert. Wir wissen nun, dass es durchaus Unterschiede zwischen den Hash-Längen geben kann und das durch die begrenzte Anzahl an Zeichen eines Hashs Kollisionen entstehen können.
Das erwartet euch im nächsten Teil:
Verschlüsselung und Entschlüsselung - Daten sichern und dennoch brauchbar wiederverwenden. Manche Daten, wie z.B. sensible Kundendaten, müssen zureichend gesichert werden, da diese nicht einem Angreifer in die Hände fallen dürfen. Da das Einwegverschlüsseln kein geeigneter Weg ist, um diese Daten zu sichern, müssen andere Mittel und Wege her.
sofern ihr Betreiber einer eigenen Webseite seid, wird euch folgende Vortragsreihe sicherlich interessieren.
Das Hauptthema dieser Reihe wird sich um die Behandlung der übertragenen Daten über oder an eine Webapplikation drehen.
Worum geht es speziell?
Wenn Daten übertragen werden, müssen diese notwendigerweise abgesichert werden, um z.B. Fremdzugriffe auf die Datenbank zu unterbinden, Schadcode herauszufiltern oder um konsistente Daten in der Datenbank zu halten.
Der gängige Übertragungsweg bei Webapplikationen ist hierbei immer eine Anfrage des Clients an den Server, dieser verarbeitet die Daten, sendet in manchen Fällen Requests an die Persistenzschicht, erhält ein ResultSet an Daten, verarbeitet diese und sendet, je nach dem wie man sein Übertragungsmodell wählt, eine Antwort als HTML-, XML- oder JSON- Struktur.
Der heutige Teil dieser Serie behandelt das Thema der Einwegverschlüsselung, also Zeichenketten, die nicht mehr entschlüsselt werden können.
Es gibt mehrere Varianten, wie man seine Daten in der Datenbank halten kann und damit arbeitet. Der große Teil spielt sich hier jedoch meist im Plain-Text ab, was zu unsicheren Daten führt, denn sobald ein Fremdzugriff auf die Datenbank stattfindet, z.B. du SQL-Injection, dann erhält der Angreifer diese Daten klar und deutlich und muss nur noch lesen. Das Ziel einer korrekten Datenhaltung ist jedoch nicht, einfach die Daten zu speichern und abzulegen, sondern diese so zu manipulieren, dass sie einerseits weiterhin verwendbar sind, andererseits aber auch dem Angreifer eine Hürde geben, diese Daten nicht verwenden zu können, ohne Wissen über ihre Manipulationsweise zu erhalten.
Der gängige Fall, mit dem jeder Web-Entwickler zu tun hat ist die einfache Login-Kommunikation. Der Benutzer gibt seinen Benutzernamen und sein Passwort an, welche dann an den Server zur Verarbeitung schickt. Der Server wickelt diese Daten ab und setzt, je nach Struktur, einen Sessionwert auf dem Server oder liefert dem Benutzer ein Cookie oder setzt beides.
Die alte Methodik, um Passwörter in der Datenbank abzulegen, war die Funktionsweise der MD5-Verschlüsselung. Hierbei wird aus der übergebenen Zeichenkette eine 32-Zeichen lange Kette erzeugt, die nicht mathematisch umkehrbar ist. Diese Vorgehensweise nennt man Einweg-Verschlüsselung. Da es immer mehr Häufungen gegeben hat, dass Kollisionen in dieser Verschlüsselungsmethode gefunden wurden, wurde im Netz der Ruf nach einer anderen Verschlüsselung gefordert. Dementsprechend wuchs der Verwendungsgrad der Verschlüsselung SHA1.
Was sind Kollisionen?
Kollisionen entstehen dadurch, dass die gegebene Verschlüsselungsmethode bestimmte Grenzen aufweist. Im Falle von MD5 ist dies z.B. eine Länge von 32 Zeichen, was bedeutet, dass alle Zeichenketten auf diese Länge gestumpft werden. Das verwendete englische Alphabet hat hierbei 26 Schrift-Zeichen + 10 Zahlen, also pro Stelle 36 Zeichen. Dies entspricht einer möglichen Kombinationszahl von 36^32. Da dies ein endlicher Wert ist und nicht dynamisch, kann eine Zeichenkette auftauchen, die z.B. dem Hashwert des Wortes 'test' entspricht. Diesen Fall nennt man Kollision.
Sicherheit der Verschlüsselung
Da MDA5 bereits seit langem als unsicher gilt, SHA1 seit neuster Zeit ebenfalls und die Entwickler von SHA1 raten, zur neuen SHA3-Version überzugehen, gilt es zu klären, in wieweit Einweg-Verschlüsselungen sicher sind.
Man kann davon ausgehen, dass je nach Bekanntheitsgrad der Verschlüsselung, ebenfalls eine entsprechende Dunkelziffer an sogenannten Rainbow-Tables besteht. Diese Tabellen können verwendet werden, um ein einweg-Verschlüsseltes Passwort zu "cracken". Dabei werden eine Vielzahl an Kombinationen probiert, bis man aus der verschlüsselten Kombination einen Hashwert erzeugt, der gleich dem gesuchten ist. Hierbei spielt weniger die Länge des Passwortes eine Rolle, als die Länge des gesuchten Hashwertes. Natürlich ist dies ein Zusammenspiel aus beiden Seiten, jedoch ist die Zahl der möglichen Kombinationen aus 32 Stellen wie bei MD5, wesentlich geringer, als wenn man eine Verschlüsselung wählt, die z.B. 64 Stellen besitzt.
Wie mache ich meine Passwörter also sicher?
Da man bei der Webentwicklung auf bestehende Funktionen der Verschlüsselungsmethoden zurückgreift, da diese meist sehr kompliziert umzusetzen sind, kann man dennoch beherzt auf alte Funktionen wie MD5 und SHA1 zurückgreifen. Es gibt zwei Methoden, trotz der Unsicherheit dieser Verschlüsselungen, diese dennoch sicher zu machen. Diese nennen sich "Salt" oder "Pepper"
Beim "salten" ergänzt man das zu verschlüsselnde Passwort um eine vorher definierte, zufällige Zeichenfolge mit mehreren Zeichen. Dadurch erschwert man es dem Angreifer, einen Wörterbuchangriff durchzuführen, da das Passwort mit dem Salt nicht unbedingt im verwendeten Wörterbuch vorhanden ist. Dabei reicht eine Zeichenfolge von "ab" als Salt nicht unbedingt aus.
Was haben wir also bisher erreicht? Wir haben unsere Passwörter, welche bisher nur unzureichend gesichert waren und mit absehbaren Umfang entschlüsselt/"gecrackt" werden konnten, mithilfe von einem "Salt" abgesichert. Wir wissen nun, dass es durchaus Unterschiede zwischen den Hash-Längen geben kann und das durch die begrenzte Anzahl an Zeichen eines Hashs Kollisionen entstehen können.
Das erwartet euch im nächsten Teil:
Verschlüsselung und Entschlüsselung - Daten sichern und dennoch brauchbar wiederverwenden. Manche Daten, wie z.B. sensible Kundendaten, müssen zureichend gesichert werden, da diese nicht einem Angreifer in die Hände fallen dürfen. Da das Einwegverschlüsseln kein geeigneter Weg ist, um diese Daten zu sichern, müssen andere Mittel und Wege her.
