Frage zum ID-Widerruf
#1
Hallo Leute,

im Moment ist es ja so, dass nur die ersten 4 Bytes (von 32 Bytes) des SHA256-gehashten Passworts an den Threema-Server geschickt bzw. dort gespeichert werden. Laut Cryptography-Whitepaper soll das Brute-Force-Angriffe auf Server-Seite verhindern.

Irgendwie verstehe ich dieses Vorgehen aber nicht. Jemand, der Zugriff auf den Server hat (egal ob 4 oder 32 Byte) kennt diesen Hash und kann den doch einfach an den Server von myid.threema.ch/revoke_ajax POSTen. Außerdem könnte jemand mit Zugriff auf den Server doch das Widerrufen selbst in Gang setzen?

Mir ist im Moment das Angriffs-Szenario nicht ganz klar, das man verhindern möchte. Kann mich hier jemand aufklären?

Außerdem, warum nutzt man nicht z. B. dieses Schema für das Passwort-Hashing (wie es z. B. Django macht, mit einer geeigneteren Hash-Funktion)?
<iterations>$<salt>$<hash>, also z. B. 200000$(Threema-ID)$(PBKDF2-Hash)

Da ist doch ein Brute-Force-Angriff so gut wie ausgeschlossen. Aber wenn man den Hash kennt, kann man den doch wiederum POSTen.

