Sicher, es ist richtig, dass einem Kollisionen bei langen Passwörtern einen Strich durch die Rechnung machen können, aber du musst bedenken:

a) um die Kollisionen eines Hashing-Algorithmus’ voll auszunutzen, müsstest du eine Rainbow-Table erstellen, die für jeden möglichen Hash zumindest einen möglichen Klartext liefert. Das ist absolut unwirtschaftlich.
Ein MD5-Hash ist 128bit lang. Das heißt, du hast einen String bestehend aus 32 Hexadezimalzahlen. Rein rechnerisch müsstest du also eine Datenbank anlegen, die zumindest theoretische 340282366920938463463374607431768211456 Einträge umfasst (frage mich nicht, wie man diese Zahl ausspricht). Als Rainbow-Table bekommst du das wesentlich kompakter hin, aber die Größe ist dennoch immens. Bei SHA1 wächst die Anzahl bereits auf 1461501637330902918203684832716283019655932542976 und von SHA256 will ich gar nicht erst reden (nagut, doch, weil es so schön aussieht: 115792089237316195423570985008687907853269984665640564039457584007913129639936 und SHA512… auch lassen wir das…).

b) irgendwann fällt dir bei der Berechnung der Rainbow-Table deine eigene Reduktionsfunktion auf die Füße, denn auch die produziert selbstverständlich Kollisionen.

c) Kollisionen müssen nicht zwangsläufig auftreten. Es ist durchaus möglich, dass für Klartext-Phrase “foo” schlicht keine Kollision mit vertretbarem Aufwand zu finden ist. Insbesondere wenn der Hashwert länger ist als das Kennwort (was bei starken Algorithmen meist der Fall ist), wirst du mit Kollisionen nicht unbedingt weit kommen.

d) Kryptographische Funktionen wurden extra dazu designt, kollisionsresistent zu sein. Das heißt, dass dies explizit eine Anforderung an eine solche Funktion ist. Aus diesem Grund ist es nicht einfach möglich, einen Algorithmus zu schreiben, der zu x = hash(y) die Unbekannte x berechnet. Auch bei MD5 nicht. Hier bleibt dir also nur Bruteforce oder eine unglaublich große Rainbow-Table.

Bei schwachen Hash-Algorithmen (wie eben LM-Hashes) bekommst du also schnell eine Rainbow-Table zusammen, die 99% aller möglichen Kombinationen abdeckt, die notwendig sind, um Kennwörter sicher zu knacken. Bei stärkeren Algorithmen gelingt das nicht so einfach.

Wenn möglich, sollten aber stärkere Algorithmen wie SHA1 (wobei sich hier auch erste Schwächen abzeichnen) oder SHA2 (d.h. SHA256, SHA512 etc.) verwendet werden.

Nochmals: Ich sage nicht, das lange Passwörter nicht sicher wären (im Gegenteil). Aber gegen Rainbow-Tabellen helfen sie nur bedingt. Viel einfacher und besser ist ein (mehrfaches) Salting.

Der Hersteller von 1Password (AgileBits) bietet auf seinem Blog immer wieder nette Artikel, die die Passwort-Thematik gut beschreibt.
http://blog.agilebits.com/2011/06/21/toward-better-master-passwords/
http://blog.agilebits.com/2012/06/06/a-salt-free-diet-is-bad-for-your-security/
http://blog.agilebits.com/2012/06/07/flames-and-collisions/
und der schöne Antwort auf den vllt bekannten XKCD-Comic: http://blog.agilebits.com/2011/08/10/better-master-passwords-the-geek-edition/

Siehe auch: http://en.wikipedia.org/wiki/Rainbow_table

Allerdings ist es beim Hashing überhaupt nicht erforderlich = gar nicht möglich, das originale Passwort zu besitzen/nutzen. Ich brauche als Angreifer nur ein passendes Passwort zum Hash. Wie bei einer mathematischen Funktion gibt es für den Wert y (Hash) mehrere verschiedene mögliche Werte für x. Dem Angreifer reicht einer. Jedes x kann eine andere Länge sein, es könnte theoretisch nur aus einem Zeichen bestehen.

Ähm, in kurz: Nein.

Ich weiß nicht, wieso euer Gespräch überhaupt in diese Richtung verlaufen *g* ist, aber mittlerweile ist es sogar besser, wenn man seinen gesamten Service mit HTTPS kapselt (die sozialen Netzwerke machen das, Google selber mehr und mehr, GitHub auch). Der Grund ist u.a., dass man ohne SSL ganz einfach die Session (über das Session Cookie) kommt. Das war der technische Hintergrund, dass überhaupt Firesheep funktionieren konnte. Es wäre fatal, auf SSL zu verzichten, weil es überhaupt nichts bringen würde. Die Tragweite, den Netzverkehr unverschlüsselt zu übertragen, muss einem schließlich in jeder Position der Anwendung klar sein. Selbst bei einer simplen Aufgabenverwaltung kann ein Datenleck oder Account-Hijacking nicht erwünscht sein (wahrscheinlich eher die Standardvorgabe).

Tatsächlich kann man sogar soweit gehen, und alle statischen aber Code ausführenden Artefakte Ressourcen mit SSL sichern, damit erhöht man den Integritätsfaktor der eigenen Webanwendung (Server wird mehr und mehr integer, aber Browser ist natürlich weiterhin kompromitierbar).

Dass natürlich eine PKI wie bei den SSL-Zertifikaten nicht 100% sicher sein kann, ist ein anderes Thema. Aber die beiden Alternativen sind nicht besser: das Web Of Trust (WOT) wie bei PGP ist nur bedingt brauchbar und gar nichts zu tun ist einfach inakzeptabel.

