php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #55391 Uniqid is not unique --
Submitted: 2011-08-10 07:28 UTC Modified: 2015-12-09 01:04 UTC
Votes:1
Avg. Score:1.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: ludovic dot urbain dot 1 at gmail dot com Assigned: yohgaki (profile)
Status: Assigned Package: Unknown/Other Function
PHP Version: Irrelevant OS: any
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2011-08-10 07:28 UTC] ludovic dot urbain dot 1 at gmail dot com
Description:
------------
---
From manual page: http://www.php.net/function.uniqid%23Description
---
Basically, I find it useful to have UUID's that can at the very least be unique 
in a controlled environment.

As in, being able to have unique id's within a limited set of machines(I picked 
32bits for the machine id, carefully distributed by me and intended to be 
unique, not based on MAC which can/must sometimes be spoofed for other 
purposes).

In order to achieve that, several parts are required:

-> machine unicity
-> thread unicity
-> thread time unicity
-> inside-thread unicity

The reason I picked those variables is very easy :

-> machine id is a preset variable

-> thread id is a readily available variable (you can pre-store it @ start of 
thread)

-> thread time unicity (same you can pre-set it @ start) to avoid mixing thread 
1234 from 12 o'clock with thread 1234 from 16 o'clock (with the time id which is 
in milli or microseconds, you can be sure that ending your thread with a very 
small sleep will prevent any possibility of two threads on the same time point)

-> inside thread unicity (counter... of course you always have at least a 
counter going somewhere for some reason, so might as well use it)

So basically, I picked 4 variables which are almost free to get (machine_id is 
present even before thread execution, thread_id is present @ thread creation, 
and thread_time is present @ thread creation too, the counter is almost 
inevitably present if you're handling several objects) in terms of processing 
power, but can also guarantee unicity.

This can be guaranteed to be unique, as long as your time is unique (and if it 
is not, you have so many problems beyond unique identification it's not worth 
focusing on it -- ), and from my calculations, that type of unique id is safe 
for the next 20+ years according to processing power growth (although at some 
point threads_id's might get another digit).

Besides, this method of generating unique id's is orders of magnitude faster, as 
it requires only very minor cpu activity (no random, no hash, no time variable 
generation on every id, etc. etc.) -> the most expensive operations have to be 
on the base16 encode / concat side.

I have my own code for generating UUID's, however I believe it would be 
interesting to upgrade the UUID function in PHP to propose something as 
efficient and unique.


Test script:
---------------
// No script is required when a function is by it's nature not generating unique id's

Expected result:
----------------
Absolutely nothing


Patches

fakepatch.txt (last revision 2011-08-10 07:30 UTC) by ludovic dot urbain dot 1 at gmail dot com)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-12-09 01:04 UTC] yohgaki@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: yohgaki
 [2015-12-09 01:04 UTC] yohgaki@php.net
uniqid() is not designed to generate unique ID like UUID, but generate time based ID, optionally more entropy by passing TRUE as parameter. If you need better unique ID, use UUID or good enough RNG and hash.

When TRUE parameter is passed, we may use random generator rather than gettimeofday(), but it does not worth to implement it since there is UUID or RNG for this purpose.

However, users may misuse this function. We may change uniqid() default to uniqid(TRUE) as misuse mitigation.
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC