Welches Hash Verfahren bei Daten mit wenig Möglichkeiten?

[BeBur]

Wir speichern die Bewertung zu der gehashten Nummer. Wenn ein Nutzer nun die Bewertung einer Nummer abrufen will, gibt dieser die Nummer ein, wir hashen die und erkennen diesen Hash. Denn zuvor wurde bereits eine Bewertung zu deiser Nummer abgegeben. Nun zeigen wir diese Bewertung an.

Die beim Client ausgeführte Hash-Funktion muss dazu möglichst aufwendig sein. Da gibt es etablierte Verfahren, die das Hashen beliebig aufwendig machen. KeePass2 verwendet z.B. die Argon2 Familie. Bin aber nicht sicher, ob das realisierbar ist. Denn das Hashing muss aufwendig genug sein, dass mit dedizierter Hardware ein komplettes durchprobieren nicht praktikabel ist aber gleichzeitig einfach genug sein, dass das innerhalb weniger Sekunden im Browser eines Nutzers durchgeführt werden kann.

Dazu eine generelle Frage: Wieso ist es überhaupt so wichtig, dass Bruteforcing nicht möglich ist? Wenn jemand die Datenbank raus trägt und veröffentlicht, wen oder was schützt dieser Aufwand dann? Jeder kann doch jederzeit den Datensatz zu jeder einzelnen Nummer abrufen. Nur eben nicht alle, sondern jede einzeln.

 

[marvin.seb]

Was ich nicht verstehe: was hält den Angreifer ab, deine Webseite mit allen möglichen Telefonnummern aufzurufen?

Guter Einwand. Aber das lassen wir nun mal außen vor. Das ist im tatsächlichen Szenario kein Problem, aber bei dem Telefonnummernbeispiel ist der Einwand natürlich berechtigt. Allerdings soll das gar nicht zum Thema gemacht werden.

Ergänzung (12. Oktober 2023)

Denn das Hashing muss aufwendig genug sein, dass mit dedizierter Hardware ein komplettes durchprobieren nicht praktikabel ist aber gleichzeitig einfach genug sein, dass das innerhalb weniger Sekunden im Browser eines Nutzers durchgeführt werden kann.

Genau. Das ist es nämlich. Notfalls greife ich auch auf Argon2 beim Client zurück. Aber optimal ist es jetzt nicht und ich glaube ein paar Millionen Argon2 Hashes lassen sich auch schnell generieren.

Dazu eine generelle Frage: Wieso ist es überhaupt so wichtig, dass Bruteforcing nicht möglich ist?

Gleicher Gedankengang wie der andere User. Es soll einfach nicht möglich sein. In der tatsächlichen Variante die ich umsetzen will, ist es etwas anders. Aber das ist hier nicht relevant. Ich möchte einfach nicht, dass ich die Telefonnummern entschlüsseln kann.

Falls ihr dennoch eine erfunde Antwort benötigt: Der Nutzer wird auf der Webseite ja limitiert. Captcha, ... Da kann der nicht mal eben 20. Mio durchlaufen lassen.

 

[tollertyp]

Und damit jemand den ganzen Aufwand betreibt, muss es ja um etwas von Wert gehen. Den Wert sehe ich hier noch nicht so ganz.

Und dann habe ich noch das Gefühl, dass wir hier an der Nase herumgeführt werden, denn manchmal sprichst du davon, dass du eine konkrete Seite hättest, dann wieder von "nur ein Beispiel".

Wir wissen nicht, wie gut dein Beispiel deine Situation tatsächlich abstrahiert. Was für das Beisipiel gelten mag, muss nicht zwingend auf dein Szenario anwendbar sein.

Wie ist die Architektur? Ist das Captcha nur Client-seitig? Also stellt das Captcha sicher, dass das Backend keine Anfragen ohne Captcha beantwortet?

 

[marvin.seb]

Hier hatte ich ja alles gut erklärt: https://www.computerbase.de/forum/t...g-moeglichkeiten.2164372/page-2#post-28695667

Das Beispiel erklärt doch alles ziemlich gut. Ich frage mich nun nur, ob es technisch möglich ist oder nicht.

Einfach eine ganz normale Webseite, auf der man Nummern bewerten kann, welche aber nicht im Klartext in der Datenbank landen sollen und auch nicht via Rainbow Table entschlüsselt werden können, trotdzessen, dass es ja nur wenige Millionen Möglichkeiten gibt.

