Hallo,

ich muss demnächst in Mathematik eine Präsentation zum Thema Kryptographie halten und würde hier gerne, meinerseits aufkommende Fragen klären.

Habe mich jetzt mal auf die Schnelle ein wenig in das Thema eingelesen und auch schon einmal die Caesar-Chiffre ausprogrammiert.

Jetzt ist es ja so, das diese Verschlüsselung mit einem Computer in Millisekunden geknackt werden kann und ich auch gerne noch etwas Komplexeres zeigen möchte.
Wie läuft das denn mit diesen "Salts" ab, die sind ja nichts anderes als eine zufällig generierte Erweiterung des verschlüsselten Textes, oder?
Wie kann denn dann z.B. eine Anwendung (Forum) beim Login eines Benutzers überprüfen ob das eingegebene Passwort dem, mit einem Salt versetzen Hash, entspricht? Dieser wurde ja zufällig generiert und kann jetzt nicht noch einmal generiert werden beim Login.

So, das wäre mal meine erste wichtige Frage die ich hätte!

Schönen Gruß,
Dude566

Also so wie ich das jetzt nach kurzem einlesen verstanden habe, wird in der Datenbank im Forum der zufällig generierte Salt mitgespeichert zu jedem Benutzer. Da die Tabelle ja eh mit Passwort und so weiter geschützt ist, kann ja auch niemand den Salt auslesen. Dann wird bei jeder Passwortabfrage einfach der Salt hinten drangehängt und davon dann erst der Hashwert gebildet. Diesen Vergleicht man dann mit dem in der Datenbank gespeicherten Hash.

Wenn du auch ein bisschen was "Advanced" zeigen möchtest, dann zeig doch die Vigenère Verschlüsselung her. Ist ein bisschen komplexer als die reine Cäsar-Verschlüsselung und kann auch nicht mehr so leicht anhand von Buchstabenhäufigkeiten und kurzen Wörtern entschlüsselt werden.

lg elundril

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

elundril hat folgendes geschrieben :

Also so wie ich das jetzt nach kurzem einlesen verstanden habe, wird in der Datenbank im Forum der zufällig generierte Salt mitgespeichert zu jedem Benutzer. Da die Tabelle ja eh mit Passwort und so weiter geschützt ist, kann ja auch niemand den Salt auslesen. Dann wird bei jeder Passwortabfrage einfach der Salt hinten drangehängt und davon dann erst der Hashwert gebildet. Diesen Vergleicht man dann mit dem in der Datenbank gespeicherten Hash.

Ja, wenn das so sein sollte finde ich das aber auch ziemlich unsicher, dann könnte ich ja wenn ich den Zugang zur Datenbank geknackt bekommen würde den normalen MD5 Hash mit Rainbowtables knacken und hätte ja eigentlich keine zusätzliche Sicherheit. Denn der Salt soll das ja erschweren.

Wenn ich mich anmelde wird ja zunächst ein MD5 Hash meines Passworts und Benutzernamens generiert und dann mit den Daten aus der Datenbank abgeglichen, da bringt mir es ja nix beim erneuten Anmelden das er noch einen Salt in der Tabelle hat. Hoffe das ist verständlich wie ich das meine.

elundril hat folgendes geschrieben :

Wenn du auch ein bisschen was "Advanced" zeigen möchtest, dann zeig doch die Vigenère Verschlüsselung her. Ist ein bisschen komplexer als die reine Cäsar-Verschlüsselung und kann auch nicht mehr so leicht anhand von Buchstabenhäufigkeiten und kurzen Wörtern entschlüsselt werden.

Danke, werde ich mir auch mal anschauen.

Dude566 hat folgendes geschrieben :

dann könnte ich ja wenn ich den Zugang zur Datenbank geknackt bekommen würde den normalen MD5 Hash mit Rainbowtables knacken

