Primärschlüssel für USER-ID per SQL ändern

    Hallo,


    mein Wunsch ist folgender: Ich werde die nächsten Tage eine Reihe Karteileichen, also User, aus der Nutzerverwaltung entfernen, d.h. (per Batch) ihre Profile löschen. Aber einige bleiben.

    Gleichzeitig möchte ich die Sicherheit erhöhen, indem ich für die verbliebenen Nutzer neue USER-ID's (Primärschlüssel) erstelle. Meine Idealvorstellung wäre es, wenn die Nummern wirklich "random ID's" wären. Denn das sind sie derzeit nicht, ich zitiere firstlady


    Zitat

    Es ist eine Schutzmaßnahme, dass der erste angelegte user immer eine zufällig gewählte Nummer hat.
    User-ID


    "der erste" - die folgenden Nrn. aber nicht, die folgen dem +1-Schema.

    Was ich erreichen möchte, ist: Ich möchte, dass der Primary key nach einer SQL-Formel so durchgeschüttelt wird, dass ALLE Nummern wirklich "random" (zufällig) generiert werden, also nach dem Prinzip "Lottozahlen", im Beispiel: Auf eine ID 257 folgt eine 911, darauf eine 468 usw.
    So erreiche ich, dass eine Nachbar-ID nicht "erraten" werden kann, also, falls sich doch einmal ein Nutzer mit nicht ganz koscheren Absichten registriert, hier "no way" ist (in den Datenschutzbestimmungen ist mit der Registrierungs-E-Mail darauf hinzuweisen, dass die einem Nutzer zugewiesene ID nicht "seine" ist, sondern jederzeit vom Super User geändert werden kann).
    Was ich nun im Web dazu fand, ist nicht wirklich weiterführend. Was ich hier lese, ist, dass auto_increment immer nur +1 versteht:
    https://dev.mysql.com/doc/mysq…ample-auto-increment.html

    Ist aber ein alter Thread; gibt es inzwischen komplexere Formeln?
    Natürlich könnte man jetzt einen Rundumschlag machen, die Spalte mit dem Primary keys löschen und mit ALTER TABLE neu generieren. Aber was ist dann mit den relativ abhängigen ID's, die z.B. in der Tabelle {Präfix]_contact_details die Relation herstellen? Die müsste ich vermutlich von Hand umschreiben, ein nicht praktikables Unternehmen.
    Gibt es vielleicht ein Plugin für diesen Zweck? Ich wüsste nicht mal, wonach ich fragen sollte. "rebuild primary key"?
    Danke schon mal für Antworten.

    Zitat von aspera

    ein nicht praktikables Unternehmen

    Dein ganzer Plan ist nicht praktikabel, da es diverse Relationen gibt (weitaus wichtigere als Kontakt-Details) und es jeder Erweiterung frei steht, eigene Relationen auf die user_id in seinem System zu verwenden, die nun wiederum an beliebig benannten Orten gespeichert sein könnten. Vielleicht in separater Spalte, vielleicht innerhalb eines Parameter-JSON-Blocks, vielleicht ....


    Unter'm Strich machst du das System unsicherer. Weil bei unbedachtem Rumfuhrwerken, es auch denkbar sein kann, dass User plötzlich Zugriff auf Daten anderer bekommen oder deren Rechte. Wäre dein Plan in irgendeiner Art und Weise tatsächlich ein sicherheitsförderlicher hätten sich schon andere in diversen Systemen Gedanken darüber gemacht ;)


    Bist auch (laut meinen Erinnerungen) nicht der erste, der mit so einer Idee bzgl. Joomla aufwartet. Die Integer-ID ist ein reiner Verwaltungsakt sozusagen.


    Weiters arbeiten solche Systeme bewusst so, dass NIEMALS eine id doppelt sein kann. Selbst, wenn sie gelöscht wurde, wird sie niemals mehr auftauchen. Dein Plan müsste also berücksichtigen, dass bei der Zufallssuche auch keine ids mehr verwendet werden, die es vorher schon mal gab.

    Zitat von aspera

    (in den Datenschutzbestimmungen ist mit der Registrierungs-E-Mail darauf hinzuweisen, dass die einem Nutzer zugewiesene ID nicht "seine" ist, sondern jederzeit vom Super User geändert werden kann

    Das musst jetzt noch mal genauer erklären. Was hat das denn mit der DSE zu tun und inwiefern hat ein Nutzer denn ein Recht auf "seine eigene ID".


    Und wo siehst du denn die Gefahr, dass jemand eine Folge-ID "errät"? Da Knatter ich als Hacker eben einen ganzen Block von IDs in Millisekunden durch und komm auch so ans Ziel. Dafür muss das System aber eine Sicherheitslücke haben, damit mir das überhaupt was bringt.

    Hm, ja, scheint mir auch so. Es sollte aber mal als Anregung aufbewahrt werden. Habe hier noch etwas gefunden, was jedenfalls von gleicher Problemstellung ausgeht:

    https://stackoverflow.com/ques…-for-primary-key-in-mysql


    Der Threadstarter gibt als Motiv wie ich an: "want them to be random. A user should not be able to guess other users Id"

    ... verknüpft das aber mit UUID, was ich nicht brauche.


    Eine passende Antwort sehe ich in dem Thread auch nicht.

    Was man noch machen kann, ist, nach jeder Registrierung eine Pseudo-Registrierung zwischenzuschalten, die man dann auch wieder löschen kann, so dass der Primary key dem Schema folgt: 1 - 3 - 5 -7. So viele Registrierungen haben wir derzeit noch nicht, wäre also noch ein vertretbarer Aufwand.

    Bin gerade mit unseren Fake-Accounts - also nur als Nutzergruppe "registriert" da reingegangen, sieht nicht so aus, als ob jemand von da überhaupt "seine" ID sehen kann.

    In der Nutzergruppe "Manager" aber schon.

    Zitat von aspera

    Nutzergruppe "registriert" da reingegangen, sieht nicht so aus, als ob jemand von da überhaupt "seine" ID sehen kann.

    Jeder kann sich in Joomla mit ganz bisschen KnowHow ohne Gehacke seine eigene ID rausklamüsern. Trotzdem sehe ich kein Sicherheitsproblem, wenn er damit die vorige oder nächste in Erfahrung bringt, die ja sowieso auch schon längst gelöscht sein könnte. Wenn das System eine Sicherheitslücke hat, bei der mittels ID Daten erschlichen werden können, ist es wie gesagt technisch gar kein Problem nahezu beliebig viele IDs durchzuprobieren, egal, ob es sie nun gibt oder nicht, bis man eine passende findet, die tatsächlich was hergibt.

    Man macht ja eigentlich nur user zu Managern die vertrauenswürdig sind.

    Aber ich warne dich, in einer bestehenden Datenbank im SQL an Primärschlüsseln herumzumachen. Egal bei welchen. Die Gründe hat Re:Later schon geschrieben. Es gibt zahllose Verknüpfungen, die du wahrscheinlich nicht kennst. Du öffnest damit eher eine Sicherheitslücke als dass du was sicherst.

    Danke auch dir für die Antwort, Christiane. Vor allem die Abhängigkeiten vom Primary leuchten mit ein.
    Was "Manager" betrifft: Im Moment haben wir keinen, nur Hauptadministratoren und einige Fakeaccounts, um zu prüfen, was ein Teilnehmer einer Nutzergruppe sieht und beeinflussen kann.

    Ich stelle den Thread jetzt auf erledigt.