Larry Osterman's WebLog

Because they don't know the meaning of the GUIDS. They just copy paste the example code and then forget about that.

Textbox cargo cult programming: http://blogs.msdn.com/EricLippert/archive/2004/03/01/82168.aspx

Or use <a href="http://www.codeproject.com/macro/guidgennet.asp">GUIDGen.NET </a>

I reused a MS GUID 2 weeks ago. It's name for the time being is MustChangeGUID.reg as I didn't have anyway of generating a new one without rooting around for VS CD. And that reminds me VS is now reinstalled so I'm off to make a new one.

It was adding a menu entry to the IE tools menu. One requires a GUID (for no good reason I can see - there is no code attached). First I thought any string will do. Well test didn't substitute for a meaningless number. So I chose a IE4 powertoy GUID.

Only a moron would have thought up GUIDs in the first place. I understand the problem it solves but meaningless numbers are meaningless numbers. They are too long for humans to work with, remember, or anything. Didn't someone invent an assembler to solve a meaningless number problem, eg Int 21 instead of 52513.

> 2) They're unique

I thought that was only true on machines with a NIC (since it uses the MAC address as part of the generation process, and the MAC address is going to be unique) but if you don't have a NIC, there's no way to ensure with 100% certainty that the number's going to be unique...

Then again, how many machines are there these days without a network card?

I can totally see how this happened. Code was copied, pasted, forgotten about, rediscovered. You can't tell by looking at the code if the GUID has been used before or replaced*. It's often a hassle to replace a GUID, since it's in 2 or 3 different places (idl, reg) in multiple formats (so you can't do a naive search and replace) and you get mysterious errors if you don't fix them all (or no errors until you try on a clean machine).

* How would that be for a "What's wrong with this code" installment? The GUID comes from MSDN code sample X.

Hah!

Unique MAC addresses in network cards.

Right.

Our programs have installation IDs generated from (a) the numerical lowest network card MAC address, if any are present, or (b) randomly.

We get two sorts of problems all the time:

- installation IDs that were generated randomly because no suitable MAC was available

- conflicting installation IDs at multiple customers' sites because the MAC wasn't unique

I just wish privacy fanatics hadn't killed the Pentium ID feature, this kind of problem would be much easier to solve if we had that. Unfortunately, as it is, I don't know of a single reliable way to uniquely identify a user's PC.

Also, we've had one of our own GUIDs, generated by guidgen, conflict with some other component, apparently by complete accident. Fix? We generated a new GUID...

Yes it's a good idea for people to read the rules and use GUIDgen, just as it's a good idea for people to read the rules and write valid C (or C++). Let's hope that one reminder will be enough for some of them.

On the other hand, yes there are still a lot of PCs without built-in LAN cards. PCMCIA-Ethernet and USB-Ethernet adapters are still strong sellers.

Hmm, you know I have done a lot of experimenting with guids, trying to generate the same one even multiple ways.

Ok so I was really bored one day. Idle Programmers hands do weird things. Anyway I was playing generating GUIDs in SQL server, in .net and through some old VB Code that taps into UuidCreate

Anyway all of them were inserting the guids they generated into the SQL server and the SQL server was using a unique ID to hold the guids it was inserting and the unique ID was also a guid. I am not sure the algorithms MS uses to generate the guids but something is based on time because I would get a lot of guids generated with like the first 12 characters would be the same then like every second the first 12 would change. This was in .net SQL server there was no real pattern to the guid and the VB one I don't remember. Anyway not one of all these GUID I generated were the same. So how the heck does it happen that people get the same GUID. I am not saying it can't happen but the chances of getting the same guid I think are greater than winning the lottery, now the example above is blatant that someone copied the guid from the sample. However, it seems that I have been hearing more and more lately about guid collisions. Kent Sharky even found this weird experience. http://blogs.msdn.com/ksharkey/archive/2004/10/28/249164.aspx

I guess maybe is there talk of changing the GUID? Making it bigger or different? It seems more and more it is getting used everywhere. The chances of guids not being unique are getting slimmer and slimmer. I know there are GUIDs in com just look at how many dlls are on your machine. There are guids in hardware and drivers, guids are used in databases. Active directory sheesh each object in there may use 2 or more guids plus something called a SID, never understood a SID, but I know it is also a unique identifier to each object. Is it possible that the world may be running out of GUIDs just like IP addresses? hence the reason for IPv6. I know there are 16 bit guids, and I know there are 32 bit guids, are there now 64 bit guids? At one time we thought the world would never run out of IP addresses. Could ever find ourselves in a world where the guid runs out.

They are fine for programming. In VB I don't even see them or think about them (normally). But when there is problems, mine or others, it is impossible (well without writing things down) to troubleshoot. The human brain can contains 7 items in short term memory. Unique strings need to have less than 7 items (although real words can count as 1).

I mean one can''t even find things in Add/Remove anymore as GUIDs migrate there. Microsoft word has gone from Word to a 128 bit number.

I recall a thing called DNS to handle small 32 bit numbers. And didn't LAN Manager use names rather than numbers for the benefit of humans.

This is something designed by an engineer.

Here is some HTML,
<OBJECT CLASSID="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83"
ID=dsoMacro5 WIDTH=0 HEIGHT=0>
<PARAM NAME="DataURL" VALUE="music.txt">
<PARAM NAME="UseHeader" Value="True">
<PARAM NAME="FieldDelim" VALUE="&#09;">
<PARAM NAME="Sort" Value="Title">
</OBJECT>