Was denkst du, in wie vielen Rainbow Tables !35§%1randomsalt3dfg4#admin123 aufgeführt ist ? Als früher nur ein einziger Salt für die gesamte Website benutzt wurde, konnte für große Datenbanken wenigstens eine Rainbow Table für diesen Salt quasi On-the-Fly generiert und durchgetestet werden, aber mit Per-User-Salts hat sich das auch gegessen.

Dude566 hat folgendes geschrieben :

Ja, wenn das so sein sollte finde ich das aber auch ziemlich unsicher, dann könnte ich ja wenn ich den Zugang zur Datenbank geknackt bekommen würde den normalen MD5 Hash mit Rainbowtables knacken und hätte ja eigentlich keine zusätzliche Sicherheit.

Eben das geht dann nicht. Du hast das falsch verstanden. Der Hash wird über das Passwort plus den Salt gebildet. Das heißt in deiner Rainbowtable müsstest du die Passwörter mit dem Hash drin stehen haben.

Und das wird wie Kha schon geschrieben hat, nicht möglich sein.

Okay, das klärt schonmal das es, wenn man Zugang zur Datenbank bekommt nicht mehr so sicher ist.

Aber was ist mit der Sache das beim Login ja auch geprüft werden muss, denn wenn ich den Salt in einem extra Feld der Tabelle mit meinen Usern nehmen würde hätte dies ja kein Sinn!

Denke mal der Salt wird dann damit gemischt, aber wie wird denn dann ein Salt der dazu passt beim Einloggen eines Benutzers generiert, dieser muss dann ja identisch zu dem hinterlegten sein, sonst könnte man ja nicht mit den Benutzerdaten in der Tabelle vergleichen.

Edit: @jaenicke: Aber es gibt ja auch Rainbowtables die auch Salted Hashs haben, gibt halt nur nicht so viele davon.

Dude566 hat folgendes geschrieben :

Denke mal der Salt wird dann damit gemischt, aber wie wird denn dann ein Salt der dazu passt beim Einloggen eines Benutzers generiert, dieser muss dann ja identisch zu dem hinterlegten sein, sonst könnte man ja nicht mit den Benutzerdaten in der Tabelle vergleichen.

Der Salt steht ja bei dem Benutzer in der Tabelle, den braucht das Skript ja nur auslesen. Dann generiert es aus dem eingegebenen Passwort und dem Salt den Hash und vergleicht den mit dem gespeicherten.

Dude566 hat folgendes geschrieben :

Edit: @jaenicke: Aber es gibt ja auch Rainbowtables die auch Salted Hashs haben, gibt halt nur nicht so viele davon.

Wie sollte das gehen? Das müssten ja riesige Listen sein, denn wie der Salt aussieht, weiß man ja vorher nicht.

jaenicke hat folgendes geschrieben :

Dude566 hat folgendes geschrieben : Denke mal der Salt wird dann damit gemischt, aber wie wird denn dann ein Salt der dazu passt beim Einloggen eines Benutzers generiert, dieser muss dann ja identisch zu dem hinterlegten sein, sonst könnte man ja nicht mit den Benutzerdaten in der Tabelle vergleichen. Der Salt steht ja bei dem Benutzer in der Tabelle, den braucht das Skript ja nur auslesen. Dann generiert es aus dem eingegebenen Passwort und dem Salt den Hash und vergleicht den mit dem gespeicherten.

Stimmt, das ich darauf nicht gekommen bin es so zu machen.

Dude566 hat folgendes geschrieben :

Okay, das klärt schonmal das es, wenn man Zugang zur Datenbank bekommt nicht mehr so sicher ist.

Um das noch klarzustellen: Salts haben nur bei einem Einbruch in die DB überhaupt einen Nutzen, also so ziemlich das Gegenteil von "nicht mehr so sicher" .

Kha hat folgendes geschrieben :

Dude566 hat folgendes geschrieben : Okay, das klärt schonmal das es, wenn man Zugang zur Datenbank bekommt nicht mehr so sicher ist. Um das noch klarzustellen: Salts haben nur bei einem Einbruch in die DB überhaupt einen Nutzen, also so ziemlich das Gegenteil von "nicht mehr so sicher" .

