UserID nicht fortlaufend - wie dann? Hashes?

[Forumsgast]

Hallo,

man soll ja UserIDs nicht fortlaufend vergeben sondern Hashes dafür verwenden...

Wie generiert man dann so einen Hash, damit er auch 100% eindeutig ist?

z.B. aus Usernamen und Anmeldedatum?

Kann man auch 16-stellige, eindeutige Hashes erstellen?

Bei StudiVZ wäre das z.B. 9fdf65a886657b66

[Forumsgast]

hashes sind nicht eindeutig, nur relativ unwahrscheinlich dass sie doppelt auftreten. bei 16 zeichen wird natürlich schon wahrcheinlicher....

[Forumsgast]

N'Abend ...

Hast du dir dieses mal angesehen ...?

[Forumsgast]

Hallo,

ja die Funktion kenn ich...

Nur ist die Frage, warum doch nicht fortlaufende numerische IDs?

Ich mein die Datenbank wird dadurch nur unnötig aufgebläht... statt schlanken INT-Feldern müssen überall dann 32-stellige VARCHARs hin

[Forumsgast]

Nimmste ne Datenbank und als id ne PRIMARY KEY und AUTO_INCREMENT

Eindeutige ID, fortlaufend, erstellt die Datenbank selbstständig.

Was will man mehr?

[Forumsgast]

Grins... das habe ich doch schon!

Es geht mehr darum, dass die Seite nicht zu Statistikzwecken spiderbar ist...

Wenn es so aufgebaut ist ...

http://www.domain.de/profil.php?userid=[XXXXX]

... dann kann man mittels einfachen Script alle IDs einlesen und eine Statistik erstellen.

War ja bei StudiVZ am Anfang auch so...

[Forumsgast]

Glaube habs falsch verstanden, deshalb alten Beitrag entfernt ^^

In der Form kannst du auch die fortlaufende User-ID verwenden ^^ Was spricht dagegen?

"ID" (wie der Name schon sagt "identifikation") ist eindeutig und einmalig. Eine zweite ID is keine ID mehr, höchstens ein Alias.

[Forumsgast]

Hier wird ein weinig aneinander vorbei geschrieben/geredet ...

Was spricht dagegen?

... dass die Seite nicht zu Statistikzwecken spiderbar ist...

BTW @ Exakt: wird dich wenig trösten, aber md5() kann auch 16Byte-Hashes erzeugen.

[Forumsgast]

wenn ich mich recht entsinne gibts im php eine funktion mit der man in 2 richtungen arbeiten kann also codieren und eindeutig dekodieren. warum codierst du die id nicht einfach in einen hash und beim request dekodierst du deine userid einfach wieder.

oder du schreibst dir einen eigenen coder den kann man dann nicht so schnell knacken.
geht aber halt zu lasten der rechenzeit. und mal ehrlich einen hash in der db speichern ist doch nciht schlimm und auch nicht viel oder oberrierst du mit über 1.000.000 usern?

[Forumsgast]

schreibst dir einen eigenen coder

Wenn das so einfach wäre...! Das solltest Du keinesfalls machen, weil es unsicher ist und es nicht umsonst zertifizierte und berühmte/bekannte Verschlüsselungsalgorithmen gibt.
Also wenn Du nicht gerade einen IQ über 160 hast, dann sollte man das anders lösen.

[Forumsgast]

es ist so einfach und dazu brauch man keinen iq von 160+
und zertifizierte verschlüsslungen kosten teilweise geld also sollte man den kosten nutzen aufwand betrachten und da kommt man mit einem eigenen kleinen coder besser. find ich auf jedenfall. denn wenn da ein hash von 32 zeichen steht, sind die statistikabfragen, wegen denen das ja verhindert werden soll schonmal außen vor und das war die ursprüngliche frage...

[Forumsgast]

Aber deswegen kann sich ja trotzdem noch ein Bot durch die Profile hangeln und die User-Hash-IDs einsammeln .-(