Sponsor-Board.de
Antwort schreiben  Thema schreiben 

Einwegverschlüsselung - Absicherung des Datenverkehrs in Webapplikationen

Verfasser Nachricht

Beiträge: 1.306
Bewertung: 6
Registriert seit: May 2009
Status: offline


Beitrag: #1
Einwegverschlüsselung - Absicherung des Datenverkehrs in Webapplikationen

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.

09.01.2016 09:45
 
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren

Beiträge: 6
Registriert seit: Nov 2015
Status: offline


Beitrag: #2
RE: Einwegverschlüsselung - Absicherung des Datenverkehrs in Webapplikationen

Wenn dann bitte richtig mit password_hash() und password_verify() oder einer sichereren Hash-Funktion (wieso nicht direkt SHA-512 verwenden?), Salt und Iterationen.

Dieser Beitrag wurde zuletzt bearbeitet: 09.01.2016 16:14 von McHeinrich.

09.01.2016 16:14
 
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren

Beiträge: 1.306
Bewertung: 6
Registriert seit: May 2009
Status: offline


Beitrag: #3
RE: Einwegverschlüsselung - Absicherung des Datenverkehrs in Webapplikationen

Hallo McHeinreich,

wie du vllt gemerkt haben solltest, ist dieser Thread allgemein gehalten.
Ich beziehe mich hier in keinster Weise auf eine Programmiersprache, vor allem nicht in einem unspezifischen Bereich wie z.B. der Kryptographie.

Das Thema stellt dementsprechend die Handhabung mit der Kryptographie dar, keine genaue Anleitung, wie man was macht.

Warum also nicht so eine Klasse [Link: Registrierung erforderlich] warum nicht openssl-Funktionen [Link: Registrierung erforderlich] ? Richtig, das eine ist Javascript, das andere PHP.

Warum benutze ich kein password_hash() ? Vielleicht rede ich hier von einer für dich völlig unbekannte Sprache, vielleicht habe ich einen eigenen Parser geschrieben Wink

Es geht einfach darum, das Wissen um das "Was" zu übermitteln, nicht das "wie", das bleibt demjenigen, der das Wissen umsetzen möchte, in seiner Sprache vollkommen freigestellt. Die Funktionsfülle, die man verwenden kann, weicht z.B. zwischen JavaEE und PHP wieder stark ab, die Problematik der unverschlüsselten Daten bleibt dennoch die gleiche.

09.01.2016 17:55
 
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren

Beiträge: 844
Bewertung: 0
Registriert seit: Jun 2011
Status: offline


Beitrag: #4
RE: Einwegverschlüsselung - Absicherung des Datenverkehrs in Webapplikationen

Schöner Artikel.

Aber man tut nicht nur "salzen/pfeffern" gegen mögliche Angriffe sondern auch um Rainbow-Tables zu erschweren.
Ausserdem nutzt auch die beste Verschlüsselung nichts, wenn der Plaintext (also das zu verschlüsselnde) nichts taugt.
Passwörter z. B. sollten mind. 10 Zeichen lang sein, nicht auf gültigen Begriffen basieren und komplex sein (d. h. mind. 3
der Kategorien: * Großbuchstaben, * Kleinbuchstaben, * Ziffern und * Sonderzeichen).

Danke.


Alcazar
(nach Diktat spazierengegangen)

Dieser Beitrag wurde zuletzt bearbeitet: 11.01.2016 09:49 von alcazar.

11.01.2016 09:49
 
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren

Beiträge: 1.306
Bewertung: 6
Registriert seit: May 2009
Status: offline


Beitrag: #5
RE: Einwegverschlüsselung - Absicherung des Datenverkehrs in Webapplikationen

Andererseits muss man aber auch sagen, dass das "pfeffern" ja das Passwort auch verlängert um eine bestimmte Zeichenkette. Wenn dem Angreifer diese nicht bekannt ist, können auch Passwörter wie "Test" schwer knackbar sein oder missinterpretiere ich da gerade etwas? Wink

11.01.2016 10:13
 
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren

Beiträge: 844
Bewertung: 0
Registriert seit: Jun 2011
Status: offline


Beitrag: #6
RE: Einwegverschlüsselung - Absicherung des Datenverkehrs in Webapplikationen

Pepper ist eigentlich eine Art generierter Key der angehangen wird und für alle Passwörter auf diesem System gleich ist.
Salt ist für jeden unterschiedlich.

Dennis schrieb:
Wenn dem Angreifer diese nicht bekannt ist

Normal speichert man den Pepper auf einem anderem System als die Hashes, sonst bringts nix.


Alcazar
(nach Diktat spazierengegangen)

11.01.2016 13:51
 
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
Antwort schreiben  Thema schreiben 

Möglicherweise verwandte Themen...
Thema: Verfasser Antworten: Ansichten: Letzter Beitrag
  Zweiweg-Verschlüsselung - Absicherung des Datenverkehrs in Webapplikationen Dennis 0 1.542 12.01.2016 15:56
Letzter Beitrag: Dennis

 Druckversion anzeigen
 Thema einem Freund senden
 Thema abonnieren
 Thema zu den Favoriten hinzufügen

Sponsor-Board.de

Community
Über uns
Partner
Powered by Mybb: Copyright 2002-2024 by MyBB Group - Deutsche-Übersetzung von Mybb.de
 
© 2007-2024 Sponsor-Board.de - Hosted by OVH

Willkommen auf SB!   Sie benötigen ein Sponsoring?   1. Anmelden   2. Sponsoring-Anfrage erstellen   3. Nachrichten von Sponsoren erhalten   Kostenlos!   Jetzt registrieren