orangepips

Addressing some common questions and issues seen with UUIDs and Coldfusion.

Through version 7, the Coldfusion UUID implementation, createUUID(), is slow. So here are some alternatives depending on JVM version.

• 1.5+: look at java.util.UUID.
  
• 1.4 & earlier: see the Java Uuid Generator (JUG) that the 1.5 implementation is based upon (http://jug.safehaus.org/)

Even if UUID generation performance is not an issue you may still want to use something other than Coldfusion's implementation: see the Security heading below.

Unique != Random

The Version 1 UUID algorithm used by Coldfusion virtually guarantees a globally unique value. In other words a call to createUUID() will generate a value different than any other computer in existence. And, the design ensures that repeated calls will generate a new, globally unique value each time.

However, to achieve this end the Version 1 UUID algorithm relies upon the time and MAC address of the computer generating the value. This means that a given UUID value can be reverse engineered to determine the MAC address and timestamp of the generator. In addition, a UUID can be generated to appear as if it came from the computer in question as well, given its MAC address.

As a result the value is predictable, i.e. not random, and may present a security problem.

Security

One proposed solution for making UUIDs secure is using an MD5 hash of the value. This is probably not a good solution because rainbow table attacks have made breaking this technique relatively cheap and straightforward. Instead, the Java options above both offer static methods that generate a random UUID value, not tied to the computer's timestamp and MAC address.

However, randomness creates a potential collision problem because the possibility exists that multiple calls may generate a duplicate value. For throwaway values, this may not be much of an issue, but for use with database primary keys it requires extra care to deal with dupes.

Database Primary Key for Replication

Replication is a problem when dealing large volumes of database records. The problem arises when copying a subset of records from a source to target system. Often key conflicts arise. UUIDs are a viable solution.

Auto-incrementing primary keys are a problem in this scenario because the target server may have already assigned the IDs. And, attempting to insert copied records may also violate foreign key constraints, particularly if data is coming from more than one table. So, UUIDs (at least version 1 UUIDs) as database primary keys guarantee records will not conflict when replicated.