Archiv für die Kategorie "Webserver"

Passwörter im Internet sicher speichern

Mit Erschrecken stelle ich immer wieder fest, dass viele Internetseiten die Sicherheit von Benutzerkonten hinsichtlich der Passwörter vernachlässigen.

Der schlimmste Fall betrifft eine recht populäre Internetseite mit angekoppeltem Online-Shop, die die Passwörter sogar im Klartext zu hinterlegen scheint. Hat man das Passwort vergessen wird es nämlich im Klartext per E-Mail zugesendet, was ein enormes Sicherheitsrisiko bedeutet. Zum einen können die Datenbestände des Anbieters in falsche Hände gelangen, zum anderen birgt der unverschlüsselte Versand des Passwortes weitere Risiken (z.B.: Man-In-The-Middle Angriff). Man kann sich leicht vorstellen, wie viele Benutzer das dortige Passwort auch auf anderen Internetseiten verwenden und was das im Falle von Datendiebstahl bedeuten kann… Einen Hinweis sucht man auf der Internetseite ebenfalls vergebens.

Leider stoße ich sogar bei etwas besser abgesicherten Internetseiten häufig über sehr niedrige Begrenzungen der Passwortlänge. Aus welchem Grund darf ein Passwort nur 10 oder 20 Zeichen lang sein? Das Passwort wird ohnehin verschlüsselt und ist damit immer gleich lang (z.B.: 64 Bytes bei MD5). Einzig die möglichen Performance-Verluste seitens des Webservers fallen mir dabei als Grund ein. Daraufhin bastelte ich mir kurzerhand ein kleines PHP-Script um Benchmarks für unterschiedlich lange Zeichenketten aufzuzeichnen. Dabei werden die Hash-Verfahren MD4, MD5, SHA1, SHA256 und SHA512 jeweils mit einer 32, 64, 160 und 320 Bytes langen Zeichenkette berechnet. Um auf einigermaßen aussagekräftige Werte zu kommen, wird jede Berechnung 10.000 mal durchgeführt und der Mittelwert gebildet. Als Ergebnis der Untersuchungen kam ich zu der Erkenntnis, dass die Hash-Verfahren MD4 und MD5 die Zeichenkette in der kürzesten Zeit berechnen konnten. Die Länge der Zeichenkette wirkt sich dabei zwar auf die Dauer der Berechnung aus, aber nicht sehr stark: während sich die Länge verzehnfacht, benötigen die beiden Hash-Verfahren lediglich die rund 1,4-fache Zeit.
Etwas anders sieht es bei SHAx aus. Die Leistung von SHA1 ist noch ungefähr vergleichbar mit MD4/MD5. Die Berechnung mit SHA256 dauert aber schon etwas länger und bei der zehnfachen Länge der Zeichenkette wird auch schon die doppelte Zeit benötigt. Am längsten dauert die Berechnung mit SHA512, nämlich rund drei bis vier mal so lange im Vergleich zu MD4/MD5. Die Proportionen verhalten sich hier wie bei SHA256.

Ergebnisse: hashbenchmark.txt

Was bedeutet das nun? Obwohl sich die Zeiten teilweise deutlich unterscheiden, kann ich mir kaum vorstellen, dass ein Webserver durch längere Berechnungen deutlich an Performance verliert. Im übrigen bin ich der Meinung, dass auch diese Umstände bei der Auslegung der Hardware des Servers berücksichtigt werden sollten! Übrigens sind schnelle Hash-Verfahren nicht unbedingt die besten, denn auch Rainbow-Tables lassen sich damit schneller erstellen, wovon die Cracker profitieren.

Eine Begrenzung der Passwortlänge würde ich erst ab mindestens 50 Zeichen ansetzen und als Hash-Verfahren SHA256 oder SHA512 verwenden. Weiterhin ist die Verwendung von Salts, die vor, hinter oder/und in das Passwort eingefügt werden, zu empfehlen. Damit lassen sich die Passwörter künstlich in die Länge ziehen und sogar Wörter aus Wörterbüchern so verschlüsseln, dass Angriffe mit Rainbow-Tables erfolglos bleiben. Eine weitere sinnvolle Methode ist das mehrfache Berechnen eines Hashes. So wird die resultierende Zeichenkette nach dem Verschlüsseln des Passwörtes wiederum verschlüsselt. Dieser Vorgang kann beliebig oft wiederholt werden, was wiederum die Rückverfolgung über Rainbow-Tables erschwert.

Den abschließenden Appell auf jeder Internetseite ein anderes Passwort zu verwenden kann so manch einer vielleicht nicht mehr hören, möchte ich an dieser Stelle der Vollständigkeit halber erwähnen!

XAMPP unter Ubuntu

XAMPP ist eine beliebte Tool-Compilation um einen Webserver aufzusetzen.
Im Folgenden möchte ich die Installation und Konfiguration von XAMPP unter Ubuntu erläutern.

XAMPP kann als Archiv von der Apachefriends-Homepage heruntergeladen werden:
http://www.apachefriends.org/de/xampp-linux.html

Zunächst wird das Archiv nach /opt entpackt:

sudo tar xvfz xampp-linux-VERSION.tar.gz -C /opt

(VERSION durch jeweilige Bezeichnung ersetzen)
Es entsteht ein Verzeichnis /opt/lampp, worin sich XAMPP befindet.

