Good post! This stuff should be common knowledge.
Also, I’m not an expert is hash algorithms, but I understand SHA-1 is a better alternative to MD5 with regards to random distribution.

Some guy on php.net’s uniqid page says md5-ing the output of uniqid is a dumb idea…
http://php.net/uniqid
John Haugeland
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.
function BadIdeaID() { return uniqid() . ‘_’ . md5(mt_rand()); }
Is he right?

Excellent piece. I’m currently writing a book “Why company’s take your intellectual property? ‘Cause you give it to them.” – Your example is prime. Whom do I talk to about use w/attribution of course.
Thanks for sharing!
Christopher

Hi Jeff,
While some may take the position that it’s a benefit that such information remain private to your competitors, it could also be argued that the transparency would be beneficial to your customers.
Also, with your scheme, how do you handle key collisions? On a large enough dataset, the probability that two records will share the same id increases to 1.

@Xianhang With 820 billion documents, the probably of an MD5 collision (128 bits) is 1 in a billion. See
http://en.wikipedia.org/wiki/Birthday_paradox#Probability_Table
However, this requires that you have at least 128 bits of entropy in the first place, which rand() (and probably even mt_rand()) won’t give you. Still, once the random number generating part is fixed you should be okay for most applications.
(I am also doubtful that feeding the output of one random number generator into another does any good.)

John Haugeland’s comments were taken somewhat out of context. The original thread on php.net he was responding to had someone advocating the use of system time as the seed for an ID generator, which has a number of implementation-specific problems including resolution (resistance to collisions) and reverse engineering (being able to determine the date the ID was generated from the ID itself). John’s comments are right in that context.
To recast the discussion — what we are really discussing is a set of requirements. (1) ability to generate a unique ID with vanishingly small probability of duplication; (2) ID format and content that provide no useful information to a competitor / adversary; (3) ID format that is suitable for embedding in a URL query string; (4) niceties — compactness, human-readable etc.
The earlier suggestion that this could be accomplished (in pseudo code) as Encode(Hash(Random())) is conceptually correct but over-complicated. The standard UUID function accomplishes all of this, if you use a recent enough version. E.g. UUID version 5 uses a high entropy random source, and runs the result through SHA-1, and the final format is URL-friendly if not particularly compact.
If compactness is needed then wrapping all this in a base conversion is a good idea, but straight Base 64 isn’t the best choice because the + and / characters require extra encoding & decoding for use in URLs. Life is a lot simpler, if somewhat less compact, if you use Ascii 32 or Base 62 encoding. Compactness usually isn’t a real requirement unless the number needs to be readable, speakable, transcribable or memorizable by a person, which doesn’t seem to be the case here.