I copied the above code once (years ago) and each time I use it I copy the previous time I used it (I love tab delimited databases - like screwdrivers there is no problem they can't solve). I don't know that stupid number, never will, so cut and paste is the only way to make a display page for whatever data. That means I NEED to find a previous page to make a new page or I am stuck.

A GUID conveys no information.

Maybe random word would be a better idea, eg

{dog-cat-mouse-supercalafragalistic....-hate-guid}

This would allow 7 words rather than 7 letters/numbers to be remembered.

Denis wrote:
Our programs have installation IDs generated from (a) the numerical lowest network card MAC address ...
We get two sorts of problems all the time:
...
- conflicting installation IDs at multiple customers' sites because the MAC wasn't unique

It is not uncommon for PCs to have "pretend" network interfaces for things like VPNs, modems, the loopback adaptor and so on. To avoid confusing higher software layers these pretend devices can have a MAC address, and it's often the same address on every PC (which shouldn't matter, because it's not actually used for anything). If you're grabbing a MAC address for uniqueness you need to ensure it's from a real network interface card.

The Macromedia Flash Player's CLSID is {D27CDB6E-AE6D-11cf-96B8-444553540000}. I believe 444553540000 suffix is "DEST", the fake MAC address used by the "fake" NIC used by dial-up networking! If you grep through the Microsoft Platform SDK, you'll see lots of other CLSIDs ending in 444553540000, so the GUID namespace is a lot smaller for many components!

Carlos:

"If you're grabbing a MAC address for uniqueness you need to ensure it's from a real network interface card."

We're doing that, but apparently there are more non-real NICs than we know of...

Shipping in Q4 2005: DRM for GUIDs.

Copy a GUID, go to jail.

;)

"I just wish privacy fanatics hadn't killed the Pentium ID feature, this kind of problem would be much easier to solve if we had that. Unfortunately, as it is, I don't know of a single reliable way to uniquely identify a user's PC."

The Pentium ID was not a globally unique number. Sadly, a lot of privacy advocates never realized this.

Given that it is too hard for people to generate GUIDs, I think it is beyond all possible hope that people use real MAC addresses. I for one didn't even know this was a problem. *sigh*

I don't know who's fault it is, but gosh darn it, STOP!!!!

:)

MAC addresses are SUPPOSED to be unique. You have to purchase a block of MAC addresses from IEEE.

However, a lot of second-rate network card mfgrs will just randomly create addresses for their cards without buying a block. Another common thing is to re-use addresses once you have used up your block (rather than buying a new block). Sad but true.

I've also seen some poorly-designed network cards that had trouble reading the MAC address EEPROM, so they would occasionally change their MAC on a reboot.

Microsoft has itself distributed software integrated/bundled with windows that with the same GUID had changed interface (!) between releases of Windows. (same functions, but different parameters/arguments)

It did cost us a measurable amount of money, lost goodwill and (me) debugging this for a non-trivial amount of time to find this shite - that MS themselves violated the cardinal rule about COM interfaces.

As Microsoft has a history of this themselves, what Microsoft dude/dudette/representative/employee has the stomach to complain about it when others do it too? MS have already set the pace.

There are some malwares implemented as browser helper objects that use the same UUID as in this article from MSDN (BHO 101):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebgen/html/bho.asp

A google search on "1E1B2879-88FF-11D2-8D96-D7ACAC95951F" returns thousands of hits.

Plain stupidity or spoofing for profit?

Larry,

this blog entry forms the basis for a section in the OWASP Guide 2.0 :) This blog entry is linked in the cryptography section and the topic itself is a level B entry.

Hopefully this will help prevent this issue in the future.

Andrew van der Stock
OWASP Guide Lead

With respect to MAC addresses, I've worked with ethernet chips where every single chip had the same MAC. Caused havoc until we figured out what was going on.

Thursday, July 21, 2005 10:55 PM by Jeff Parker

> So how the heck does it happen that people
> get the same GUID. I am not saying it can't
> happen but the chances of getting the same
> guid I think are greater than winning the
> lottery,

That's absolutely right. Even though you can't predict who will win the lottery or how long it will take (in a version where there's no guarantee of a winner but the jackpot grows), but nonetheless someone will eventually win it.

A better analogy of course is a famous puzzle regarding birthdays. What are the odds that a random collection of n people will include at least two with the same birth month and date. If you want a 100% guarantee then you need 367 people. But even with just 23 people you have a 50% chance.

http://www.opengroup.org/onlinepubs/9629399/apdxa.htm
doesn't exactly say how to generate a UUID if no IEEE 802 address is assigned to the machine doing the generating. Its stated conditions for detecting that the local value of UTC has gone backwards also seems slightly insufficient, since some operating systems allow an administrator to adjust the time of day, some (including some that are closely related to the Open Group) don't want to admit that UTC includes leap seconds, etc.

On the other hand, in one three-bit field, one possible value is defined as letting Microsoft do whatever they want to do differently. Hey, there are millions of manufacturers in this industry (some of them not being manufacturers of operating systems or integral components thereof so they haven't even been steamrolled flat yet). Why doesn't this three-bit field allow enough values for every manufacturer to do whatever they want to do differently? After all, how else can you expect everyone to agree on a standard? Sheesh.

Plus they admit that the 100 nanosecond interval is only likely to remain adequate for one generation of high-performance multiprocessors after 1997. We're passed that now. The universe is doomed.

PingBack from http://famouspeoplesbirthdayblog.info/larry-ostermans-weblog-uuids-are-only-unique-if-you-generate-them/