Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › WLAN-Tracking: Ab Juli 2019 will…

"MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

  1. Thema

Neues Thema Ansicht wechseln


  1. "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: katze_sonne 23.05.19 - 13:52

    Was? Das ergibt doch keinen Sinn.

    Ein Salt wird immer einem Nutzer (in diesem Fall: MAC-Adresse?) zugeordnet, denn sonst würde der Hash von MAC + Zufallswert ja auch einen "Zufallswert" ergeben und man könnte kein Tracking mehr betreiben.

    Bleibt also noch: Man speichert zusätzlich zur MAC-Adresse einen Salt und hasht diese Kombination dann. Aber wenn man sowieso die MAC-Adresse speichert, kann man sich das doch gleich schenken. Oder speichert man doch alles und wertet dann die mit einem Salt anonymisierten Daten aus? (dann könnte man sich das doch gleich alles sparen)

    Oder wird jeden Tag ein anderer Salt verwendet? Dann wäre ein Nutzer immer nur tagesweise zuordbar.

    Das einzige, was hier irgendeinen Sinn ergeben würde: Es wird nur der Hash der MAC-Adressen gespeichert. Dann hätte man trackbare Daten ohne die urpsrünglichen MAC-Adressen zu kennen. Aber wo da noch der Salt zu gut sein soll: Ich weiß es nicht. Allgemein ist die Idee bei nem Salt ja eigentlich eine andere: Nicht anonymisieren, sondern Rainbow-Table-Attacken zu verhindern.

  2. Re: "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: randya99 23.05.19 - 14:14

    Möglicherweise probieren sie einfach jedes Mal beim Hashen alle Salts durch, bis das Ergebnis und Salt übereinstimmen. Dann löschen sie den Salt nach Abschluss der Überwachung.

  3. Re: "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: trinkhorn 23.05.19 - 15:17

    katze_sonne schrieb:
    --------------------------------------------------------------------------------

    > Oder wird jeden Tag ein anderer Salt verwendet? Dann wäre ein Nutzer immer
    > nur tagesweise zuordbar.

    Das würde ja auch eines der im Artikel genannten eventuellen Probleme lösen...

  4. Re: "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: treysis 23.05.19 - 15:18

    trinkhorn schrieb:
    --------------------------------------------------------------------------------
    > katze_sonne schrieb:
    > ---------------------------------------------------------------------------
    > -----
    >
    > > Oder wird jeden Tag ein anderer Salt verwendet? Dann wäre ein Nutzer
    > immer
    > > nur tagesweise zuordbar.
    >
    > Das würde ja auch eines der im Artikel genannten eventuellen Probleme
    > lösen...

    Ist eh Quatsch. Aber Q wird Android vermutlich bei jeder Verbindung eine zufällige MAC-Adresse verwenden. Schon seit Oreo wird mit zufälligen Adressen gepollt.

  5. Re: "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: Nullmodem 23.05.19 - 15:27

    katze_sonne schrieb:
    --------------------------------------------------------------------------------
    > Was? Das ergibt doch keinen Sinn.
    >
    > Ein Salt wird immer einem Nutzer (in diesem Fall: MAC-Adresse?) zugeordnet,
    > denn sonst würde der Hash von MAC + Zufallswert ja auch einen "Zufallswert"
    > ergeben und man könnte kein Tracking mehr betreiben.
    >
    > Bleibt also noch: Man speichert zusätzlich zur MAC-Adresse einen Salt und
    > hasht diese Kombination dann. Aber wenn man sowieso die MAC-Adresse
    > speichert, kann man sich das doch gleich schenken. Oder speichert man doch
    > alles und wertet dann die mit einem Salt anonymisierten Daten aus? (dann
    > könnte man sich das doch gleich alles sparen)
    >
    > Oder wird jeden Tag ein anderer Salt verwendet? Dann wäre ein Nutzer immer
    > nur tagesweise zuordbar.
    >
    > Das einzige, was hier irgendeinen Sinn ergeben würde: Es wird nur der Hash
    > der MAC-Adressen gespeichert. Dann hätte man trackbare Daten ohne die
    > urpsrünglichen MAC-Adressen zu kennen. Aber wo da noch der Salt zu gut sein
    > soll: Ich weiß es nicht. Allgemein ist die Idee bei nem Salt ja eigentlich
    > eine andere: Nicht anonymisieren, sondern Rainbow-Table-Attacken zu
    > verhindern.

    Ich denke auch, das funktioniert nicht so, wie die das behaupten, denn:

    Möglichkeit A)
    Man speichert die MAC, den Salt und den Hash zusammen in der Datenbank -> keine Pseudonymisierung

    Möglichkeit B)
    Man generiert einen Salt, hasht MAC und Salt, verwirft die MAC und speichert Salt und Hash. -> sinnlos, denn so ist kein Tracking möglich, da ein anderer Salt mit derselben MAC einen anderen hash ergibt

    <edit>
    Möglichkeit C)
    Man benutzt für alle Zeiten ein festcodiertes Salt -> Na, da kann man auch gleich die MAC Adresse speichern, die ändert sich auch nie und ist praktisch zufällig
    </edit>

    Davon abgesehen hat die MAC-Adresse nur 6 Byte, eine Brut-Force Attacke ist also billigst möglich, im Moment machen die 0815 Bitcoin.Minerhardware 44TH/s, die 48 Bit (281e12) hashes kriegt man also in 281/44/2 = 3.19 Sekunden durchprobiert.
    <edit>
    Tatsächlich ist es wohl noch weniger, da die ersten 2 oder 3 Byte bei den Macadressen den Hersteller codieren und immer fix sind
    </edit>

    ($1500 ist jetzt nicht die Welt, wenn man Marc Buckerzerg heisst)

    nm



    1 mal bearbeitet, zuletzt am 23.05.19 15:33 durch Nullmodem.

  6. Re: "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: LinuxMcBook 23.05.19 - 19:40

    treysis schrieb:
    > Ist eh Quatsch. Aber Q wird Android vermutlich bei jeder Verbindung eine
    > zufällige MAC-Adresse verwenden. Schon seit Oreo wird mit zufälligen
    > Adressen gepollt.

    Ich glaube nicht, dass es soweit kommt, dass die Smartphones auch bei jeder Verbindung zu bekannten WLANs immer eine zufällige MAC-Adresse verwenden werden. Dagegen dürften die WLAN-Betreiber Sturm laufen, weil somit jede Kontingentierung (z.B. von Datenvolumen) hinfällig wird.

  7. Re: "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: treysis 23.05.19 - 19:47

    LinuxMcBook schrieb:
    --------------------------------------------------------------------------------
    > treysis schrieb:
    > > Ist eh Quatsch. Aber Q wird Android vermutlich bei jeder Verbindung eine
    > > zufällige MAC-Adresse verwenden. Schon seit Oreo wird mit zufälligen
    > > Adressen gepollt.
    >
    > Ich glaube nicht, dass es soweit kommt, dass die Smartphones auch bei jeder
    > Verbindung zu bekannten WLANs immer eine zufällige MAC-Adresse verwenden
    > werden. Dagegen dürften die WLAN-Betreiber Sturm laufen, weil somit jede
    > Kontingentierung (z.B. von Datenvolumen) hinfällig wird.

    Also Einstellen kannst du es bei Pie, sofern der Hersteller das Feature implementiert hat.
    Bei Windows 10 kannst du das relativ einfach aktivieren. Und ja: solange die Authentifizierung über MAC läuft, wird dein Kontingent jedes Mal zurück gesetzt. Hatte letztens das zufällige Vergnügen dies im ICE festzustellen.

    Darf man sich bei denen bedanken, die WLAN zum Tracken zweckentfremdet haben.

    Oder das war alles geplant: dadurch wird keiner mehr WLAN anbieten wollen, weil man die Kontingente umgehen kann. Daraufhin wird jeder mobile Daten nutzen müssen. Und die muss man natürlich beim Anbieter kaufen. Und anonym ist man da erst recht nicht mehr.

  8. Re: "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: hjp 25.05.19 - 23:47

    katze_sonne schrieb:
    --------------------------------------------------------------------------------
    > Was? Das ergibt doch keinen Sinn.

    Doch, natürlich ergibt das Sinn.

    > Ein Salt wird immer einem Nutzer (in diesem Fall: MAC-Adresse?) zugeordnet,

    Nein. Ein Salt ist einfach ein zufällig gewählter String, der mitgehasht wird, damit gleiche Eingangswerte nicht gleiche Hashes ergeben. Bei Passwort-Hashes ist der der dem Benutzer zugeordnet, weil man nicht möchte, dass gleiche Passwörter verschiedener Benutzer trivial erkennbar sind, das Passwort des gleichen Benutzers aber schon. Für andere Zwecke gibt es andere Zuordnungen. Bei BATV z.B. wird das Salt täglich gewechselt.

    [...]
    > Oder wird jeden Tag ein anderer Salt verwendet? Dann wäre ein Nutzer immer
    > nur tagesweise zuordbar.

    Das wäre am sinnvollsten. Man hat dann Traces für jede Fahrt, bzw. im Normalfall sogar Hin- und Rückfahrt. Das ist ausreichend, um z.B. Routenplanung zu betreiben oder Umbauten in den Stationen zu planen. Auch für die Preisgestaltung von Werbeflächen, wie im Artikel erwähnt, reicht es. Aber es gibt keine Möglichkeit, eine Person mehr als 24 h zurückzuverfolgen, also sind die datenschutzrechtlichen Probleme relativ gering.

    > Das einzige, was hier irgendeinen Sinn ergeben würde: Es wird nur der Hash
    > der MAC-Adressen gespeichert. Dann hätte man trackbare Daten ohne die
    > urpsrünglichen MAC-Adressen zu kennen. Aber wo da noch der Salt zu gut sein
    > soll: Ich weiß es nicht.

    Wenn Du nur einen Hash der MAC-Adresse berechnest, ist das trivial zu brute forccen. Da kannst Du Dir den Hash sparen. Mit einem ausreichend langen zufälligen Salt ist brute force unmöglich und der Angreifer muss das Salt herausfinden. Wenn dass regelmäßig gewechselt wird (und alte Salts nirgends gespeichert werden), sind historische Daten sicher anonymisiert.

    > Allgemein ist die Idee bei nem Salt ja eigentlich
    > eine andere: Nicht anonymisieren, sondern Rainbow-Table-Attacken zu
    > verhindern.

    Du denkst zu spezifisch an Passwörter. Hashes haben noch andere Anwendungszwecke.

    (Und Salts für Passwörter wurden auch Jahrzehnte vor Rainbow-Tables erfunden)

  9. Re: "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: katze_sonne 27.05.19 - 00:01

    hjp schrieb:
    --------------------------------------------------------------------------------
    > katze_sonne schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Was? Das ergibt doch keinen Sinn.
    >
    > Doch, natürlich ergibt das Sinn.
    >
    > > Ein Salt wird immer einem Nutzer (in diesem Fall: MAC-Adresse?)
    > zugeordnet,
    >
    > Nein.

    Nein? Was dann?

    > Ein Salt ist einfach ein zufällig gewählter String, der mitgehasht
    > wird, damit gleiche Eingangswerte nicht gleiche Hashes ergeben. Bei
    > Passwort-Hashes ist der der dem Benutzer zugeordnet,

    Aber genau das hab ich doch geschrieben. Und der "Benutzer" / Nutzername ist nach meinem Verständnis hier gleichzusetzen mit der MAC. Oder was?

    > weil man nicht möchte,
    > dass gleiche Passwörter verschiedener Benutzer trivial erkennbar sind, das
    > Passwort des gleichen Benutzers aber schon. Für andere Zwecke gibt es
    > andere Zuordnungen. Bei BATV z.B. wird das Salt täglich gewechselt.

    Korrekt.

    > [...]
    > > Oder wird jeden Tag ein anderer Salt verwendet? Dann wäre ein Nutzer
    > immer
    > > nur tagesweise zuordbar.
    >
    > Das wäre am sinnvollsten. Man hat dann Traces für jede Fahrt, bzw. im
    > Normalfall sogar Hin- und Rückfahrt. Das ist ausreichend, um z.B.
    > Routenplanung zu betreiben oder Umbauten in den Stationen zu planen. Auch
    > für die Preisgestaltung von Werbeflächen, wie im Artikel erwähnt, reicht
    > es. Aber es gibt keine Möglichkeit, eine Person mehr als 24 h
    > zurückzuverfolgen, also sind die datenschutzrechtlichen Probleme relativ
    > gering.

    Sehe ich genauso. Ich hoffe auch, dass das so gedacht ist, aber im Artikel wird das keinesfalls so beschrieben. (und die Briten und Datenschutz sind sowieso immer so eine Sache... wundert mich, dass die überhaupt darauf eingehen)

    > > Das einzige, was hier irgendeinen Sinn ergeben würde: Es wird nur der
    > Hash
    > > der MAC-Adressen gespeichert. Dann hätte man trackbare Daten ohne die
    > > urpsrünglichen MAC-Adressen zu kennen. Aber wo da noch der Salt zu gut
    > sein
    > > soll: Ich weiß es nicht.
    >
    > Wenn Du nur einen Hash der MAC-Adresse berechnest, ist das trivial zu brute
    > forccen. Da kannst Du Dir den Hash sparen. Mit einem ausreichend langen
    > zufälligen Salt ist brute force unmöglich und der Angreifer muss das Salt
    > herausfinden.

    Stimmt, das ist ein gutes Argument. Aber "überzeugend" ist das trotzdem nicht - nur, wenn man davon ausgeht, dass das einem Angreifer das Herausfinden der MAC-Adressen erschwert. Aber hier geht es ja eher um Datenschutz, denn angeblich wären die Nutzer durch den Salt "pseudonymisiert". Hmm. Aber vermutlich wurde genau das damit gemeint. Finde ich trotzdem nicht beruhigend.

    > Wenn dass regelmäßig gewechselt wird (und alte Salts nirgends
    > gespeichert werden), sind historische Daten sicher anonymisiert.

    Wenn. Aber wenn das nicht öffentlich als Sicherheitsmerkmal kommuniziert wird, kann man davon ausgehen, dass die einfachere Variante verwendet wird: Nichts wird gewechselt.

    > > Allgemein ist die Idee bei nem Salt ja eigentlich
    > > eine andere: Nicht anonymisieren, sondern Rainbow-Table-Attacken zu
    > > verhindern.
    >
    > Du denkst zu spezifisch an Passwörter. Hashes haben noch andere
    > Anwendungszwecke.
    >
    > (Und Salts für Passwörter wurden auch Jahrzehnte vor Rainbow-Tables
    > erfunden)

    Klar, aber deswegen ja meine Überlegungen, wo ich falsch liege oder ob die Aussagen im Artikel wirklich nur wenig Sinn ergeben. Inzwischen bin ich sicher, dass letzteres zutrifft.

  10. Re: "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: katze_sonne 27.05.19 - 00:04

    Nullmodem schrieb:
    --------------------------------------------------------------------------------
    > Davon abgesehen hat die MAC-Adresse nur 6 Byte, eine Brut-Force Attacke ist
    > also billigst möglich, im Moment machen die 0815 Bitcoin.Minerhardware
    > 44TH/s, die 48 Bit (281e12) hashes kriegt man also in 281/44/2 = 3.19
    > Sekunden durchprobiert.

    Gibt ja gute Gründe, warum man meistens mehrere Hash-Durchläufe über solche Werte laufen lässt. Bis irgendwann die Rechenzeit groß genug ist. (unterm Strich wäre ein angehängter Salt aber trotzdem sinnvoll, weil dadurch die Anzahl der möglichen Kombinationen, die man Hashen muss stark ansteigt; aber das betrifft ja alles nur, was passiert wenn die Datenbank einem Angreifer in die Finger fällt und hat nichts mit "Pseudonymisierung" zu tun)

  11. Re: "MAC-Adresse mit einem Salt als Zufallskomponente gehasht" <-- Ergibt keinen Sinn!

    Autor: hjp 30.05.19 - 09:10

    katze_sonne schrieb:
    > hjp schrieb:
    > > katze_sonne schrieb:
    > > > Ein Salt wird immer einem Nutzer (in diesem Fall: MAC-Adresse?)
    > > > zugeordnet,
    > >
    > > Nein.
    >
    > Nein? Was dann?
    >
    > > Ein Salt ist einfach ein zufällig gewählter String, der mitgehasht
    > > wird, damit gleiche Eingangswerte nicht gleiche Hashes ergeben. Bei
    > > Passwort-Hashes ist der der dem Benutzer zugeordnet,
    >
    > Aber genau das hab ich doch geschrieben. Und der "Benutzer" / Nutzername
    > ist nach meinem Verständnis hier gleichzusetzen mit der MAC. Oder was?

    Benutzer und MAC wären gleichzusetzen, ja. Aber es ist nicht notwendig
    und auch nicht sinnvoll, das Salt der MAC-Adresse zuzuorden. Möglich
    (und sinnvoll, wie weiter unten ausgeführt) ist es auch, das Salt dem
    Datum zuzuordnen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. BWI GmbH, Köln-Wahn
  2. hubergroup Deutschland GmbH, Kirchheim bei München
  3. BWI GmbH, Meckenheim
  4. BWI GmbH, bundesweit

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 12,99€
  2. (-63%) 16,99€
  3. 69,99€ (Release am 21. Februar 2020, mit Vorbesteller-Preisgarantie)
  4. 3,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Linux-Kernel: Selbst Google ist unfähig, Android zu pflegen
