Lösung ist:

[Jörg Reinholz]

Moin!

Wenn beispielsweise der ntpd im Hintergrund an der Uhr dreht, kommt eventuell dieselbe Uhrzeit zweimal.

Das sollte eigentlich nicht passieren. Zumindest glaube ich gelesen zu haben, dass die Systemzeit dann nicht etwa hart verstellt wird, sondern dass die Differenz in mehreren Schritten angeglichen wird und es also keine zwei Zeitpunkte gibt, an welchen die gleiche Systemzeit zurück geliefert wird. Prinzipiell kann Linux sogar Nanosekunden zurückgeben

~> date +%s.%N
1428658410.775922668

also ist diese schrittweise Verstellung auch im Microsekunden-Bereich machbar.

Stellt sich die Frage, was Windows kann. In dem von Dir verlinkten Quelltext zur Funktion uniqid() glaube ich Hinweise gefunden zu haben, dass es zumindest auf 32-Bit-Windows-Systemen und auch mit cygwin.dll wohl das eine oder kleinere Problem bei derart feinen Zeitauflösungen gibt.

Was jetzt den Unit-Test bestrifft: Da braucht es unter Umständen nur ein Mehrprozessor-System und die entsprechende Anzahl von parallelen Threads. So könnte, genug Lotto vorausgesetzt durchaus so ein Konflikt in einem Unit-Test provozierbar sein, während er im Alltag nahezu ausgeschlossen ist.

In einem Punkt hast Du allerdings durchaus recht, denn der TO will was Blaues und was Rotes. Lila klingt nur so als wäre es das.

Das Blaue: Wenn ich eine Identifizierung brauche, dann sollte, genau wie Du trefflich vorschlägst, und wenn die Datenbank schon benutzt wird, deren Möglichkeit, eine (schlicht und einfach fortlaufende) ID zu generieren, auch genutzt werden. (Punkt!)

Das Rote: Wenn ein nicht erratbares Muster (String, Zahl) quasi als Passwort gewünscht wird, dann kann man das durch Zufall erzeugen (und hier ist ETWAS wie bin2hex(openssl_random_pseudo_bytes(32)) gewiss nicht die schlechteste Lösung, weil ja wohl kaum jemand etwas griffiges gegen openssl einzuwenden hat)

Am Ende der Story muss man das nur noch verbinden und, darum geht es hier wohl, die Daten nur ausliefern, wenn ID und "Passwort" stimmen.

Jörg Reinholz