# Blatt 9

## Aufgabe 2

Ein Rainbowtable/Wörterbuch- Angriff beinhaltet eine Tabelle, in der alle möglichen Passwortkombinationen mit zugehörigem hash gespeichert sind. Hat ein Angreifer nun Zugang zum hash kann er in seiner Tabelle den zugehörigen Klartext string nachschauen und hat dadurch das Passwort. (Weiterführung siehe unten. m.M.n unklar definiert) Bei simplen Brute Force angriffen wird durch vie ausporbierne versucht, das richtige Passwort zu erraten. Hat man zum Beispiel eine verschlüsselte Datei kann man alle Passwortkombinationen ausprobieren und testen, ob man die Datei zufällig entschlüsseln konnte.

Die Rainbowtable ist die Tabelle, welche den Hash und den Klartext beinhaltet. Abgebildet wird als OWF(w) -> w und OWF ist eine Einwegfunktion.

Hier ist m.M.n etwas unklar:
Laut unserer Folie ist ein Wörterbuchangriff folgendes:

Dies ist mir aber eher als Rainbowtable Angriff bekannt. Ein Wörtberuchangriff ist eigentlich, laut Wikipedia (https://de.wikipedia.org/wiki/W%C3%B6rterbuchangriff) ein Brute Force welcher mit einer Wörterliste durchgeführt wird. Man geht davon aus, dass nur sinnvolle Zeichenketten verwendet werden. Was wahrscheinlich auch oft der Fall ist. Laut unserer Folie ist jedoch ein Wörterbuchangriff ein Angriff, bei welchem der Hash auf ein Passwort abgebildet wird. Dies ist allerdings eigentlich ein Rainbowtableangriff.

Eine effektive Gegenmaßnahme sind Salts. Da diese die Rainbowtables vergrößern. Da jeder Klartext hash für jeden salt generiert werden muss. Fügt man ein Salt der Größe ein Byte hinzu, dann muss man für ein einzigen Klartext 256 Hashes generieren. Dadurch vergrößert sich die Rainbowtable und der Angriff wird langsamer bis hin zu nicht durchführbar (Speicherkapazität als begrenzender Faktor).

## Aufgabe 3

Die druckbaren Zeichen sind im Bereich 32 - 126 (inkl. 32 & 126). Das heißt, dass es 95 druckbare Zeichen gibt.

Quelle: http://facweb.cs.depaul.edu/sjost/it212/documents/ascii-pr.htm
Quelle 2: https://en.wikipedia.org/wiki/ASCII

$$
f(l) = b^{l} = 95^{l}
$$

| l | f(l) | Zeit zum knacken | Speicherplatz Rainbowtable |
| -------- | -------- | -------- | -------- |
| 1 | 95 | < 1 Sekunde | 6175 byte |
| 2 | 9.02e3 | <1 Sekunde | 595 kb |
| 3 | 8.57e5 | <1 Sekunde| 57,4 Mb |
| 4 | 8.14e7 | <1 Sekunde| 5,5 Gb |
| 5 | 7.73e9 | <2 Sekunden| 533 Gb |
| 6 | 7.35e11 | 183.75 Sekunden | 51 Tb |
| 7 | 6.98e13 | 17450 Sekunden = 4,8 Stunden | 4,9 Pb |
| 8 | 6.63e15 | ca. 460 Stunden | 477 Pb |
| 9 | 6.30e17 | ca. 1823 Tage | 46 Eb |
| 10 | 5.98e19 | ca. 474 Jahre| Nicht gefordert |

Größe Sha 512 Hash: 512 bits = 64 byte

Formel zum berechnen des Speicherbedarf s(l)
$$
s(l) = f(l) * (l + 64)
$$

=> Man hat f(l) mal ein Passwort welches die größe l hat, da ein Zeichen ein byte groß ist. Dazu kommt pro Passwort ein SHA hash welcher immer 64 byte groß ist.

Der Salt muss lang genug sein, um ausreichend Permutationen hinzuzufügen. Ein Salt aus einem byte zum Beispiel würde nicht wirklich Sinn ergeben, da dadurch die anzahl der zu generierenden Hashes für einen Wörterbuchangriff nur mit dem Faktor 256 erhöht werden wprde (Da man ja für jeden salt wert alle hashes neu berechnen muss). Daher muss der Salt eine relevante Größe haben. Unserer Meinung sollte de Salt mindestens 6 byte groß sein. Das basiert aber eher auf einem Gefühl, als auf den Zahlenwerten. Ein Salt ist ja nicht nur auf druckbare asci zeichen begrenzt. Mittels base64 lassen sich alle Bitfolgen auch als Zeichen speichern. Oder man speichert in der Datenbank gleich bits, wodurch man die hashes allerdings nicht ausgeben könnte.

Aus den Ergenissen von oben lässt sich schließen, dass SHA-512 nicht als Passwort Hashing Algorithmus taugt, da dieser zu schnell ist. Da hilft auch ein Salt ehrlicherweise nicht wirklich viel. Denn selbst mit einem 10 Zeichen langen Hash (noch ohne Salt) kann man das mit mehreren Grafikkarten relativ schnell knacken. Ein insitutioneller Angreifer kann daher auch das relativ schnell knacken. Unserer meinung nach müsste der Salt selbst schon mindestens 2 byte groß sein, damit man eine relative Sicherheit erlangt.

Ein Hashing Algorithmus der langsamer ist wäre sinnvoller.

Annahme: Ein Passwort ist dann sicher, wenn man mehr als ein Leben braucht, um das Passwort erraten zu können. Ein gut zu rechnender Mittelwert für das Alter ist 80, da Männer im Schnitt 78,3 Jahre alt werden und Frauen 83,2 Jahre.

Quelle: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwionfeNmIODAxUJRPEDHTwoAYMQFnoECA0QAw&url=https%3A%2F%2Fwww.destatis.de%2FDE%2FThemen%2FGesellschaft-Umwelt%2FBevoelkerung%2FSterbefaelle-Lebenserwartung%2F_inhalt.html&usg=AOvVaw2JtkO47-wmj2oA_1u2fuyE&opi=89978449

80 jahre = 29200 Tage = 700800 Stundenm = 42048000 Sekunden

Dadurch ergibt sich folgende Berechnung für die Anzahl der hashes die man in einem Leben generieren kann:

$$
42048000 * 10 ^{11} = 4.2 * 10 ^{18}
$$

Aus der Tabelle von oben ergibt sich daher, dass ein Passwort mindestens 10 Zeichen lang sein sollte, damit man einen ausreichend großen Puffer hat, und es daher unwahrscheinlich ist, dass ein Angreifer diesen berechnen kann.

Die Berechnung mit 80 Jahren mag etwas hoch erscheinen. Allerdings muss davon ausgegangen werden, dass in der Zukunft es immer schneller möglich ist solche hashes zu berechnen. Außerdem erlauben sinkende Hardwarepreise, dass sich ein Angreifer seinen Angriff horizontal skalieren kann. Daher ist um auch in Zukunft sicher zu sein, ein Zeitraum von 80 Jahren durchaus legitim.