Quantcast
Channel: Kommentare zu: Revision 82: Wiederverwertbarkeit von CSS & Web Security
Viewing all articles
Browse latest Browse all 20

Von: nk

$
0
0

Besonders gut wurde das Thema md5 ohnehin nicht beschrieben.

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.


Viewing all articles
Browse latest Browse all 20