Webauftritt aktualisiert inkl. Transparenzbericht

Stelle deine Frage öffentlich an die Threema-Forum-Community - über 3.000 Mitglieder helfen dir weiter. Los gehts!
Unterstützung von offizieller Seite erhältst du direkt bei Threema: Zum offiziellen Threema-Support
  • Hallo @"Mr. Meyhet":
    da Du mich hier extra zitiert hast...dann eben doch auch hier im Klartext, was ich anderer Stelle schon so ähnlich geschrieben hatte:


    Du hast mit Deiner Bemerkung IMHO recht - und ich habe prinzipiell auch nichts dagegen, wenn im plausiblen Einzelfall nach genauer Prüfung von Threema eine Info an Behörden gegeben wird (wenn das auch nach den einschlägigen Veröffentlichungen nicht viel sein kann...)
    Der Threema-Support könnte sich meiner Meinung nach hier im Forum aber schon etwas mehr bei Problemen oder Vorschlägen zu Wort melden... Schließlich setzen viele Leute hier im Forum den eigenen Gehirnschmalz zur Verbesserung des Produkts Threema oder zur Hilfestellung für andere User ein. Und das kostenlos.
    Bei den o.g. "heißen" Themen wird man aber erfahrungsgemäß keine Meinungsäußerung oder offizielle Info von Threema erwarten können. Die dürfen sich ja auch nicht zu weit aus dem Fenster lehnen, um nicht in die falsche Ecke gestellt zu werden... Und genau so war meine etwas flapsige Antwort in Deinem Zitat gemeint.

    __________________________
    Gruß Miaz
    (Samsung Galaxy S7 / Sony Xperia Z1C / Threema seit 08-2014)

    Einmal editiert, zuletzt von Miaz ()

  • Diese Rechtshilfeersuchen (oder wie das heißt) gibt es ja bei jedem Messenger. Klar mit mehr oder weniger Daten/Auskunftsfreudigen Betriebern oder eher weniger auskunftsfreudig...


    Das Einzigste, was mich noch wirklich interessiert ist das Thema Telefonnummer... wie läuft das nun genau?


    Warum liegt diese anscheinend im Klartext vor? Warum wird die nicht verschlüsselt/gehasht/was auch immer? Woran liegt das? Hat das technische Gründe? usw.


  • Warum liegt diese anscheinend im Klartext vor? Warum wird die nicht verschlüsselt/gehasht/was auch immer? Woran liegt das? Hat das technische Gründe? usw.


    Hashen von Telefonnummern ist relativ nutzlos, egal in welchem System. Wenn es beispielsweise um eine Schweizer Mobiltelefonnummer geht, gibt es ca. 40 Millionen Möglichkeiten (076 xxx xx xx - 079 xxx xx xx).


    Hier ist ein unoptimiertes Programm in der relativ langsamen Programmiersprache Python, welches 40 Millionen mal einen SHA256 Hashwert berechnet:


    Code
    1. import hashlib
    2. numbers = map(lambda x: str(x).encode('utf8'), range((10**7) * 4))
    3. for number in numbers:
    4.     m = hashlib.sha256()
    5.     m.update(number)
    6.     m.digest()


    Die Ausführung dauert auf meinem System 50 Sekunden. Die Resultate kann man in einer Datenbank (oder einer Textdatei) speichern, und schon hat man eine Tabelle, in der man jeden Hash einer Telefonnummer zuordnen kann...


    Mit einer systemnahen Programmiersprache sowie parallelisierter Ausführung auf GPUs dauert selbst das Berechnen aller Hashwerte aller Telefonnummern aus dem deutschsprachigen Raum allerhöchstens ein paar Minuten...


    Das gehashte Speichern von Telefonnummern ist Security by Obscurity.


    Als Vergleich: Beim Hashen von Passwörtern mit 10 Stellen bestehend aus Buchstaben und Zahlen gibt es bereits 839'299'365'868'340'224 (839 Billiarden) Möglichkeiten. Die Kombinatorik bei E-Mail-Adressen verhält sich ähnlich.

  • Ich habe keine Einwände gegen (begründete) Einzelabfragen.
    Mich interessiert nur, wieso Threema die ungehashte (!) Telefonnummer zu einer ID überhaupt liefern kann, wo doch der Adressbuch-Abgleich nur in gehashter (!) Form geschehen soll? Oder andersherum: wieso speichert Threema die Telefonnummer im Klartext offenbar doch dauerhaft, die beim Verknüpfen einer ID zwangsläufig einmalig in Threema offenbart werden muss? [1] Eine technische Notwendigkeit für die Speicherung kann ich nicht erkennen. Ist es vielleicht eine gesetzliche Auflage? Und wenn ja, welche Auflagen zur Speicherung von Daten gibt es vielleicht noch?
    Im Gegensatz übrigens zur Email-Adresse, die Threema offenbar nur gehasht liefert.


    [EDIT]
    Zu [1]: das Threema-Whitepaper hält sich sehr bedeckt darüber, wie Threema mit der Klartext-Email bzw. -Telefonnummer eines Nutzers umgeht, nachdem die Verifikation abgeschlossen wurde, also nachdem die Bestätigungs-SMS bzw. -Email empfangen wurde. Insbesondere ist dem Abschnitt "Linking" auf der vorletzten Seite nicht zu entnehmen, dass die Klartext-Daten gelöscht würde...
    Zum Whitepaper: https://threema.ch/press-files/cryptography_whitepaper.pdf

  • Zitat


    Als Vergleich: Beim Hashen von Passwörtern mit 10 Stellen bestehend aus Buchstaben und Zahlen gibt es bereits 839'299'365'868'340'224 (839 Billiarden) Möglichkeiten. Die Kombinatorik bei E-Mail-Adressen verhält sich ähnlich.


    Was wiederum bedeutet, dass kurze E-Mail-Adressen das gleiche Problem wie die Rufnummern haben. Es muss mindestens 1 @ und 1 Punkt drin sein. Sicherlich kann man bei Android von 90% @gmail.com ausgehen. Auch werden die meisten E-Mail-Adressen klein geschrieben. Somit bleiben eigentlich nur sinnvoll die Zeichen vor dem @. Das wären dann ca. 36 Kominationen pro Zeichen. Somit wäre eine E-Mail-Adresse wie ich125@gmail.com mit 6 Stellen zu knacken in 36^6=2,1 Milliarden Möglichkeiten.


    SHA256 sind 64 Bytes bei 2,1 Milliarden E-Mail-Adressen wären das insgesamt 129,7 Gbyte an Hash-Daten. Keine Ahnung ob das für Knacker/Hacker viel ist oder nicht...


    Nachtrag: 40 Mio. Rufnummern wären dem nach bei SHA-256 2,38 GByte an Hash-Daten.

  • Hashen von Telefonnummern ist relativ nutzlos, egal in welchem System. Wenn es beispielsweise um eine Schweizer Mobiltelefonnummer geht, gibt es ca. 40 Millionen Möglichkeiten (076 xxx xx xx - 079 xxx xx xx).


    Hatte das schon mal in einem anderen Thread angemerkt: Das Problem müsste man mit scrypt zumindest etwas entschärfen können, right?


  • Das Problem müsste man mit scrypt zumindest etwas entschärfen können, right?


    Könnte man, aber durch die geringe Anzahl von Möglichkeiten würde es wohl auch nicht so viel helfen. dennoch kannst du dies doch mal Threema vorschlagen.
    Wenn möglich sollte man aber eher den Gewinner aus dieser Competition nehmen (ARGON2): https://password-hashing.net/
    Und den gleichen natürlich auch für E-Mail-Adressen (wo er noch mehr Sinn macht).
    Aber abgesehen davon zu:


    Die Resultate kann man in einer Datenbank (oder einer Textdatei) speichern, und schon hat man eine Tabelle, in der man jeden Hash einer Telefonnummer zuordnen kann...


    Da Threema einen HMAC verwendet, müsstest du dein Skript nur auch noch anpassen um eine passende Textdatei (aka Rainbow-Table) für Threemas Telefonnummern zu erstellen, aber sonst geht es so, ja.



    Das gehashte Speichern von Telefonnummern ist Security by Obscurity.


    Das kommuniziert Threema aber auch so (und zwar schon von Anfang an):


    Zitat


    Bitte beachten Sie: aufgrund der relativ wenigen möglichen Zahlenkombinationen von Telefonnummern können Hashes davon theoretisch per Brute-Force-Attacke (= Durchprobieren aller Möglichkeiten) entschlüsselt werden. Dies ist prinzipbedingt und kann nicht anders gelöst werden (die Verwendung von Salts wie beim Hashing von Passwörtern funktioniert für so einen Datenabgleich nicht). Wir behandeln daher die Telefonnummern-Hashes mit der selben Vorsicht, als wenn es rohe/ungehashte Telefonnummern wären.


    https://threema.ch/de/faq/addressbook_data


    Mich würde dennoch interessieren, warum die Telefonnummern nicht gehasht gespeichert werden (Oder werden sie es doch und das ist ein Fehler im Transparenzbericht?). Zumal das ständige Neuhashen der Nummern auf dem Threema-Server bei einem Adressbuchabgleich ja nicht gerade förderlich für die Performance wäre.
    Hat da eventuell schon mal jemand beim Threema Support nachgefragt?


  • Nach dem Argument, dürften die Mail Adressen ja auch nicht gehashed werden. Die werden ja genau so abgeglichen und die sind teilweise noch länger.


    Nein, reguläre Hash-Algorithmen wie SHA256 sind ja relativ schnell. Algorithmen für Passwörter wie z.B. PBKDF2 oder bcrypt sind explizit gemacht, dass sie sehr langsam sind. Bei einem Login für eine Hash-Berechnung 1 Sekunde warten ist kein grosses Problem. Aber wenn das Smartphone eines Users 30 Sekunden bei voller CPU-Auslastung braucht, um das Adressbuch zu hashen, dann vermutlich schon.


  • Hashing-Algorithmen mit hohen CPU-/Memory-Kosten würden dann aber wohl den Adressbuchabgleich massiv verlangsamen (und ergo den Energieverbrauch beim Sync erhöhen). Ich kenne Leute mit 500+ Kontakten...


    Ja, das ist mir gestern auch noch aufgefallen. Das schwächste Glied ist hier durch die geringe Rechenleistung der Smartphones gegeben.



    Nach dem Argument, dürften die Mail Adressen ja auch nicht gehashed werden. Die werden ja genau so abgeglichen und die sind teilweise noch länger.


    Die Länge der plaintexts ist hierbei eher nebensächlich. Ich weiß nicht genau wie scrypt funktioniert, aber in der Regel erhöht man die Anzahl der Iterationen, indem man den resultierende Hash einfach nochmal in die Hash-Funktion wirft und das sehr oft.

  • Ich wollte darauf hinaus, dass das Hashen bei Nummern und Mail Adressen ja keinen Unterschied machen sollte. Beider werden durch Threema Verifiziert, beide werden die gleiche Hash-Dauer benötigen und beide werden beim Adressbuch-Abgleich benötigt.
    Mir erschließt sich daher kein Grund für den unterschiedlichen Umgang mit den Daten.

  • Ich habe nochmals genau gelesen und darüber gedacht.



    Zitat


    Sofern die rechtlichen Voraussetzungen vollständig erfüllt sind, können wir folgende Angaben zu einer gegebenen Threema-ID liefern:

    • Handynummer, sofern durch den Nutzer verknüpft


    Können heißt ja nicht zwingend wird oder muss geliefert werden.


    Sofern verknüpft:
    Gibt es nicht die Möglichkeit am Anfang beim Einrichten der ID sich eine Bestätigungs-SMS schicken zu lasssen? Da müsste ja die Nummer im Klartext da sein, sonst könnte Threema ja keine SMS schicken?

  • Hm, wenn beide Angaben für die Verifikation einmalig im Klartext vorliegen müssen, ist die Frage wohl, ob es sich lohnt, die E-Mailadresse und die Telefonnummer überhaupt nachträglich zu hashen. Bei der E-Mail-Adresse würde ich klar ja sagen (was ja so wie's aussieht auch so gehandhabt wird). Bei der Telefonnummer würde ich - wie in einem meiner letzten Posts erwähnt - verneinen. Wenn es nichts bringt, ist es Security by Obscurity.

  • Dennoch hätte ich erwartet, dass die Klartext-Telefonnummer nicht dauerhaft gespeichert wird - einfach, um das Zero-Knowledge-Prinzip zu erfüllen (bzw. so nahe wie möglich zu kommen) [1]. Im Gegensatz zur gehashten Telefonnummer ist die Klartext-Nummer auch nicht zum Betrieb erforderlich, sondern nur zur einmaligen Verifikation.


    [1] unter https://threema.ch/de/faq/data wird auch der Eindruck vermittelt, dass so wenig Daten wie möglich gespeichert werden, und insbesondere nur solche, die zur asynchronen verschlüsselten Kommunikation (und Kontakt-Discovery) erforderlich sind. Die Klartext-Telefonnummer gehört m. E. nicht dazu und wird dort auch gar nicht als permanent gespeichertes Datum erwähnt.


    - Andy
    [hr]
    Was passiert eigentlich, wenn ich die Verknüpfung nachträglich aufhebe? Werden dann die gehashte Emailadresse und die Klartext-Telefonnummern derart gelöscht, dass sie nicht mehr geliefert werden können? Oder werden die nur als gelöscht markiert, können aber doch noch geliefert werden? Vermute aber, dass sich das nicht zufriedenstellend klären lässt...



    - Andy

  • Hier noch ein Puzzle-Teil (Quelle: https://threema.ch/de/privacy):

    Zitat


    E-Mail-Adressen und Telefonnummern, die für die Verknüpfung verwendet wurden, werden nur zum Zweck der Synchronisation gespeichert und nicht an Dritte weitergegeben. Sie werden auch nicht für Werbezwecke verwendet. Der Benutzer kann seine Verknüpfungen jederzeit wieder löschen. Von verknüpften E-Mail-Adressen [Anm.: gilt also nicht für die Telefonnummer] wird nur ein Hash gespeichert.


    Im Umkehrschluss und im Zusammenhang mit dem Transparenzbericht muss man das wohl so verstehen, dass Threema wohl tatsächlich die Telefonnummer im Klartext speichert. Auch wenn Telefonnummern-Hashes vergleichsweise leicht zu knacken sind, finde ich das nicht wirklich begrüßenswert und eher enttäuschend, da ich das von Threema nicht erwartet hätte und ich das Gefühl habe, nur eher zufällig darüber gestolpert zu sein anstatt offen darüber informiert worden zu sein. Zumal im selben Zitat auch einleitend steht, dass "Telefonnummern, die für die Verknüpfung verwendet wurden, [...] nur zum Zweck der Synchronisation gespeichert [werden]" - dafür ist die Klartext-Telefonnummer sicher nicht erforderlich.
    Muss man jetzt auch bei Threema immer argwöhnisch zwischen den Zeilen lesen und kann sich nicht auf offen und ehrliche kommunizierte Bedingungen verlassen?



    - Andy