Und doch, das Beispiel entspricht so gut wie meinem realen Szanario. Aber das wäre dann ja mein Problem, wenn ich ein falsches Beispiel präsentiere. Und an der Nase führe ich doch niemanden herum? Wie kommst du darauf? Es ist doch alles nur ein Beispiel mit den Telefonnummern.

Ergänzung (12. Oktober 2023)

Wie ist die Architektur? Ist das Captcha nur Client-seitig? Also stellt das Captcha sicher, dass das Backend keine Anfragen ohne Captcha beantwortet?

Ich hatte doch eben gesagt, dass wir diesen Teil bitten außen vor lassen. Meine Frage ist nur, ob ich die Nummern so speichern kann, dass ich die wenn ich die Datenbank habe nicht entschlüsseln kann.

 

[tollertyp]

Etwas vereinfacht darzustellen und sich ein anderes Beispiel auszudenken sind halt unterschiedliche Dinge.
Ich bin komplett verwirrt und weiß nicht mal, ob es wirklich um Telefonnummern geht, gleichzeitig wird aber immer der Wertebereich von Telefonnummern genannt. Aber dann wieder "Beispiel mit den Telefonnummern".

Ich glaube niemandem hier ist klar, was noch Beispiel ist, was Vereinfachung und was real. Dann sollen noch andere Punkte außen vor gelassen werden, die aber aus "Sinnhaftigkeitssicht" relevant sind.

Ich bin auf jeden Fall raus.

 

[marvin.seb]

Jetzt übertreiben wir aber mal nicht. Sollten nun alle so schwer verwirrt sein, dann bitte alles vergessen und nur diesen Beitrag lesen: https://www.computerbase.de/forum/t...g-moeglichkeiten.2164372/page-2#post-28695667

Wie kann ich die Telefonnummern speichern, dass ich diese selbst als Betreiber nicht entschlüsseln kann? Es kann auch sein, dass wir hier einfach an die Grenze stoßen was technisch möglich ist. Zumindest stoßt das Szenario an meine Grenzen.

 

[BeBur]

Notfalls greife ich auch auf Argon2 beim Client zurück. Aber optimal ist es jetzt nicht und ich glaube ein paar Millionen Argon2 Hashes lassen sich auch schnell generieren.

Argon2 kann man doch beliebig einstellen. Du musst dich vielmehr fragen, ob das was du versuchst prinzipbedingt überhaupt möglich ist. 20 Millionen Sekunden sind 0,6 Jahre. Wenn ein normaler Desktop Computer z.B. 10 Sekunden braucht zum Anzeigen eines Ergebnisses, dann 6 Jahre um alle Kombiniationen auszuprobieren. Und ein Angreifer, der eure Datenbank raus trägt, der wird ja nicht einen handelsüblichen Desktop Computer verwenden, sondern bessere Hardware zur Verfügung haben.

 

[marvin.seb]

Also Argon2 kann ich so einstellen, dass ich mit einer bestimmten Hardware mindestens 10 Sekunden pro Hash benötige? Um dann aber auch gegen starke Computer abgesichert zu sein, müsste man Argon2 ja so stark anpassen, dass dies evtl. zu viel für das Endgerät der Nutzer ist. Oder auch für meinen Server, wenn ich das Hashen erst auf dem Server stattfinden lasse. Aber eigentlich war mir das ja bereits bewusst, dass dies aufgrund der Performance nicht wirklich möglich ist. Daher hatte ich nach einer anderen Möglichkeit als Argon2 gesucht, welches ich einfach hochschraube.

Eine Telefonnummer besteht ja aus zwei Teilen. Vorwahl und die eigentliche Nummer. Eventuell kann ich das nutzen, um mein Problem zu lösen? Ich würde dann erst die Vorwahl hashen, dann die Nummer und dann nochmal beides zusammen. Aber wenn man erstmal bei SHA256 bleibt, macht dies wohl kaum einen Unterschied und die Rainbow Table ist dann auch schnell fertiggestellt, was?

Falls sich hier ein wirklicher Kryptoexperte aufhalten sollte, kann er sich auch gerne via PN melden. Würde definitiv auch für eine Lösung zahlen wollen.

 