Linux-Kernel
Selbst Google ist unfähig, Android zu pflegen

Bisher gilt Google als positive Ausnahme von der schlechten Update-Politik im Android-Ökosystem. Doch eine aktuelle Sicherheitslücke zeigt, dass auch Google die Updates nicht im Griff hat. Das ist selbst verschuldet und könnte vermieden werden.
Ein IMHO von Sebastian Grüner

  1. Kernel Linux bekommt Unterstützung für USB 4
  2. Kernel Vorschau auf Linux 5.4 bringt viele Security-Funktionen
  3. Linux Lockdown-Patches im Kernel aufgenommen

16K-Videos: 400 MByte für einen Screenshot
16K-Videos
400 MByte für einen Screenshot

Die meisten Spiele können nur 4K, mit Downsampling sind bis zu 16K möglich. Wie das geht, haben wir bereits in einem früheren Artikel erklärt. Jetzt folgt die nächste Stufe: Wie erstellt man Videos in solchen Auflösungen? Hier wird gleich ein ganzer Schwung weiterer Tools und Tricks nötig.
Eine Anleitung von Joachim Otahal

  1. UL 3DMark Feature Test prüft variable Shading-Rate
  2. Nvidia Turing Neuer 3DMark-Benchmark testet DLSS-Kantenglättung

