[TYPO3-german] Wie sicher ist Typo3

David Bruchmann david at bruchmann-web.de
Tue Dec 23 15:25:53 CET 2008


Hallo Malte,

Bezüglich Verschlüsselung gibt's große Unterschiede - soweit waren wir
eigentlich schon:

1) Der Logarithmus muss einen Salt-Wert enthalten. Also einen zufälligen
Code, der das Nachschlagen des Passworts in einer Rainbow-Tabelle verhindert
oder erschwert.

2) Der Salt-Wert könnte auf einem anderen Server gespeichert werden,
allerdings nützt auch das nichts, wenn die Zugangsdaten zum entfernten
Server auf dem Hauptserver gespeichert werden. Somit kann der Saltwert
eigentlich gemeinsam mit dem Passwort in einer Tabelle gespeichert werden.
Personen mit Vollzugriff können das Passwort eigentlich immer irgendwie
entschlüsseln oder umgehen. Für Daten, die nur Userspezifisch übertragen
werden, kann der Salt-Wert beim Client gespeichert werden. Somit ist die
Rekonstruktion auf dem Server mangels Salt-Wert nicht möglich, außer der
Client wird bei Verbindung "abgehört".

3) Sofern die Passwörter verschlüsselt übertragen werden ist die eigentliche
Länge erst mal egal. Für kurze Passwörter ist die Wahrscheinlichkeit einfach
höher dass jemand sie errät oder dass das Passwort bei Rekonstruktion durch
eine Rainbow-Tabelle früher gefunden wird. Der Verschlüsselte und
übertragene Wert ist aber bei vielen Logarithmen gleich lang, egal wie lang
das Passwort ist.

4) Der Logarithmus ist umso sicherer je seltener er ist oder je häufiger er
individuell wechselt. Würde jeder Server einen anderen Logarithmus
verwenden, würden Rainbow-Tabellen nur jeweils für einen Server gelten.
Interessanter und realistischer ist aber die Möglichkeit einfach
verschiedene Logarithmen zu wechseln oder/und zu kombinieren. Darüber hinaus
kann man den jeweils angewendeten Logarithmus versteckt speichern, z.B. als
Bestandteil des Salt-Wertes.

5) Das (alternative oder zusätzliche) häufige Wechseln von Passwörtern
erschwert das Erraten und begrenzt zumindest zeitlich die
Schadensmöglichkeit.

6) Alle Verschlüsselung nützt gar nichts, wenn Passwörter geklaut werden
können und Datenmissbrauch erlauben.

An die Option mit der Direktverbindung per Modem hatte ich auch gedacht,
früher war das häufig anzutreffen (BBS, wenn ich mich richtig erinnere). Im
Hinblick auf Breitbandverbindungen wüsste ich momentan nicht, wie man mit
DSL-Modem eine solche Einwahl realisieren könnte um auch große Datenmengen
schnell zu übertragen. Ich denke, da bräuchte man spezielle Hardware.

Gruß
David


-----Ursprüngliche Nachricht-----
Von: typo3-german-bounces at lists.netfielders.de
[mailto:typo3-german-bounces at lists.netfielders.de] Im Auftrag von Malte
Jansen
Gesendet: Dienstag, 23. Dezember 2008 14:20
An: typo3-german at lists.netfielders.de
Betreff: Re: [TYPO3-german] Wie sicher ist Typo3

Hi,
wenn die Daten so sensible (ala Militärgeheimnis) sind, sollten die 
Daten nicht via Internet übertragen werden, sondern mit ner direkten 
Leitung direkt zum Client. ;)

Deine ganzen Sicherheitsmaßnahmen helfen nichts, wenn die Passwörter 
etc. unverschlüsselt auf den Server übertragen werden.

Das einfachste ist das ganze mit SSL zuverschlüssel. Natürlich müssen 
Passwörter dann noch sicher sein, was man aber ganz simple mit ein paar 
einfachen Regeln beim Passwort erstellen überprüfen kann:
- Länge Passwort > 8
- mind. 1 Sonderzeichen
- mind. 1 großer und kleier Buchstabe
- keine Geburtsdaten oder Zahlen Kombination länger als 2
-...

Gruß

Malte