[naTmeg]

Benötigt wird nun also eine Möglichkeit, wie ich Bewertungen zu Telefonummern hinzufügen kann und diese auch anzeigen kann, ohne die Telefonnummer tatsächlich im Klartext zu besitzen.

Das ist ein Widerspruch in sich. Wenn du Nummern anzeigen willst, musst du sie auch speichern und entschlüsseln können. Z.B. "Liste der Nummern mit besten Bewertungen"

Du müsstest sowieso Client-seitig per Javascript hashen, da ja ein potentieller Angreifer (auch du) mit Zugang zum Server die im Klartext gesendeten Nummern abfangen könnte.

Bleibt also nur die Möglichkeit eine zeitaufwendige Hashfunktion anzuwenden, um das erstellen einer Rainbow-Tabelle zu erschweren.

Würde das speichern von Nummer im Klartext aber als eher undramatisch ansehen, schließlich gibt es auch Telefonbücher wo sogar noch Namen dabeistehen.

 

[Evil E-Lex]

Was ist ein "starker Computer"? Wie viele Randbedingungen willst du hier noch einführen?

Falls sich hier ein wirklicher Kryptoexperte aufhalten sollte, kann er sich auch gerne via PN melden. Würde definitiv auch für eine Lösung zahlen wollen.

So funktioniert ein Forum nicht.

 

[marvin.seb]

Das ist ein Widerspruch in sich. Wenn du Nummern anzeigen willst, musst du sie auch speichern und entschlüsseln können. Z.B. "Liste der Nummern mit besten Bewertungen"

Nein. Die Nummer bekomme ich immer im Klartext von dem Nutzer während der Eingabe und kann dann auf der Webseite zusammen mit den Bewertungen zu dem Hash angezeigt werden. Das ist kein Problem.

Was ist ein "starker Computer"? Wie viele Randbedingungen willst du hier noch einführen?

Naja, das sind Bedingungen die uns alle betreffen. Ich kann doch nicht nur mit einem Raspberry Pi kalkulieren. Und dein Einwand betrifft aber ein viel größeres Thema, welches man gesonders besprechen kann. Das hatte ich ja zuvor bereits angerissen. Mit welchen Szenarien muss man rechnen und sich davor schützen? Ab wann ist es absurd und erfordert keinen Schutz mehr?

 

[Evil E-Lex]

Mit welchen Szenarien muss man rechnen und sich davor schützen? Ab wann ist es absurd und erfordert keinen Schutz mehr?

Das ist eine Abschätzung die du treffen musst. Post-Quantum-Crypto ist für deine private Bratwurst-Datenbank unnötig, für eine Datenbank mit Gesundheitsdaten mag das anders aussehen.

Wenn du mit den Telefonnummerndatenbanken die Seiten meinst, wo man die Reputation von Rufnummern abfragen kann, die einen angerufen haben, sehe ich gar kein Problem darin, die Rufnummern im Klartext zu speichern. Schließlich dürfte es sich bei diesen Nummern fast ausnahmslos um Scammer oder Firmen handeln. Da erscheint mir die Rufnummer nicht schützenswert.

 

[Funfare]

Der Salt wird dich nicht wirklich weiter bringen, da du dem den Client bereitstellen musst (sonst kann der Client ja nicht den selben Hash erstellen). Alternativ, wenn du das den Server berechnen lässt, ist es das gleiche Problem. Dein Server muss wissen, welchen Salt er verwenden muss. Also hast du entweder einen globalen Salt oder z.B. pro Vorwahl einen, aber das ist in Kombination mit der Anzahl der nutzbaren Vorwahlen auch nur ein minimaler Zeitverlust beim erstellen der Rainbow-Table.

Dein Problem ist, dass du dich vor dir selber schützen möchtest. Das ist in einer Umgebung, die öffentliche Daten bereitstellt äußert schwierig. Die Daten sollen gleichzeitig gut geschützt sein, aber von jedem aufrufbar. Das lässt sich nicht wirklich kombinieren, da musst du den Kompromiss finden der für dich akzeptabel ist.

mMn bleibt dir nur übrig, eine lang dauernde Hash-Funktion zu benutzen. Aber auch das wird dich nur begrenzt weiterbringen.

