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. über Dr. Maier & Partner GmbH Executive Search, Region Stuttgart
  2. Fraunhofer-Institut für Optronik, Systemtechnik und Bildauswertung IOSB, Karlsruhe
  3. ITEOS, Karlsruhe
  4. operational services GmbH & Co. KG, Wolfsburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 2,99€
  2. 26,99€
  3. 48,49€
  4. 32,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Endpoint Security: IT-Sicherheit ist ein Cocktail mit vielen Zutaten
Endpoint Security
IT-Sicherheit ist ein Cocktail mit vielen Zutaten

Tausende Geräte in hundert verschiedenen Modellen mit Dutzenden unterschiedlichen Betriebssystemen. Das ist in großen Unternehmen Alltag und stellt alle, die für die IT-Sicherheit zuständig sind, vor Herausforderungen.
Von Anna Biselli

  1. Datendiebstahl Kundendaten zahlreicher deutscher Firmen offen im Netz
  2. Metro & Dish Tisch-Reservierung auf Google übernehmen
  3. Identitätsdiebstahl SIM-Dieb kommt zehn Jahre in Haft

Projektorkauf: Lumen, ANSI und mehr
Projektorkauf
Lumen, ANSI und mehr

Gerade bei Projektoren werden auf Plattformen verschiedener Onlinehändler kuriose Angaben zur Helligkeit beziehungsweise Leuchtstärke gemacht - sofern diese überhaupt angegeben werden. Wir bringen etwas Licht ins Dunkel und beschäftigen uns mit Einheiten rund um das Thema Helligkeit.
Von Mike Wobker


    Energie: Wo die Wasserstoffqualität getestet wird
    Energie
    Wo die Wasserstoffqualität getestet wird

    Damit eine Brennstoffzelle einwandfrei arbeitet, braucht sie sauberen Wasserstoff. Wie aber lassen sich Verunreinigungen bis auf ein milliardstel Teil erfassen? Am Testfeld Wasserstoff in Duisburg wird das erprobt - und andere Technik für die Wasserstoffwirtschaft.
    Ein Bericht von Werner Pluta

    1. Autos Elektro, Brennstoffzelle oder Diesel?
    2. Energiespeicher Heiße Steine sind effizienter als Brennstoffzellen
    3. Klimaschutz Großbritannien probt für den Kohleausstieg

    1. TLS-Zertifikat: Gesamter Internetverkehr in Kasachstan kann überwacht werden
      TLS-Zertifikat
      Gesamter Internetverkehr in Kasachstan kann überwacht werden

      In Kasachstan müssen Internetnutzer ab sofort ein spezielles TLS-Zertifikat installieren, um verschlüsselte Webseiten aufrufen zu können. Das Zertifikat ermöglicht eine staatliche Überwachung des gesamten Internetverkehrs in dem Land.

    2. Ari 458: Elektro-Lieferwagen aus Leipzig kostet knapp 14.000 Euro
      Ari 458
      Elektro-Lieferwagen aus Leipzig kostet knapp 14.000 Euro

      Ari 458 ist ein kleiner Lieferwagen mit Elektroantrieb, den der Hersteller mit Aufbauten für verschiedene Einsatzzwecke anbietet. Die Ausstattung ist einfach, dafür ist das Auto günstig.

    3. Quake: Tim Willits verlässt id Software
      Quake
      Tim Willits verlässt id Software

      Seit 24 Jahren ist Tim Willits einer der entscheidenden Macher bei id Software, nun kündigt er seinen Rückzug an. Was er künftig vorhat, will der ehemalige Leveldesigner und studierte Computerwissenschaftler erst nach der Quakecon verraten.


    1. 17:52

    2. 15:50

    3. 15:24

    4. 15:01

    5. 14:19

    6. 13:05

    7. 12:01

    8. 11:33