uniqid

Description

stringuniqid
([ string$prefix = ""
[, bool$more_entropy = false
]] )

Gets a prefixed unique identifier based on the current time in
microseconds.

Warning

This function does not create random nor unpredictable strings.
This function must not be used for security purposes.
Use a cryptographically secure random function/generator and
cryptographically secure hash functions to create unpredictable
secure IDs.

Parameters

prefix

Can be useful, for instance, if you generate identifiers
simultaneously on several hosts that might happen to generate the
identifier at the same microsecond.

With an empty prefix, the returned string will
be 13 characters long. If more_entropy is
TRUE, it will be 23 characters.

more_entropy

If set to TRUE, uniqid() will add additional
entropy (using the combined linear congruential generator) at the end
of the return value, which increases the likelihood that the result
will be unique.

/* We can also activate the more_entropy parameter, which is * required on some systems, like Cygwin. This makes uniqid() * produce a value like: 4b340550242239.64159797 */printf("uniqid('', true): %s\r\n", uniqid('', true));?>

Notes

Caution

This function does not generate cryptographically secure tokens,
in fact without being passed any additional parameters the return
value is little different from microtime(). If
you need to generate cryptographically secure tokens use
openssl_random_pseudo_bytes().

Note:

Under Cygwin, the more_entropy must be set
to TRUE for this function to work.

In other words, first 8 hex chars = Unixtime, last 5 hex chars = microseconds. This is why it has microsecond precision. Also, it provides a means by which to reverse-engineer the time when a uniqid was generated:

date("r",hexdec(substr(uniqid(),0,8)));

Increasingly as you go further down the string, the number becomes "more unique" over time, with the exception of digit 9, where numeral prevalence is 0..3>4>5..f, because of the difference between 10^6 and 16^5 (this is presumably true for the remaining digits as well but much less noticeable).

Generating an MD5 from a unique ID is naive and reduces much of the value of unique IDs, as well as providing significant (attackable) stricture on the MD5 domain. That's a deeply broken thing to do. The correct approach is to use the unique ID on its own; it's already geared for non-collision.