Bleiben wir bei den Telefonnummern, die können maximal 15 stellen lang sein, in der Praxis sind die natürlich nicht so lang, es gibt auch kürzere, daher bleibe ich einfach mal bei den 20 mio als Beispiel.

Wenn du eine Hash-Funktion nutzt, die 1 Sekunde dauert, wärst du bei einem einzelnen Prozess in einem halben Jahr fertig. Parallelisiert man das ganze etwas schlau, sind bestimmt auch wenige Tage/Stunden möglich. Die Anzahl der Kombinationen ist einfach viel zu gering um Bruteforce von intern (also wenn man die Daten vorliegen hat) zu verhindern. Du kannst das ganze auch auf 10 Sekunden erhöhen, aber auch da ist der Aufwand technisch locker machbar das zu knacken (und deine Website würde niemand nutzen wenn das Ergebnis erst nach 10+ Sekunden sichtbar ist)

Ein Salt lebt ja davon, dass er zufällig generiert ist, genau das kannst du aber nicht machen, weil alle auf die gleichen Daten zugreifen müssen. Selbst wenn du also einen individuellen Salt pro Nummer verwendest , z.B. die Telefonnummer oder einen MD5/SHA1-512 Hash von der Telefonnummer, wäre das kein Sicherheitsgewinn da sich das auch alles viel zu schnell berechnen lässt.

Ich kann nicht erkennen, wie sich bei 20 mio Kombinationsmöglichkeiten auch nur ansatzweise ein Schutz etablieren lassen könnte. Wer da die Datenbank hat, wird zwangsläufig an die Daten kommen. Das wäre alles nur ein Pseudoschutz bzw Obfuscating.

Daher würde ich dir eher Raten, die Daten im Klartext abzuspeichern (macht dir das Leben so viel einfacher und dann lässt sich auch viel besser damit arbeiten, z.B. gleiche Telefonnummer mit nur verschiedenen Durchwahlen, Auflistung der akut gemeldeten Telefonnummer etc.), sicher bekommst du es nicht hin.
Zusätzlich musst du dich entsprechend von Angriffen von außen schützen, ein Rate-Limit für die Abfragen einbauen (maximal 10 pro Minute oder so), damit man nicht einfach alle Daten abgreift. Hat aber jemand deine DB irgendwie geleaked, lassen sich die Daten aber so oder so recht einfach in Klartext zurückverwandeln

 

[naTmeg]

Nein. Die Nummer bekomme ich immer im Klartext von dem Nutzer während der Eingabe und kann dann auf der Webseite zusammen mit den Bewertungen zu dem Hash angezeigt werden. Das ist kein Problem.

Für was dann um Verschlüsselung bemühen, wenn die Nummern schon von Haus aus kompromittiert sind? Braucht ja nur jemand die Server POST-Daten mitprotokollieren...

Würde mir den ganzen Aufwand sparen und im Klartext speichern, weil jede Art der "Verschlüsselung", so wie du dir das vorstellst, leicht auszuhebeln ist.

 

[Piktogramm]

Der Schutz vor sich selbst bzw. Mitarbeitenden, die auf dem IT-System eskalierte Rechte haben ist recht sinnlos. Wer eskalierte Rechte hat, kann im Zweifelsfall auch schlicht die Programmlogik modifizieren, die der Server bzw. die Clients ausführen und nahezu beliebig Daten ausleiten.

Das die Clients, beim gewünschtem Schutz gegen Interne, Telefonnummern im Klartext übermitteln ist Käse. Es wäre sinnvoller den Klients zwar die Klartexteingabe zu ermöglichen, diese Eingabe jedoch vom Absenden direkt zu hashen, sodass nur die Hashes beim Server abgefragt werden. Das hat auch den enormen Vorteil, dass aufwendigeres Hashing keine Last beim Server bedingt. Gerade bei Hashverfahren mit hohem Bedarf an Speicher und Laufzeit wird ja jede Nutzung zum DDoS.

Das was ich hier im Thread teils zu Hashing und Salts gelesen habe hat mein Beißholz sehr belastet. Hausaufgabe für Alle: Wikipedia zu Hashing, Salting durchlesen!