Mädchen und IT: Fehler im System
Mädchen und IT
Fehler im System

Bis zu einem gewissen Alter sind Jungen und Mädchen gleichermaßen an Technik interessiert. Wenn es dann aber um die Berufswahl geht, entscheiden sich immer noch viel mehr junge Männer als Frauen für die IT. Ein wichtiger Grund dafür ist in der Schule zu suchen.
Von Valerie Lux

  1. IT an Schulen Intelligenter Stift zeichnet Handschrift von Schülern auf
  2. 5G Milliardenlücke beim Digitalpakt Schule droht
  3. Medienkompetenz Was, Ihr Kind kann nicht programmieren?

  1. Radikalisierung: Die meisten Menschen leben nicht in einer Blase
    Radikalisierung
    Die meisten Menschen leben nicht in einer Blase

    Dass fast jeder in gefährlichen Filterblasen oder Echokammern lebt, ist ein Mythos, sagt die Kommunikationswissenschaftlerin Merja Mahrt. Radikalisierung findet nicht nur im Internet statt, doch darauf wird meist geschaut.

  2. Mozilla: Firefox 70 zeigt Übersicht zu Tracking-Schutz
    Mozilla
    Firefox 70 zeigt Übersicht zu Tracking-Schutz

    Der Tracking-Schutz des Firefox blockiert sehr viele Elemente, die in der aktuellen Version 70 des Browsers für die Nutzer ausgewertet werden. Der Passwortmanager Lockwise ist nun Teil des Browsers und die Schloss-Symbole für HTTPS werden verändert.

  3. Softbank: Wework fällt von 47 auf 8 Milliarden US-Dollar
    Softbank
    Wework fällt von 47 auf 8 Milliarden US-Dollar

    In einer neuen Vereinbarung erlangt die japanische Softbank die Kontrolle über das Co-Working-Startup Wework. Es fällt dabei erheblich im Wert und entgeht dem drohenden Bankrott.


  1. 19:37

  2. 16:42

  3. 16:00

  4. 15:01

  5. 14:55

  6. 14:53

  7. 14:30

  8. 13:35