Ja ist mir jetzt klar geworden, dachte erst Hash und Salt würden in zwei verschiedene Felder abgelegt, funktioniert ja aber so wie jaenicke beschrieben hat, indem es vermischt wird.

Hab mir jetzt nicht alles durchgelesen, aber habe vor kurzem von nem Prof. die Unterlagen eines 2 tägigen Kryptografier vortrages erhalten.

Wennst mir deine Email gibst kann ich sie dir schicken, da is sicher vieles nützliches dabei

lg

Willst du es nicht vielleicht lieber direkt hier posten, dann hätten noch mehr Leute etwas davon die später mal auf diesen Thread stoßen.

Es sei denn, das darf nicht veröffentlicht werden oder so.

Dude566 hat folgendes geschrieben :

elundril hat folgendes geschrieben : Also so wie ich das jetzt nach kurzem einlesen verstanden habe, wird in der Datenbank im Forum der zufällig generierte Salt mitgespeichert zu jedem Benutzer. Da die Tabelle ja eh mit Passwort und so weiter geschützt ist, kann ja auch niemand den Salt auslesen. Dann wird bei jeder Passwortabfrage einfach der Salt hinten drangehängt und davon dann erst der Hashwert gebildet. Diesen Vergleicht man dann mit dem in der Datenbank gespeicherten Hash. Ja, wenn das so sein sollte finde ich das aber auch ziemlich unsicher, dann könnte ich ja wenn ich den Zugang zur Datenbank geknackt bekommen würde den normalen MD5 Hash mit Rainbowtables knacken und hätte ja eigentlich keine zusätzliche Sicherheit. Denn der Salt soll das ja erschweren.

Praktisches Beispiel:

Der Nutzername ist user, das Passwort ist foobar. Hash-Verfahren ist APR1 (eine MD5-Kaskade). Der Salt ist mNSgBsO6 und der eigentliche Hash, der gebildet wurde, ist 2T.qjERxIQDVS649Df1d7/

Wie wird der Hash nun Gebildet: VOR dem Passwort wird der Salt-Wert als Präfix und noch ein paar Trennzeichen ergänzt. Danach wird das (mehrfach, bei APR1 sind das etwa 100 Durchläufe; wer Source sehen möchte, kurz nachfragen, dann such ich das raus; hatte hier im DF dazu mal was gepostet). Danach wird $apr1$salt$ und der gebildete Hash als ein Ausgabestring kodiert und als Ergebnis geliefert.

