"gehashcodete" IS statt Zahl - Datentyp?

Mahlzeit!

Ich habe gerade eine vage EMail von einem Entwickler bekommen. Dort wurde angekündigt, dass ein gelieferter Wert zukünftig nicht mehr ganzzahlig sondern hashcodiert wird. Montag darf ich mich damit beschäftigen…

  • gibt es dafür Datentypen? (nein, sehe keine, welchen würdet Ihr vorschlagen?)
  • kann ich “einfach” alle Felder in den verschiedenen Tabellen von Zahl auf den neuen Datentyp umwandeln und die neuen Werte einlaufen lassen?
  • Wie wirkt sich dann zukünftig ein Zugriff auf ein solches Feld von der Performance her aus?

Hintergrund: Große Datenmengen, die user_id ist’s, ich werde die neuen Werte “hineinsiechen” lassen, das System ist jetzt schon an seiner Leistungsgrenze…

Irgendwie habe ich ziemliche Bauchschmerzen bei dem Thema…

anton

Woher sollen wir aus der Ferne wissen, welchen Datentyp und vor allem welchen Hash du verwendest bzw. verwenden sollst? Dafür müsstest du mehr Informationen zur eigentlichen Aufgabenstellung herausrücken.
Ich sehe allerdings kein Problem darin, für einen Hash einen passenden Datentyp zu erstellen.


  • kann ich “einfach” alle Felder in den verschiedenen Tabellen von Zahl auf den neuen Datentyp umwandeln und die neuen Werte einlaufen lassen?

Hängt primär vom Hash ab, aber pauschal würde ich sagen: das ist machbar.



  • Wie wirkt sich dann zukünftig ein Zugriff auf ein solches Feld von der Performance her aus?

Again: woher sollen wir das bestimmen können, wenn du nicht mal weißt, was genau verwendet wird? :wink:



Hintergrund: Große Datenmengen, die user_id ist’s, ich werde die neuen Werte “hineinsiechen” lassen, das System ist jetzt schon an seiner Leistungsgrenze…

Dabei könnte ich sicherlich helfen :wink:
Also, die Performance Engstellen wegzubekommen.

Wie gesagt ich habe bisher auch nur eine “Vorwarnung” bekommen… deshalb ist es schwierig genauere Angaben zu machen…

…wenn’s nach mir ginge…

D.h. Deine Empfehlung ist einen eigenen Datentyp zu generieren…okay…

Performance…

Ich wollte ein grobes “Bauchgefühl” von euch haben… Bisher handelt es sich um ein integer Feld, zukünftig halt ein “Standard” Textfeld oder ein selbst definierter Datentyp… das Feld wird häufig direkt in angesprochen, alt:

 ...where id = 0815...

und neu:

...where id = 11AC2345B2

… wird sich die Performance bei einem Zugriff mit neuer id verschlechtern?

anton

nunja - hashs berechnen ist je nach typ des hashs unterschiedlich “teuer” - wenn der hash dann aber in die tabelle geschrieben wird, sollte die performance nicht wesentlich darunter leiden - es ist ja schließlich erstmal egal, woraus die keys bestehen.

allerdings koennte das schreiben des index deutlich langsamer werden, wenn die keys nicht mehr sequenzell erstellt werden sondern sehr streuen.

alles in allem wuerde ich mal nachfragen was man damit eigentlich erreichen will. es gibt nicht viele gruende, warum man hashs als keys verwenden wollen wuerde.

Höchstens marginal, weil du jetzt einen Text vergleichst statt einen Integer.

Du musst nicht mal einen komplett neuen Datentyp schreiben, eine DOMAIN reicht aus.

hashs sind ja erstmal numerisch - er koennte auch die numerische darstellung speichern - vielleicht wollen sie ja auch einen kleinen hash - dann koennte gar integer reichen

wie du sagst - egal wie - das ist marginal

Aaaber:

  • es wird mehr Platz belegt, gilt auch für den Index
  • der Code ist umzuschreiben, es ist nun auf einen String und nicht auf einen INT zu vergleichen, also ’ drumherum

Andreas

Vielen Dank an alle…

Jepp, genau das mache ich jetzt…

@ads: Du meinst das hier? CREATE DOMAIN

liest

anton

Ja, entweder das oder halt ein Datentyp. Beides ist hier wohl möglich.

Info: Es handelt sich um einen SHA-1. Man möchte Systeme trennen und die ID für Auswertezwecke anonymisieren. Es soll also nicht mehr möglich sein mit den IDs im Auswertesystem die ID des Vorsystems ermitteln zu können um ggf. historische Daten mit aktuellen Daten matchen zu können.

Bin begeistert…

anton

Nun ja, das ist aber an und für sich nix schlecht, oder? Bei all den Datenskandalen der letzten Zeit…

Andreas

das ist mit einer wahrscheinlichkeit von 92,7718% unfug (auch bei begrüsenswerten motiven) … es gibt i.d.R. neben den IDs (technische schlüssel) noch natuerliche keys … die ebenfalls sehr wahrscheinlich auch ausgewertet werden wollen / müssen … d.h. man kann auch ohne die IDs die gleichen daten aus dem neuen in dem alten system referenzieren … ok - ich kenne das system nicht - aber ich kenne genug andere um es fuer sehr wahrscheinlich zu halten dass es trotzdem möglich sein wird.

immerhin sollen ja die daten in das andere system transferiert werden, weil man die fragen, die man stellen will noch nicht kennt, sonst koennte man ja auch die fragen, an das bestehende system stellen - und die antworten in das neue system uebertragen - dann gaebe es nix mehr zum referenzieren.

naja - im zweifel halt haufen arbeit fuer die katz - also so als alibi - man hat sich bemueht :slight_smile:

bei dem was die da wollen koennte man genausogut einfach neue IDs bei der migration vergeben … die einfach mit den bestehenden daten nicht uebereinstimmen … das waere effizienter und genauso (un)sicher - nagut - mit dem hash muesste man nicht erst die neu vergebenen IDs nachschauen oder cachen … weil man einfach den SHA auf die alten keys anwenden muss und das ergebnis schreibt …

Was für natürliche Schlüssel meinst Du? Es gibt z.B. ansonsten keine personenbezogenen Daten… wenn der Hascode nicht zurückgerechnet werden kann, kann auch nix mehr schief gehen… :slight_smile:

anton

Hint: man kann Hashes auch noch mal berechnen und dann vergleichen …

Ads meint, wenn Du (Du als Angreifer) bereits IDs hast, und ab nun nur noch Hashes der IDs bekommst, kannst Du Dir von Deinen bis jetzt vorhandenen IDs eine Übersetzungstabelle basteln mit der Du dann (als Angreifer) die nun kommenden Hash-Werte ganz easy zurückrechnen kannst…


Andreas

Ja natürlich, da habt ihr recht - mit genug “krimineller Energie” bekommt man alles geknackt… jetzt muss man herausfinden was der Gesetzgeber dazu sagt, sprich ab welchem Grad gilt es als Datenschutzkonform und bis wohin nicht…

Zusammenfassung: Beide Systeme sind geschützt und entkoppelt.

Egal, danke für eure Hilfe - es sei denn Ihr wollt weiter über Datenschutz diskutieren…

anton

Natürlich lösen wir auch dieses Problem für deine Firma, stellen das dann aber auch in Rechnung.