Die meisten Leute generieren die IDs für eine Community ja, indem sie im PHPMyAdmin ein Feld "id" anlegen, das ein Primary Key ist und auf "auto_increment" gestellt ist. So bekommt dann jeder User eine ID, die immer um eins höher ist als die vorherige.
Nun habe ich einen Blog-Eintrag gelesen, in dem über ein Sicherheitsloch im studiVZ diskutiert wurde. Dort werden verschlüsselte IDs verwendet, damit man nicht durch Hochzählen alle Profile erreichen kann.
Jedoch leiteten diese IDs nur auf die normalen IDs weiter, sodass man die Profile auch noch über die fortlaufende Nummerierung erreichen konnte.
Ich habe mir nun gedacht: Wieso nimmt man nicht direkt als ID einen verschlüsselten Wert statt dem "auto_increment"? Das habe ich jetzt auf meiner Seite mal so gemacht. Drei User, die sich direkt nacheinander registriert haben, haben die folgenden IDs bekommen: 262335433, 683335433, 614335433
Haltet ihr so ein System für sicher? Ist es besser als die ID-Vergabe über auto_increment?
Danke im Voraus für die Antworten!

Also kurzgesagt willst du Zufallszahlen anstelle von vortlaufenden verwenden.

Ausser, dass man so die Userzahl nicht nachvollziehen kann sehe ich da kaum Vorteile. Evtl. wird es schwieriger bzw. dauert viel länger alle Profile automatisch auszulesen.

Das ganze geht doch völlig am Problem vorbei.

Wenn ein Nutzer die Berechtigung hat

meine-domain.de/profile/uid=580

aufzurufen und die 581 nicht aufzurufen, dann muß der Aufruf der 580 erlaubt und der Aufruf auf die 581 abgefangen werden. Völlig egal, ob die Nummern aufeinander aufsteigend oder zufällig sind.

Ein Sicherheitskonzept, das darauf beruht, 'hohe', nicht zu einfach zu erratende Zahlen zu verwenden, ist keines.

Ob der User das Profil überhaupt ansehen darf, wird natürlich auch geprüft. Aber andere Communitys haben doch nicht umsonst solche Zufalls-IDs...
Schließlich könnte man sonst auch genau erkennen, wer sich als erster registriert hat, wer danach usw.

Und?

Tut bei ICQ auch keinem weh.

Genau meine Meinung

Mach dir mit MD5 ID's

Du musst diese ID's aber "salten" sonst kann man mit einer "Rainbow-Table" leicht die MD5 Hashes "erraten"

Und das wird seit Jahren schon so gehandhabt. In vielen Bereichen / Portalen. Auch hier im Ayom.

Das war aber m.W. nach bei StudiVZ gerade nicht der Fall.

Sprich: Eine ID erraten, dann konnte man die entsprechenden Daten sehen.

Bei der Telekom gab es auch mal etwas ähnliches. Da konnten angemeldete Nutzer die Daten anderer Nutzer durch die manuelle Änderung der ID sehen.

Bei vielen Portalen wird ohnehin das Anmeldedatum ausgegeben (was ja bei Foren auch Sinn macht). Damit ist die hochzählende ID kein Informationsleck.

@jAuer:

Das habe ich vor ~ 2 Jahren bei meinem Online-Broker auf der Ausgabeseite zu einer eingegebenen Transaktion ausprobiert - und es hat tatsächlich funktioniert... dh. ich habe fremde Buchungsdaten zusehen bekommen! Nach dem ich denen telefonisch ihr "Problem" vermittelt habe, haben sie es wimre ziemlich schnell abgeschaltet. Aber passieren dürfte das in solchen "Umgebungen" eigentlich nicht.

@sd12:

Dann hast Du statt einem schlanken effizienten Integer-Wert aber einen fetten 32er Char in deinen Tabellen. Als externe ID okay, aber für Verknüpfungen nicht so "schön", oder?

Damit keine fetten Chars in der Tabelle sind, hab ich es auch so gemacht, dass die IDs alle neunstellig sind. Das kann man dann noch als Integer nehmen.
Wie hoch ist denn eigentlich das Risiko einer Kollision in MD5? Ich dachte eigentlich, dass MD5 jedem Wert genau EINEN Hash zuordnet, der dann auch einzigartig ist.

MD5 kann 64^30 verschiedene Kombinationen...

Und das ist verdammt viel.

Trotzdem kann es zu kollisionen führen...

Dann wäre MD5 ein ziemlich geiles (wenn auch nicht sehr performantes...) Kompressionsverfahren, das Dateien beliebiger Größe auf 16 Byte komprimieren kann