Ich hoffe man kann mir das erklären, steh' wohl auf dem Schlauch gerade. Lachen
Zitieren
#2
(24.05.2018., 16:57)Crixus schrieb: im Moment ist es ja so, dass nur die ersten 4 Bytes (von 32 Bytes) des SHA256-gehashten Passworts an den Threema-Server geschickt bzw. dort gespeichert werden.
Das ist jetzt zwar nicht direkt eine Antwort auf deine Frage, aber ich habe gerade mal meine bei Threema gespeicherten Daten angerufen (siehe https://threema.ch/de/faq/get_my_data). Interessanterweise ist zum Revocation–Passwort lediglich das Datum, wann es gesetzt wurde, bei Threema gespeichert... Aber kein Passwort–Hash?!
Oder wird das aus Sicherheitsgründen nicht Bestandteil der Abfrage?

Und zur Frage selbst: ich habe mich darüber auch schon mal gewundert und keine Antwort gefunden, weshalb Threema so vorgeht...


Andy
Zitieren
#3
Ich gehe stark davon aus, dass dieser aus Sicherheitsgründen nicht Bestandteil ist. Wobei, streng genommen, diese Abfrage ja sowieso nur an den richtigen Empfänge geschickt wird. Demzufolge wäre das gar nicht so dramatisch.
Zitieren
#4
(24.05.2018., 16:57)Crixus schrieb: Irgendwie verstehe ich dieses Vorgehen aber nicht. Jemand, der Zugriff auf den Server hat (egal ob 4 oder 32 Byte) kennt diesen Hash und kann den doch einfach an den Server von myid.threema.ch/revoke_ajax POSTen.

Richtig, also wenn Threema (die Zugriff auf den Server haben) böse ist, dann können Sie den Hash nehmen und über die Webseite deine ID revoken. Aber hey… da sie im Besitz des Servers sind, könnten sie das noch viel leichter machen… Da wird dann gar kein Passwort benötigt Lächeln

(24.05.2018., 16:57)Crixus schrieb: Mir ist im Moment das Angriffs-Szenario nicht ganz klar, das man verhindern möchte. Kann mich hier jemand aufklären?

Wenn es aus dem obigen Beispiel nicht klar wurde, es geht nicht darum, zu verhindern, dass Serveradmins die geschütze Aktion (ID revoke) auslösen können, sondern darum, dass sie nicht in Besitz des Klartextpasswortes kommen bzw. dass es nie im Klartext an den Server übermittelt wird.
Zitieren
#5
Ja, aber warum macht man es dann so kompliziert und nimmt nur die ersten 4 Bytes und nicht, wie oben vorgeschlagen, z. B. PBKDF2 mit der Threema-ID als Salt und ~ 200000 Iterationen.

Und unabhängig davon, wenn man mit Brute-Force wirklich erfolgreich sein sollte, hat man eigentlich nichts davon, weil einem ja der Hash bereits reicht. Warum sollte man sich also die Mühe machen? Der einzige Grund, der mir einfällt, ist dass man darauf hofft, dieses Passwort dann auch auf anderen Seiten verwenden zu können.

Aber Threema sollte eigentlich das gehashte Passwort serverseitig nochmal hashen, sodass die Datenbank nicht so gefährlich wird. Hat jemand Zugriff darauf, kann man praktisch die komplette Threema-Infrastruktur lahmlegen. Bitte mehr Infos dazu.
Zitieren
#6
Kann Threema eine Erklärung evtl. ins Whitepaper mit aufnehmen?
Zitieren
#7
Sorry für die Hartnäckigkeit, aber so richtig verstanden habe ich das immer noch nicht. Kann sich evtl. @"Julia" oder @"Valeria" dazu äußern?
Zitieren
#8
(24.05.2018., 21:31)rugk schrieb: Richtig, also wenn Threema (die Zugriff auf den Server haben) böse ist, dann können Sie den Hash nehmen und über die Webseite deine ID revoken. Aber hey… da sie im Besitz des Servers sind, könnten sie das noch viel leichter machen…  Da wird dann gar kein Passwort benötigt Lächeln

Korrekt. Wer Zugang zu den Servern hat, braucht den Hash sowieso nicht, um IDs zu widerrufen. Es geht darum, bei Threema möglichst wenig verwertbare Informationen zu speichern.

(25.05.2018., 05:55)Crixus schrieb: Ja, aber warum macht man es dann so kompliziert und nimmt nur die ersten 4 Bytes und nicht, wie oben vorgeschlagen, z. B. PBKDF2 mit der Threema-ID als Salt und ~ 200000 Iterationen.

So kompliziert ist es ja nicht, von einem SHA256-Hash die ersten vier Bytes zu nehmen – ganz im Gegenteil. Vor allem wenn man es mit PBKDF2, bcrypt, scrypt etc. vergleicht, wo man sich dann auch noch für Parameter entscheiden und diese regelmässig den Entwicklungen anpassen muss.

Es ist einfach, erfüllt den gegebenen Zweck und hat eben genau den Vorteil, dass auch mit einer Brute-Force-Attacke i.d.R. keine eindeutige Zuordnung zum vom User verwendeten Passwort möglich ist. Typischerweise verwenden Nutzerinnen und Nutzer ja häufig immer noch dasselbe Passwort für unterschiedliche Zwecke...

Viele Grüsse
Julia
Zitieren
#9
Mag sein, dass ich hier etwas zu vorsichtig bin, aber ich habe ein ungutes Gefühl. Hat jemand Zugriff auf die Datenbank, mit den ganzen Hashes, kann diese Person die KOMPLETTE Threema-Infrastrutkur lahm legen. So gut schützen kann man die ja gar nicht.

Warum also nicht serverseitig mit Argon2 nochmal verschlüsseln? Dann ist die Datenbank zumindest nicht mehr ganz so pikant.
Zitieren
#10
Argon2 ist erstmal keine Verschlüsselung, sondern auch nur ein Hash. Zum anderen, wie erwähnt nicht nötig, da sowieso nur wenige Infos auf dem Server gespeichert werden.
Und hat jemand Zugriff auf eine Threema-Datenbank, kann diese Person die komplette Infrastruktur (zumindest kurzzeitig) auch einfach lahm legen, indem dieser die Datenbank löscht. Selsbt wenn diese Person den unnötigen Weg nehmen würde und alle IDs revoken würde, dann könnte man das sicherlich serverseitig wieder rückgängig machen. Schließlich ist der Vorgang "ID revoken" etwas, dass nur auf dem Server stattfindet und die Clients nur die ID anders anzeigen.

Aber nochmal zum Passwort:
Bsp, nehmen wir hier 4 Zeichen, da dies leichter als 4 Bytes zu erklären ist. Außerdem nehmen wir an, dass das Passwort im Plaintext gespeichert würde.
Wäre also jetzt "EinP" gespeichert. Wenn der Nutzer sein richtiges Passwort "EinPasswortSuper778%SicherSeinÄhm" eingibt, kann man leichter verifizieren, dass die ersten 4 Zeichen stimmen, aber nur aufgrund der 4 Zeichen "EinP" kann man nicht das Passwort heraus finden, da es "EinPass123" sein könnte, oder "EinParken" oder "EinPs" o.ä.

Und da ein Hash genommen wird, werden da selbst die Anfangsbuchstaben des Passwortes nicht auf dem Server gespeichert.
Zitieren
#11
Naja, es könnte ja jemand LESEND Zugriff auf die DB haben, aber nicht die Möglichkeit sie zu löschen oder zu verändern. Dann würde das serverseitige Hashen doch was bringen. Zudem könnte man dann das volle Passwort verwenden und nicht nur die ersten 4 Bytes.

Und ob die Rückkehr des Schlüssel-Widerrufs so einfach möglich ist liegt daran wie der Client das umsetzt.
Zitieren