Markus Deckmann schrieb:
> Hi Christian,
> 
>> für die security meldungen von typo3 gibts einen Security newsfeed
>> http://news.typo3.org/xml-feeds/
> 
> Werde ich mir morgen gleich mal anschauen...danke für den Link.
> 
> 
>> dort bekommst du infos über alle entdeckten sicherheits lücken. und 
>> was sie genau betreffen.
>> und dann liegt es natürlich an dir schnellst möglich zu patchen.
> 
> Das ist klar. :-D
> 
> 
>> wenn der server mit den "verschlüsselten" daten auch arbeiten soll. 
>> also mehr als sie nur verschlüsselt an den enduser zu schicken. der 
>> server den schlüssel zu den daten. diesen must du dann wohl auf
>> dem server speichern. damit hätte ein angreifer in deinem angriffs 
>> szenario auch wieder
>> den schlüssel. da du ja davon ausgehst das er auf irgend eine weise 
>> vollzugriff hat.
> 
> Grundsätzlich bin ich schon davon ausgegangen das der Server auch die 
> Daten darstellt, allerdings würde auf dem Server (wenn man mal von PGP 
> ausgeht) lediglich der öffentliche Schlüssel liegen. Den privaten 
> Schlüssel müsste der User für die Ansicht manuell pro Sitzung eingeben 
> und damit würde entschlüsselt werden. Allerdings leuchtet mir hier ein 
> das ich hier den privaten Schlüssel tunlichst nicht zurück an den Server 
> schicken sollte, denn damit würde dem Angreifer ja dann privater und 
> öffentlicher Schlüssel und damit das komplette Schlüsselpaar zur 
> Verfügung stehen. Hier muss ich mir nochmal genauer Gedanken machen.
> 
> 
>> in dem ich die index.php datei ungefähr so modifizre:
>> output buffering aktivieren. den normalen "kram tun" am ende den 
>> buffer auslesen. und und an mich übermitteln / in einen log schreiben. 
>> und dann dem user den normalen output päsentieren.
> 
> Das funktioniert aber ja nur wenn die Entschlüsselung auf dem Server 
> passiert und das komplette Schlüsselpaar vorhanden ist. Nur der 
> öffentliche Schlüssel nützt dem Angreifer nichts. Wie oben erwähnt muss 
> ich mir allerdings hier dann wohl noch überlegen wie ich den privaten 
> Schlüssel nutze ohne ihn an den Server zu schicken und ohne die Gefahr 
> zu haben ein komprimitiertes Client-System zu haben.
> 
> 
>> aber ich kanns mir natürlich auch einfach machen und das passwort des 
>> users mitschreiben wenn es den "infizierten"
>> server erreicht. damit kann ich die rolle jedes users einnehmen nach 
>> dem er sich einmal eingelogged hat.
>> und könnte so auch daten auslesen die mit dem passwort des users 
>> verschlüsselt worden sind.
> 
> Davor kann ich mich also nur schützen wenn die Ver- und Entschlüsselung 
> auf einem sauberen Client-System abläuft, sehe ich das richtig? Nur dann 
> ist dem Angreifer lediglich der öffentliche Schlüssel bekannt, was ihm 
> alleine allerdings für eine Entschlüsselung nichts bringen dürfte.
> 
> 
>> du kannst dich nicht effektiv gegen einen angreifer schützen der 
>> vollzugriff auf dein system hat.
>> ich glaube bei vollzugriff auf dein system ist deine sicherheit in 
>> jedem erdeknlichn fall dahin.
>> also geht es darum einen user nicht dahin kommen zu lassen.
> 
> In meinen Augen kann dies allerdings dennoch auftreten und muss dabei 
> noch nicht mal in meiner Macht liegen. Eine falsche Einstellung die vom 
> ISP gesetzt wird und schon hat jemand evtl. mal kurz Zugriff. Sich nur 
> auf Server-Schutz zu verlassen ist in meinen Augen also ein bisschen zu 
> wenig.
> 
> 
>> der einzige fall in dem du die "vertraulichen" daten auf ein system 
>> geben kannst das von deinem angreifer
>> kontrolliert wird. ist der fall in dem die daten schon verschlüsselt 
>> das system erreichen.
>> und auch nur verschlüsselt wieder herunter genommen werden.
> 
> Ja, das leuchtet mir jetzt auch ein...allerdings würde das eine Ver- und 
> Entschlüsselung beim Client voraussetzen bei dem ich dann auch in 
> irgendeiner Weise sicher stellen sollte das dort kein Trojaner oder 
> ähnliches die Eingaben abfängt. Wäre hier u.U. eine Live-CD eine 
> Möglichkeit mit der der Benutzer sich einloggt auf dem Portal? Damit 
> sollte doch weitgehens sicher gestellt sein das kein Schädling die 
> eingegebenen Daten abhört und damit in den Besitz der Passwörter 
> gelangt. Eine sichere Ver- und Entschlüsselung auf Client-Seite sollte 
> damit dann auch gegeben sein denke ich, oder vernachlässige ich hier 
> dann noch etwas?
> 
> 
>> quasie ein FTP server auf dem du nur mit PGP verschlüsselte daten hoch 
>> und runter lädst. damit hat dein server
>> kein sicherheits problem mehr. dafür must du nun gewährleisten das 
>> keiner der user rechner infiziert wird. (besonders
>> wenn die user in der lage sein sollen die daten unter einander zu 
>> lesen. könnte es spaßig werden falls ein privater schlüssel in die 
>> falschen hände gerät.
> 
> Komplexeres Thema als es auf den ersten Blick den Eindruck machte. Ich 
> werde mal den Gedanken der Live-CD weiter durchspielen, damit ist in 
> meinen Augen eine weitgehenst sichere Verbindung zwischen Client und 
> Server möglich mit zusätzlicher Verschlüsselung der Daten auf
Client-Seite.
> 
> Danke für deine Antworten bisher...deine Tipps haben mir doch noch 
> einige Schwachstellen in meinem Konzept aufgezeigt an die ich mich noch 
> ranmachen sollte bevor ich hier anfange etwas umzusetzen.
> 
> Ciao Markus
_______________________________________________
TYPO3-german mailing list
TYPO3-german at lists.netfielders.de
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-german



More information about the TYPO3-german mailing list