Ich finde Euren Podcast weiterhin spitze, aber das musste jetzt mal beigesteuert werden. :)

Man nimmt sich ein Klartextkennwort und schickt das durch die Hash-Funktion. Diesen generierten Hash schickt man durch eine Reduktionsfunktion, die aus dem Hash einen beliebigen weiteren Klartext erzeugt (z.B. indem es die ersten x Zeichen das Hash-Werts nutzt). Dieser neue Klartext wird dann wieder gehasht usw. Nach einer bestimmten Anzahl an Iterationen hört man auf und speichert den letzten Hash zusammen mit dem Klartext, mit dem man begonnen hat. Dann fängt man mit der nächsten (Chain) an, mit der man auf dieselbe Art verfährt.
So hat man hinterher eine umfangreiche Liste von Anfangs-Klartext-Kennwörtern und End-Hash-Werten. Alle Zwischenschritte werden nicht gespeichert.

Will man nun einen Hash knacken, guckt man in der Spalte mit den Hash-Werten, ob dieser dort vorhanden ist. Wenn nicht, wird der Hash durch die Reduktionsfunktion geschickt und wieder gehasht. Dann wird wieder geprüft usw. usf. Hat man irgendwann einen Treffer, muss man nur noch den gespeicherten Anfangs-Klartext der jeweiligen Chain entsprechend oft durch die Hash- und Reduktionsfunktion laufen lassen, bis man den Klartext zum Hash hat.

Ist ein Hash jedoch gesalzen, dann klappt das nicht mehr so gut. Der Angreifer müsste jetzt für jeden Hash eine neue Rainbow-Table errechnen, da dasselbe Kennwort plötzlich unterschiedliche Hashes produziert.
Den Aufwand kann sich der Angreifer auch sparen und gleich per Bruteforce stumpf alle Kombinationen durchprobieren.

Weitere Möglichkeiten, um Rainbow-Tables ineffektiv zu machen, sind stärkere Hashing-Algorithmen, Key-Strengthening durch wiederholtes Hashing und natürlich längere Passphrasen, da mit ihnen auch die Größe der Tabelle steigt.

1. md5 ist keine Verschlüsselung, sondern ein Hashing-Algorithmus. Eine Eingabe wird dabei in einen möglichst einzigartigen (und stets gleichen) Hash überführt. Eine Prüfung gleicher Hashes legt gleiche Eingabestrings nahe. Gleiche Hashes verschiedener Eingaben nennt man Kollision.
2. Eine Rainbow Table „knackt“ nicht „irgendwie“ die Eingabe, sondern erzeught und listet Hashes typischer Eingabestrings (Trivialpasswörter etc.) und erlaubt so die Rückführung gefundener Hashes auf ein Passwort.
3. Salting hat die Aufgabe (auch Trivial-)Eingabestring so zu verlängern und durch Salts mit vielen Sonderzeichen die Entropie des Passworts zu erhöhen, so dass keine passende Rainbow-Table gefunden werden kann.
4. Natürlich kann für einen bekannten Salt eine eigenständige Rainbowtable für das Salting-Verfahren erstellt werden. Um diesen Prozess zu erschweren (die Erstellungszeit/den Aufwand für Angreifer zu erhöhen), können mehrstufige Hashing-Runden und vom jeweiligen User-Kontext abhängige dynamische Salts verwendet werden. Ist hier der Username involviert, macht es selbstredend wieder Sinn, die verfügbaren Usernamen nicht zu veröffentlichen. So erhöht sich selbt bei bekanntem Hashing-Verfahjren wiederum der Aufwand.

> selber salten ist relativ blödsinn

Hier ging es nicht um „selber salten“, sondern darum ein möglichst langes und doch merkbares Passwort zu bekommen. Ist darauf die Bildungsvorschrift für das Passwort ersichtlich, ist das natürlich problematisch, wenn das Passwort im Klartext vorliegt. Eine Strategie könnte sein, den Dienst erst mit einem anderen Passwort zu testen (bspw. auch mal die Passwort-Recovery anzustoßen) und erst später auf ein merkbares PW umzusteigen, wenn man dem Dienst hinreichend vertraut.

Was XOXOCO anbelangt: Ist ne ziemliche Müll-Idee.
1. E-Mail-Speicher sind kein zuverlässiger Passwort-Safe.
- Wie werden Daten gespeichert?
- Daten werden bspw. für Spam-Algorithmen vom Dienstanbieter verarbeitet
- Ist dem Dienstanbieter zu vertrauen
- Wie ist es um die Sicherheit von Client-Software bestellt?
2. E-Mail-Dienste können nicht erreichbar sein
3. E-Mail-Dienste können eingestellt werden
- Anbieter wird von anderem Unternehmen aufgekauft (Vertrauen)
- Anbieter geht pleite
- Anbieter ändert seine AGB
- Anbieter sperrt den Account (Google ist da ganz groß drin)
3a. Wenn es keine andere Auth-Methode gibt, wie kann ich nach XOXOCO die E-Mail-Angabe ändern? Es macht wohl kaum Sinn, hier die E-Mail-Adresse als Merkmal zu verwenden, wenn mein Account gehackt wurde oder der Mail-Service nicht mehr erreichbar ist.
4. Datenaufkommen
- eine E-Mail pro Anmeldung?
- Spam
- E-Mail ist so schon schwer genug zu verwalten
5. Nutzungskontext
- Aus einem Kontext (Browser) werden zwei (Browser, E-Mail-Client). Das Auth-Verfahren wird aufwendiger, wenn man nicht stets seinen E-Mail-Client laufen hat.
6. Verbindungssicherheit
- Klartext-Passwort wird ständig durch die Welt geschickt
7. usw.