IDs should never be obfuscated for security, so if you're worried about someone guessing your ID, fix the system, don't just make it harder to guess (because it's nowhere near as difficult to guess as you imagine: you can just brute force the 60,000 MD5s that are generatable from millisecond IDs over the course of a given minute, which the typical computer can do in less than 0.1s).

If you absolutely need to involve a hash somehow - maybe to placate a boss who thinks they understand security much better than they actually do - append it instead.

The uuid_make() function takes two arguments when generating v1 or v4, but four arguments are required when generating v3 or v5. The first two arguments have been demonstrated below and are straightforward, so I'll skip to the as-yet non-described arguments.

The third argument to uuid_make() is: $namespace - this is a secondary resource created with uuid_create(); it is apparently used to generate an internal UUID, which is used as the namespace of the output UUID

The fourth argument to uuid_make() is: $url - this is the value that is to be hashed (MD5 for v3, SHA-1 for v5); it may be any string or even null

Here's a simple class illustrating the proper usage (note that if php5-uuid is not installed on your system, each function call will just return false):

As you can see, the calls to v3() always return the same UUID because the same URL parameter, "abc", is always supplied. The same goes for the v5() function which is always supplied a null URL.

The v4() UUIDs are always entirely different because they are (pseudo)random. And the v1() calls are very similar but just slightly different because it's based on the computer's MAC address and the current time.

I've created a class from the function below. With it, creating a lot of uuids beomes about 100 times faster because you do not need to fopen() for each uuid. uuid::get() still works as a static function if you just need a single uuid.

If you want the rand_uniqid to be at least 6 letter long, use the $pad_up = 6 argument

---

You can support even more characters (making the resulting rand_uniqid even smaller) by adding characters to the $index var at the top of the function body.

---

<?phpfunction rand_uniqid($in, $to_num = false, $pad_up = false, $passKey = null){$index = "abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"; if ($passKey !== null) {// Although this function's purpose is to just make the // ID short - and not so much secure, // you can optionally supply a password to make it harder // to calculate the corresponding numeric ID

Prefix can be useful, for instance, if you generate identifiers simultaneously on several hosts that might happen to generate the identifier at the same microsecond.So we can include the hostname / servername in the id.<?phpecho uniqid(php_uname('n'), true);// Output: darkstar4dfa8c27aea106.40781203?>

This builds slightly on david's post below. The differences are that it doesn't require Cake anymore and there is a graceful fallback for /dev/urandom in case that isn't available (/dev/urandom is not available on windows systems for example).

/** * Set the four most significant bits (bits 12 through 15) of the * time_hi_and_version field to the 4-bit version number from * Section 4.1.3. * @see http://tools.ietf.org/html/rfc4122#section-4.1.3 */$time_hi_and_version = hexdec($time_hi_and_version);$time_hi_and_version = $time_hi_and_version >> 4;$time_hi_and_version = $time_hi_and_version | 0x4000;

Neither the pseudo-random number rand() nor the Mersenne Twister algorithms are cryptographically strong, and this is well known. Simply combining non-cryptographically strong algorithms doesn't not make a cryptographically strong algorithm either. Mersenne Twister is a fast algorithm with good k-distribution which will give you numbers for a long time before it repeats itself. MT, rand(), and MD5 should NOT be used for encryption, or for cookies that that store a session ID that gives personal information. A simple application where non-collision of session IDs is highly preferred but not critical, such as storing a user's shopping cart items for when they return to your site (but not their personal information), IS a good use for the MT, rand() MD5, uniqid() and combinations thereof.

DUPLICATE UID WARNING: Be aware that calling this function many times in a tight loop (for instance, to assign UIDs to objects in an array) can result in many of the UIDs being identical, since less than a microsecond may have passed since the previous call. One simple solution is to compare the latest value returned with the previous result, and keep calling in a loop until the new value is different, if you don't mind this call causing a delay of 1 microsecond per call when necessary.

mt_rand() features in a lot of comments here. It is a good PRNG for Monte Carlo simulations, not for anything related to security. Wikipedia's page on cryptographically-secure PRNGs explains. If you want it to be hard for an attacker to guess or predict a "random" UUID, try using /dev/random instead.

/** * Set the four most significant bits (bits 12 through 15) of the * time_hi_and_version field to the 4-bit version number from * Section 4.1.3. * @see http://tools.ietf.org/html/rfc4122#section-4.1.3 */$time_hi_and_version = hexdec($time_hi_and_version);$time_hi_and_version = $time_hi_and_version >> 4;$time_hi_and_version = $time_hi_and_version | 0x4000;

wooshoofoo, the reason mimec is calling mt_rand multiple times is because the largest number mt_rand can produce is 2^31 (2147483647, as reported by mt_getrandmax() on my server). RFC 4122 requires a 128 bit value.

Also they are not "4 digit sequeces", but 4 digit hexadecimal numbers. 16^4 == 2^16.

<?php/** * Another (ugly) "random or pseudo-random" version of RFC 4122 * * This version calls mt_rand() the fewest possible times. * if mt_getrandmax() == 2^31 then this will call mt_rand() 5 times YMMV * * Personally, I would use mimec's version * To handle the large values, we'll keep everything as strings. * * @return string */function uuid() {

I'm not too fond of the recommendation to use an MD5 of the unique ID for session IDs. It would be a better idea just to use uniqueid(rand(), true) without the MD5, because even though it's a rare circumstance, MD5 is a hash, not an encryption, which means it has collisions. Therefore you theoretically could have multiple users given the same session ID which could result in one user's ability to access another user's data.

I guess, this is not a bugs, just a note for someone newbie like me, i've got problem on uploading image, i tested on local server, it works fine but when i upload on my hosting site , the scripts failed (i use shared hosting, so i' m helpless), this is a part of my scripts:

$ext=$this->_fuphandler->extractExtension($data); $strsha=sha1($this->_fuphandler->extractFilename($data)); $r=sprintf($pathToRoot.$dest.'%s.%s',$strsha,$ext); // filename builder $rawsrc = $data['tmp_name']; if(!move_uploaded_file($rawsrc,$r)) {....}it should work, it did on my uniform server, but it didn't on my hosting so i spend many hours on trying, then i try to change the $strsha=uniqid();and it works...i know it's just a silly thing, ...hehehe, beside i'm just a newbie, but probably will help someone who has some problem like me.