Zum Validieren eines solchen Hashes wird nun der String analysiert. Das erste $ sagt: Hier kommt ein Hash-Format, das apr1 gibt das Verfahren und der Rest wird halt auch noch zerlegt. Danach wird das für den Login übergebene Passwort mit dem aus der Passwort-Tabelle gelesenen Hash gehasht. Das Ergebnis wird anschließend verglichen. Bei Gleichheit stimmt das Passwort (wahrscheinlich.

Der Benutzername geht i.d.R. nicht mit in den Passwort-Hash ein. Vielmehr: Wenn man so paranoid ist, gibt es neben dem Passwort-Salt noch einen Nutzer-Salt, aber in keinem Fall sollte der Nutzername direkt in den Passwort-Hash einfließen, da man ansonsten "Known Plaintext" hat Um das zu Umgehen muss beim Hashen von Daten, die einem Angreifer bekannt sein könnten, darauf geachtet werden, dass der Angreifer nicht einfach herausfinden kann, wo der bekannte Text auftaucht. Ein Beispiel für soetwas wäre z.B. wenn man einen User-Salt generiert, aus diesem die Byte-Summe bildet und dann aus dieser die Position ermittelt, wo im nächsten Durchlauf ein Byte des Nutzernamens in den Zwischenhash eingesetzt wird. Das solange wiederholen, bis kein Zeichen vom Nutzernamen mehr übrig und den dann entstandenen Hash mit beim Passwort-Hash mit in den Salt einfließen lassen. Solange ein Angreifer den Salt hier nicht kennt, kann auch der User-Salt-Teil nicht berechnet werden.

Eine Steigerung dessen macht übrigens ispCP: Dort wird ein Salt und ein IV (Initialization Vector) außerhalb der Datenbank gespeichert: Wenn man nicht weiß, wo das zu finden ist, ist die Datenbank und die darin enthaltenen Passwörter vollständig wertlos.

Dude566 hat folgendes geschrieben :

Wenn ich mich anmelde wird ja zunächst ein MD5 Hash meines Passworts und Benutzernamens generiert und dann mit den Daten aus der Datenbank abgeglichen, da bringt mir es ja nix beim erneuten Anmelden das er noch einen Salt in der Tabelle hat. Hoffe das ist verständlich wie ich das meine.

Jap. Aber wie gesagt, ist das Vorgehen ein etwas anderes Der Salt wird aus der Tabelle gelesen (steht meist sogar direkt im Passwort-Feld ) und dann wir mit dem Salt zusammen gehasht. Wenn dann der Wert aus der Datenbank wieder rauskommt, war's das richtige PW (oder eine sehr gute Kollission).

schwandi hat folgendes geschrieben :

Hab mir jetzt nicht alles durchgelesen, aber habe vor kurzem von nem Prof. die Unterlagen eines 2 tägigen Kryptografier vortrages erhalten.

Ich lege Dir das Buch mit der ISBN 978-3-411-04015-5 wärmstens ans Herz.

schwandi hat folgendes geschrieben :

Wennst mir deine Email gibst kann ich sie dir schicken, da is sicher vieles nützliches dabei

Bitte entweder öffentlich posten, damit auch andere etwas davon haben, oder sein lassen. Wenn Du das aus rechtlichen Gründen nicht posten darfst, wird das i.a.R. auch via PN verboten sein

Dude566 hat folgendes geschrieben :

Willst du es nicht vielleicht lieber direkt hier posten, dann hätten noch mehr Leute etwas davon die später mal auf diesen Thread stoßen.

Wäre ich dafür.

Dude566 hat folgendes geschrieben :

Es sei denn, das darf nicht veröffentlicht werden oder so.

Vermute ich mal stark.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Ich habe es nu am PC lokal, deswegen kann ichs nicht posten

Aber ich werds mal auf meinen Server laden und den Link hier posten

Super Erklärung BenBE, wenn ich weitere Fragen habe werde ich sie hier stellen.

@schwandi, man kann hier auch Dateianhänge erstellen.

Moin Dude566,
ein sehr interessantes Buch zum Thema Kryptologie ist das Werk von Simon Singh Geheime Botschaften
Gruß
Fiete

^^ ok

Anbei sollten die Datein sein

lg

Hallo, ich melde mich hier mal wieder.

Ich bin jetzt am überlegen welches Verfahren der modernen Kryptographie ich exemplarisch miteinbringen könnte und wie ich es dann vll sogar als Beispielanwendung machen könnte.

In den Sinn kam mir, wie oben schon diskutiert wurde, dass ich einfach einen Benutzerlogin zu einer Seite mit "gesalzenem" MD5 mache.

Oder was würdet ihr mir vorschlagen?

Wenn Du etwas Modernes haben möchtest, würde Ich Dir Sonys Implementierung für ECC (Elyptic Curve Crypto) empfehlen Dazu noch erklären, warum man NICHT den XKCD-RNG verwenden sollte und der Vortrag ist perfekt

Für Old-Fashioned geht natürlich auch ein Salted-Hash-MD5-Site-Login ^^

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Gut ich möchte ja auch immer noch bei der Mathematik bleiben, habe mir überlegt vielleicht das Prinzip des RSA Verfahren zu erläutern.

Edit: Das ECC dürfte für einen Vortrag im Mathe-GK etwas overpowered sein aber anschauen werde ich es mir nochmal genauer.