Kodi Forum Data Breach

[Nostalgic]

https://kodi.tv/article/important-kodi-forum-data-breach/

fuck

[Rooter]

user data including forum username, email address used for notifications, and an encrypted (hashed and salted) passwordBlöd, aber könnte schlimmer sein. *hust*Adobe*hust*

MfG
Rooter

[Sephiroth]

Blöd, aber könnte schlimmer sein. *hust*Adobe*hust*

MfG
Rooter
nicht wirklich, die einschätzung ist mMn. korrekt: da die unbefugte Partei auch den salt hat (wird zusammen mit dem PW-Hash in der DB gespeichert), ist das de-facto gleichbedeutend damit als gäbe es kein salt. hinzukommt das veraltete hashing verfahren mit md5 (https://www.mybb.de/forum/thread-35354.html). sie sollten dann künftig das plugin (https://community.mybb.com/mods.php?action=view&pid=976) mit argon2id verwenden.

[Rooter]

nicht wirklich, die einschätzung ist mMn. korrekt: da die unbefugte Partei auch den salt hat (wird zusammen mit dem PW-Hash in der DB gespeichert), ist das de-facto gleichbedeutend damit als gäbe es kein salt.:confused: Dass das Salt mit dem Hash abgespeichert wird, ist so üblich:
https://de.wikipedia.org/wiki/Salt_(Kryptologie)

MfG
Rooter

[Sephiroth]

Ist das eine Frage? Natürlich ist das üblich, muss ja sogar. Der Punkt ist: wenn ich den salt und das hashing-verfahren habe, kann man die rainbow-table r1 trotzdem benutzen, weil man lediglich eine neue rainbow-table r2 aus r1 + salt des accounts erstellen muss. zugegeben, das muss man pro account machen aber bei 400k usern ist das bei der heutigen rechenleistung zu verkraften.

btw:

hashcat (v6.2.6) starting in benchmark mode

OpenCL API (OpenCL 3.0 CUDA 12.1.98) - Platform #1 [NVIDIA Corporation]
=======================================================================
* Device #1: NVIDIA GeForce GTX 1660 Ti, 5440/6143 MB (1535 MB allocatable), 24MCU

Benchmark relevant options:
===========================
* --optimized-kernel-enable

-------------------
* Hash-Mode 0 (MD5)
-------------------

Speed.#1.........: 21456.7 MH/s (37.24ms) @ Accel:128 Loops:1024 Thr:256 Vec:8

----------------------------------------------------------------
* Hash-Mode 3200 (bcrypt $2*$, Blowfish (Unix)) [Iterations: 32]
----------------------------------------------------------------

Speed.#1.........: 14357 H/s (68.73ms) @ Accel:4 Loops:32 Thr:11 Vec:1

----------------------------------------------------------
* Hash-Mode 2811 (MyBB 1.2+, IPB2+ (Invision Power Board))
----------------------------------------------------------

Speed.#1.........: 4717.2 MH/s (84.98ms) @ Accel:64 Loops:1024 Thr:256 Vec:1

--------------------------------------
* Hash-Mode 2711 (vBulletin >= v3.8.5)
--------------------------------------

Speed.#1.........: 4464.3 MH/s (89.81ms) @ Accel:64 Loops:1024 Thr:256 Vec:1

bin gespannt wie das bei argon2 einmal aussehen wird. noch wird es nicht unterstützt (https://github.com/hashcat/hashcat/issues/1966).

[Rooter]

Ich dachte es dauert Tage, Wochen oder gar Monate eine Rainbow-Table zu erstellen?

MfG
Rooter

[Acid-Beatz]

Ich dachte es dauert Tage, Wochen oder gar Monate eine Rainbow-Table zu erstellen?

MfG
Rooter

Die kannst Du Dir fertig im Internet besorgen ... bis Dir der Platz ausgeht, also mehrere TB :freak:

[Rooter]

Die müssen pro Salt neu erstellt werden.

MfG
Rooter

[Sephiroth]

du brauchst ja keine komplett neue. du hängst an die bestehende eine weitere iteration an, indem du den bestehenden unsalted hash mit dem salt entsprechend des zielverfahrens verknüpfst. sicher, für lau ist das nicht aber vermutlich trotzdem "billiger" als andere verfahren. und in der praxis würde man sich zunächst auch auf interessante accounts beschränken, in der hoffnung, dass diese user das gleiche passwort in einem anderen, viel interessanteren kontext ebenfalls nutzen.

[Milchkanne]

du brauchst ja keine komplett neue. du hängst an die bestehende eine weitere iteration an, indem du den bestehenden unsalted hash mit dem salt entsprechend des zielverfahrens verknüpfst. sicher, für lau ist das nicht aber vermutlich trotzdem "billiger" als andere verfahren. und in der praxis würde man sich zunächst auch auf interessante accounts beschränken, in der hoffnung, dass diese user das gleiche passwort in einem anderen, viel interessanteren kontext ebenfalls nutzen.

Wie soll das denn funktionieren? Rainbow Tables werden ja gebildet, indem (praktisch) alle* Kombinationen von Passwörtern durchprobiert werden und das dann speichereffizient gespeichert wird. Wenn die Ketten berechnet werden, wird das Passwort immer ohne Salt gehasht. Wie man das updaten können soll, ist mir schleierhaft.

* alle als Ziel der Table. Die gibt es ja dann als loweralpha#1-10 oder mixalpha-numeric#1-9 oder so. Die Passwörter, die man mit RTs knacken kann sind doch relativ kurz.

Wer mit nem Passwortmanager überall verschiedene Passwörter nutzt, dem kann das eh egal sein.

[Sephiroth]

Worauf ich hinaus wollte ist folgendes.

Wir haben für alle accounts
yn = f(xn)

Pro account haben wir
z = f(s)
y' = f(y + z) = f(f(x) + f(s))

x ist das (gesuchte) passwort im klartext
s ist der salt
f ist md5
y ist der unsalted hash von einem bekannten passwort
y' ist unser bekannter salted passwort hash vom account

yn und xn liefert uns die table

input ist also nun y' und wir suchen dasjenige yn, für das gilt: yn = y' = f(yn + z) = f(f(xn) + z), damit wir das zugehörige xn "ablesen" können, weil das unserem gesuchten x entspricht.

was wir also tun müssen ist einmal z bestimmen, das pro account konstant ist, und für jedes yn noch y'n berechnen. es sind also zusätzlich max. n + 1 viele operationen von f durchzuführen.

damit kann ich die table weiterhin nutzen.

[Milchkanne]

Wir haben für alle accounts
yn = f(xn)



x ist das (gesuchte) passwort im klartext

Was genau ist jetzt nochmal xn wenn nicht das Passwort im Klartext?



Pro account haben wir
z = f(s)
s ist der salt

Wir haben sogar das ungehashte Salt, aber egal.


y' = f(y + z) = f(f(x) + f(s))


Ähh also wir haben (warum verwendest du überhaupt f,x,y usw. schreib doch einfach was du sagen willst):
md5(pw+salt) und das Salt
Zerlegen lässt sich das nicht weiter.


yn und xn liefert uns die table

was soll denn jetzt schon wieder yn und xn sein? Die Table liefert uns nichts mehr. Eine RT ist mit einer begrenzten Symbol und Passwortlänge gebaut worden. Beispielsweise groß/kleinbuchstaben 1-8 Zeichen lang. In dem Rahmen kann eine RT die Hashfunktion umkehren, (meist zu 99% oder so). Wenn du ein Salt ranhängst, bist du zu 99% aus dem Definitionsbereich der Table raus und damit bring sie dir absolut nichts mehr.


input ist also nun y' und wir suchen dasjenige yn, für das gilt: yn = y' = f(yn + z) = f(f(xn) + z)

yn = f(yn + z), ne Differentialgleichung oder was?

damit wir das zugehörige xn "ablesen" können, weil das unserem gesuchten x entspricht.

also ist x_n tatsächlich x?

was wir also tun müssen ist einmal z bestimmen, das pro account konstant ist,

was ist denn pro account nicht konstant?

und für jedes yn noch y'n berechnen. es sind also zusätzlich max. n + 1 viele operationen von f durchzuführen.

n? ich dachte das wäre die Laufvariable für die Accounts? Soll das die Anzahl der Accounts sein oder was?

damit kann ich die table weiterhin nutzen.
Unwahrscheinlich.

Wir haben s und md5(s+pw) und das ist jetzt nicht irgendwie md5(s)+md5(pw) oder sowas. Für CRC32 kann man da was basteln, aber selbst für md5 gilt das nicht. Aber ich hör mir gerne nochmal deine Erklärung an. Soll die auch für SHA und co gelten?

[Rooter]

Wir haben s und md5(s+pw) und das ist jetzt nicht irgendwie md5(s)+md5(pw) oder sowas.Ja, darüber bin ich auch gestolpert.

y' = f(x + s)

MfG
Rooter

[Sephiroth]

n ist die anzahl der einträge in deiner table.
xn ist ein mögliches passwort und yn der zugehörige hash (hier also plain md5). das ist der inhalt unserer festen table.

Wir haben sogar das ungehashte Salt, aber egal.
ja, s, genau das habe ich geschrieben. z wäre der gehashte salt.

Wir haben s und md5(s+pw) und das ist jetzt nicht irgendwie md5(s)+md5(pw)

nein, der erbeutete hash y' aus salt s und passwort x ist md5(md5(s)+md5(x)) (hab ich übrigens oben aus versehen in der reihenfolge vertauscht, tut aber nichts zur sache) - siehe mein 1. link in beitrag #3.

Unwahrscheinlich.
mein y' werde ich nicht finden, weil die table nur das einfache y enthält. aber mit dem wissen wie aus y ein y' wird, kann ich diese einfache berechnung on-demand durchführen. wenn ich also den hash y1 = 920ECF10 in meiner table habe und dazu x1 = aaaaaa ein passwort ist, dann ist x1 auch ein passwort für y'1. ich schau also nicht nach ob mein y' einem der yn entspricht, sondern y'n. wenn ich von einem hash yn zum nächsten yn+1 gehe, wende ich jedes mal darauf noch die umwandlungsfunktion an.

[Milchkanne]

nein, der erbeutete hash y' aus salt s und passwort x ist md5(md5(s)+md5(x))

Ok, von mir aus auch beide vorher gehasht.


...

Puh es ist echt schwer dir zu folgen.

Ich glaube dir ist nicht klar, wie eine Rainbow table gespeichert wird oder? Das ist keine Excel Tabelle, die zu jedem Hash ein Passwort enthält. Das sind Hash ketten, wo nur der Anfang und das Ende gespeichert werden. Dein Hash ist nicht einfach so mal eben in der Tabelle zu finden. Die Suche ist (je nach Größe der Tabelle) schon mit Aufwand verbunden. Wenn du deinen Hash für jede Kette erweitern willst, dann ist das so aufwändig wie neuberechnen. Für eine große Tabelle kann die Suche nach einem Hash auch mal ein paar Minuten dauern.

Nehmen wir nochmal md5(md5(s)+md5(x)) was genau suchst du jetzt in der Tabelle?

[HarryHirsch]

ich verstehe gerade das problem nicht. was für supergeheime daten (abgesehen vom passwort) können da denn abgegriffen worden sein?

[BigKid]

ich verstehe gerade das problem nicht. was für supergeheime daten (abgesehen vom passwort) können da denn abgegriffen worden sein?
Naja... Das Passwort und die eMail Adresse eben...
Und dann kannste mal testen bei wievielen Forn, Webseiten oder eMail Accounts etc. du dich dann damit anmelden kannst für jemand anderen... Es ist nach wie vor verbreitet die selben PWs zu nutzen... Manche habe nichtmal für ihre eMail Accounts ein anderes und damit biste dann quasi überall drinn weil du dann nur mit der eMail Adresse das PW bei den anderen Diensten ändern kannst...
Ups... Sorry für Necro...

[Ben Carter]

Idealerweise gibt es aber noch einen zweiten Salt, der nicht in der DB steht (dafür leider auch nur einer für alle) und es ist nicht einfach passwort + salt, sondern eine andere Art der Verknüpfung zwischen den beiden.
Vereinfacht paSssAwoLrtT. Beides macht es nicht unknackbar, aber zumindest ein weniger schwieriger, auf das korrekte Passwort und nicht nur irgendeine Kollision zu kommen.

[Rooter]

Idealerweise gibt es aber noch einen zweiten Salt, der nicht in der DB steht (dafür leider auch nur einer für alle) und es ist nicht einfach passwort + salt, sondern eine andere Art der Verknüpfung zwischen den beiden.Ja, du meinst "Pepper (https://de.wikipedia.org/wiki/Salt_(Kryptologie)#Pepper)".

MfG
Rooter