Ansonsten ist das Konzept zum Schutz gegen Interne etwas absurd. Wenn Clients den größten Teil der Datenbank wohl sowieso abfragen können. 20.000.000 Mio Abfragen über HTTP sind ohne Ratelimit in unter einem Tag erledigt. Selbst mit einem Limit von 10 Requests in der Minute kann der Datenbestand in 3,8 Jahren abgefragt werden. Oder aber in einem Bruchteil der Zeit indem man sich ein paar billige Cloudinstanzen oder für einen einzelnen Server eine /56 v6 IP-Range klickt.

Ein gescheit internes Sicherheitskonzept, sähe auch generell anders aus. Das Problem ist ja, dass du Leute mit eskalierten Rechten auf den IT-Systemen brauchst, aber denen nicht vertrauen willst/kannst. Wenn du das soziale Mistrauen durch Technologie erschlagen willst, dann braucht es ein System, welches keinem einzelnen Internen erlaubt die Rechte auf dem IT-System derart zu eskalieren, dass Zugriff auf Logik der Anwendung, noch Datenbank besteht. Die sollte also nur immer mit einem Zweiten, Internen möglich sein. Wobei sie beide Personen möglichst nicht erkennen können sollten. Wenn Klaus und Peter sich kontrollieren sollen, ein Büro teilen und Abends zusammen saufen gehen, ist die Kontrollfunktion halt weg.
Und Extrapunkte gibt es, wenn zwar die Rechte nur unter Kontrolle eskaliert werden, aber nie soweit, dass damit Logs modifiziert werden können.

Ein ganz anderer Punkt, wenn du Telefonnummern sammelst und Bewertungen zugeordnet werden sollen. Wenn die Nutzenden Telefonnummern neu einreichen können, dann wird was immer du baust tendenziell ganz schnell zu einer tickenden, rechtlichen Zeitbombe. Denn egal wie du die Telefonnummern pseudonymisierst, du sammelst ein zuordenbares, persönliches Datum natürlicher Personen und reicherst es mit weiteren Daten (Bewertungen) an. Selbst für reine interne Zwecke in einer Firma wird das ganz fix extrem haarig.

 

[AW4]

Ich bezweifle, dass du hier glücklich werden wirst.

Ein "Schutz vor dir selbst" wird weder Verschlüsselung, noch jedes Hashing oder jedwede Form von Anonymisierung oder Pseudonymisierung gewährleisten können.
Im Kontext eines "Accounts" ist es möglich, über individuelle (im besten Fall einzigartige, schwer zu erratende und schwer zu brute-forcende) Geheimisse Schutz vor Einblick und Manipulation zu gewährleisten.

Diesen Kontext hast du hier aber nicht.
Das Einzige, was du hier theoretisch tun kannst, ist Zugriffskontrolle, in verschieden stark eskalierten Paranoiastufen mit entsprechend hohem Investment an Zeit, Geld und Personal.
Allerdings kann man da, bezogen auf deine Telefonnummern, sehr sehr schnell übertreiben.
Wir reden hier effektiv über das Sammeln von Informationen in einer mehr oder minder öffentlichen Datenbank, deren Inhalte du bereitwillig, mit jedem der fragt, teilen wollen wirst.
Das ist ja wohl auch das Geschäftsmodell dahinter.

Aus Datenschutzsicht wäre natürlich das Beste, die Daten erst gar nicht zu sammeln und alle anderen am Sammeln der Daten zu hindern, zu stören und deren Löschung zu bewirken.
Aber das ist wohl hier auch keine Option, bzw. auch keine sinnvolle Antwort.

Der Grad an Sensibilität der Daten, zusammen mit der Öffentlichmachung selbiger, beißt sich stark mit Datenschutzgedanken.
Ein adäquater Schutz vor dir selbst, sollte durch einfache und übliche Einschränkungen und Kontrollen der beteiligten Systeme und Personen gewährleistet sein.
Wirksamen Datenschutz würdest du hier nur dann erreichen, wenn du Informationen und Kommentare über die Telefonnummern moderierst, kuratierst und nur aufbereitet nach außen gibst.
Ich schätze aber, dass der entsprechende Aufwand durch das Potential des Geschäftsmodells nicht gestützt werden könnte.

 

[ayngush]

Leute... einen Hash kann man nicht entschlüsseln, weil er nicht verschlüsselt ist. Eine Rainbow Table führt demzufolge auch nur zu Kollisionen und entschlüsselt nichts.

 

[Ranayna]