Zur besseren Bedienung kann man sich zwei Verknüpfungen anlegen.
Die erste Verknüpfung startet das Control-Panel.

gksudo "python /opt/lampp/share/xampp-control-panel/xampp-control-panel.py"

Mit der zweiten Verknüpfung lässt man sich mit dem Dateibrowser (Nautilus) das Webverzeichnis öffnen:

nautilus /opt/lampp/htdocs

Damit in diesem Verzeichnis auch geschrieben werden kann, muss noch die Berechtigung angepasst werden:

sudo chmod -R 777 /opt/lampp/htdocs

Zuletzt noch die Sicherheitsroutine starten, wo diverse Passwörter eingestellt werden. Zuvor sollte XAMPP im Control Panel gestartet werden.

sudo /opt/lampp/lampp security

Im Browser kann man die Seite nun aufrufen: http://localhost

Fertig!

PS: LAMPP ist im übrigen die alte Bezeichnung. Das Paket wird neuerdings XAMPP genannt.

Kampf dem Hotlinking

Unter Hotlinking versteht man das Einbinden von Elementen, meistens Grafiken, von fremden Webseiten bzw. Servern. Der Hotlinker verweist also auf Dateien eines fremden Hosts und spart sich dadurch in erster Linie Traffic. Das kann natürlich gewünscht sein, denn mit diesem Prinzip arbeiten sogenannte Sharehoster (Imageshack & Co.).
Oftmals möchte man als Betreiber eines Servers aber genau dies vermeiden, da dadurch Performance und vor allem Traffic verbraucht wird.
Auch rechtlich gesehen ist Hotlinking eine heiße Sache. Ohne Genehmigung des Urhebers ist das Einbinden fremder Inhalte nicht gestattet.

Um das Hotlinking beim eigenen Webserver zu unterbinden, gibt es die Möglichkeit den Apache entsprechend zu konfigurieren: Hierbei werden alle externen Anfragen bestimmter Dateitypen (hier: gif, jpeg, jpg png, bmp, js und css) umgeleitet und ersatzweise eine Datei hotlinking.png angezeigt.

<IfModule mod_rewrite.c>
	<FilesMatch "\.(gif|jpe?g|png|bmp|js|css)$">
		RewriteEngine on
		RewriteCond %{HTTP_REFERER} !^$
		RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.tld [NC]
		RewriteCond %{REQUEST_FILENAME} !hotlinking.png$
		RewriteRule .*\.(gif|jpe?g|png|bmp|js|css)$ http://www.domain.tld/hotlinking.png [R]
	</FilesMatch>
</IfModule>

Das kostet zwar auch Performance und Traffic, aber bei geeignet kleiner Grafik (hotlinking.png) hält es sich deutlich in Grenzen. Das Interesse der Hotlinker verschwindet dann auch sehr schnell.

Das oben genannte Beispiel soll nur die Möglichkeiten aufzeigen. Sinnvoller wäre es beispielsweise, wenn ausschließlich Grafiken zu der Datei hotlinking.png umgeleitet werden und alle anderen blockierten Dateitypen ohne eine Reaktion unterdrückt werden.

Tipp zu Favicons im PNG-Format

Ein Favicon ist eine kleine Grafik, die in den Lesezeichen oder Tabs zu einer Internetseite angezeigt wird. Sie dienen dazu, die Internetseite hervorzuheben. Zumeist zeigen sie das Logo der dazugehörigen Internetseite.

Da diese Erfindung aus dem Hause Microsoft stammt, wurde dort mit dem ICO-Dateiformat ein eigener Standard entwickelt. Heutzutage können moderne Browser auch mit anderen Dateiformaten umgehen, dennoch werden .ico-Dateien bevorzugt.

Hier möchte ich auf die Vorteile von Favicons im PNG-Format hinweisen. Der wichtigste Punkt ist hierbei, dass man für PNG-Dateien keinen speziellen Converter oder aufwändige Grafiktools braucht. Des weiteren lassen sich sehr einfach transparente Logos erstellen, was mit dem üblichen ICO-Format deutlich komplizierter ist. Auch das W3C empfiehlt deren Sprössling (PNG).

Leider sind sich die Browser auch bei den Favicons nicht einig. Microsoft pocht mit dem Internet Explorer auf deren Standard und sträubt sich bei der Unterstützung anderer Formate.
Die anderen Browser (Mozilla Firefox, Opera und Google Chrome) sind da unempfindlicher und unterstützen Dateiformate wie ICO, PNG, GIF und JPEG.

Der Firefox hat aber das Problem, dass er zwar mit Favicons im PNG-Format umgehen kann, aber nicht selbstständig nach domain.tld/favicon.png sucht, was für das ICO-Format aber gemacht wird. Ein kleines Workaround schiebt dem Browser das korrekte Favicon zu:

RewriteEngine on
RewriteRule ^favicon\.ico$ /favicon.png [L]

Der Browser sucht nach der Datei favicon.ico, falls keine Angaben im HTML-Head (<link>-Element) gemacht wurden. Da wir aber eine PNG-Datei verwenden, wird mit Hilfe von mod_rewrite auf die PNG-Datei verlinkt. Die Angaben können natürlich auch in den Virtualhost-Settings der Apache-Konfiguration gemacht werden.