Die ganze Kryptographie und Salt und Pepper Geschichte hilft hier doch ueberhaupt garnichts.
Die sind dafuer da, das wenn der Angreifer die eigendliche Datenbank mopst, und kann in grossen Firmen auch vor internen Mitarbeitern schuetzen die nur Zugriff auf bestimmte Teile haben.

Wenn du aber Zugriff auf alles, also Datenbank und Code, hast, kannst du das auch umgehen.
Ja, wie @ayngush schreibst hat man bei einem Hash keinen "Zugriff" auf die originalen Daten.
Aber das konkrete Beispiel sind hier ja Telefonnummern, also Integer bis zu 15 Stellen (ggf. mit einem vorgestelltem +)
Alle Kollisionen die keinen Integer ergeben kannst du also direkt wegwerfen.

Aber mal ganz abgesehen vom technischen Aspekt kommt mir das ganze extrem erbsenzaehlerisch vor. Du willst dem Buchstaben des Gesetzes entsprechen, aber nicht dem Sinn.
Glaubst du ein potenziell Betroffener, ueber dessen Telefonnummer auf deiner Bewertungsseite irgendwelcher rufschaedigender Quatsch steht, laesst sich von deinem Argument das du die Nummern ja nicht speichern wuerdest abspeisen?

 

[ayngush]

Dazu muss man aber auch wissen, dass die gesuchten Daten nur auf 15 Stellen Integer kollidieren sollen und auf nichts anderes.
Das weiß man natürlich, wenn das Attribut "Telefonnummer" heißt.
Das weiß man nicht mehr unbedingt, wenn das Attribut "rate_me_hash_value" heißt.
Aus dem Kontext der Applikation wird man es jedoch so oder so herstellen können.
Dazu müsste das beim Leak jedoch auch leaken oder bekannt sein. Ist es aber meistens.

Ich sehe, wenn es tatsächlich um so ein Telefonnummern-Bewertungsportal geht, jedoch überhaupt keine Notwendigkeit die Telefonnummern in der Datenbank zu "verschleiert" oder zu "pseudonymisieren", da man dazu ja gar keine Personenbezogenen Merkmale speichern sollte.
Eine Telefonnummer, die für sich alleine steht, ist kein personenbezogenes Datum, das wird sie erst, wenn man auch den Inhabernamen dazu speichert. Ähnlich wie die IP-Adresse. Ja, da wird via Datenschutz auch ein Zirkus drüber veranstaltet aber in Wirklichkeit kann damit niemand etwas anfangen (außer Strafverfolger).

Aber wenn ich mir eine Datenbank mit allen IPv4 Adressen erzeuge, wie sie ja auch im Web existieren, dann muss ich die IP an sich nicht besonders schützen. Denn erst im Kontext Besucher <-> IP <-> Zeitstempel wird daraus ein personenbezoges Datum, davor ist es einfach nur eine IP-Adresse, bestehend aus vier Oktetts.

BZW. Niemand verstößt gegen irgendwas, wenn ich hier folgendes hinschreibe: 252.14.87.137 (alles ausgedacht, keine Ahnung, wo man da landet )

Edit: Bin mittlerweile auch zu blöd für richtige IPs

 

[Piktogramm]

@ayngush
IPs werden für sich nicht als persönliches Datum betrachtet, weil sie in der Regel kurzfristig durchwechseln. Bei Telefonnummern besteht die Bindung zu Personen wesentlich länger, zudem ist der Zweck von Telefonnummern (insbesondere Mobil) ja die persönliche Erreichbarkeit herzustellen. Telefonnummern sind also von der Anlage her bereits IDs, die u.a. ja auch von Diensten wie Whatsapp zur eindeutigen Zuordnung genutzt werden. Das ist arg "sportlich" Telefonnummern nicht als persönliches Datum anzusehen (Imho).

dazu:

1. „personenbezogene Daten“ alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (im Folgenden „betroffene Person“) beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung oder zu einem oder mehreren besonderen Merkmalen, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind, identifiziert werden kann;

https://dsgvo-gesetz.de/art-4-dsgvo/ ; Hervorhebung durch mich

Ergänzung (13. Oktober 2023)

Edit: Bin mittlerweile auch zu blöd für richtige IPs

"Richtige IPs" sehen so aus: fe80::2 diese 32bit Krücke kann Niemand mehr wollen.