Unique Computer ID

[storme]

G'day All

I've been searching around the forums for a method of generating a "Unique Identification" number for a computer.

I'm not worried about people hacking to clone someone else as it would be a waste of time in this case.

The main requirement is that it is unique for each computer.

The number is needed for an internet based client-server system so the server can ID the incoming computer.

I was originally going to add a CustomerID + ComputerID(Non Unique) to create a Unique ID, But I would have had to create the CustomerID ahead of time at the server and logistics don’t allow that.

What I've come up with so far are :

• Mac address of Fixed Network Adaptor
• OEM number of main hard drive
• Windows Registration Key
• Serial number (Generated on site or requested from server)

Could you please let me know (in your view) what the pros and cons of each of these?

Which one you would suggest is best?

Pointers to code to create the ID? (Not necessary but appreciated)

Thank you in advance for any help!

[JohnOne]

CPUID maybe combined with some bios info.

if you want code for this search compinfo udf

[storme]

  On 4/10/2010 at 2:35 PM, 'JohnOne said:

CPUID maybe combined with some bios info.

if you want code for this search compinfo udf

I think I read somewhere that CPUID wasn't UNique and infact on the same chip could be exactly the same.

But I maybe mistaken as I"m going a bit loopy after reading multiple threads on the subject.

I'll be falling back on the Compinfo UDF (it's a great piece of code) to get the details when I know what to use. I don't want to pick a few details that I think will give me a Unique ID then find out too late that I was wrong and have to redoe everything.

Thanks for the input

[somdcomputerguy]

Perhaps this helps? UUID Generator

[Ascend4nt]

'CPUID' is an instruction for getting CPU information from the computer. In some cases you can get a serial #, but for most PC's, serial # information is turned off by default in the BIOS. So, that's definitely not an option.

[jchd]

Uniquely identifying a physical installation is not only hard, but also a can of worms.

MAC addresses are not unique from the start (can be spoofed or forced even in Bioses, ..) not reliable.

CPU UID has been defeated several times for privacy concern, or only identify type, stepping, ..., or is simply not available

Hard disk number isn't usable everywhere (thin clients, unusual hardware)

Other deep-into-firrmware secrets like DRM-aware devices never wait long before the scheme gets broken.

Secure unique tokens are difficult to implement in computers, are not always as secure than advertised and cost more legs and arms than most laymen or small organizations can afford to spare.

Only thing remaining: pure software for unique ID of an session. You say you don't worry about cloning, so use a strong hash of the timestamp at first connection (salted) and keep that as a shared "secret" on both sides. Your server knows a list of IDs, will only accept connections from them (except new clients of course) and you need to consider that if an ID gets cloned and used simultaneously by two different sessions, then the original client is responsible for giving out the secret ID.

The big problem with hardware UID is that anyone can have a perfectly legitimate need to split a "known" (by the server) PC in pieces and reuse the CPU elsewhere, sell the harddisk, burn the Lan adapter and install a Gigabyte add-on card ... If you rely on a single hard ID, then the once-known client can disappear forever (hardware changed). If you rely on a mix (like MS does) you have to keep track of what hardware goes where, etc... Too messy and too difficult to get right. In fact MS doesn't track down to sub-components level.

[storme]

  On 4/10/2010 at 11:39 PM, 'jchd said:

Uniquely identifying a physical installation is not only hard, but also a can of worms.

Agreed!

A bit more information to clarify what I need the Unique ID for. (Should have made it clear in the first place.

The Unique ID will be used in a "hello" message at the start of a session to link the incoming Socket from the client to an entry for that computer at the server end.

  Quote

MAC addresses are not unique from the start (can be spoofed or forced even in Bioses, ..) not reliable.

CPU UID has been defeated several times for privacy concern, or only identify type, stepping, ..., or is simply not available

Hard disk number isn't usable everywhere (thin clients, unusual hardware)

Other deep-into-firmware secrets like DRM-aware devices never wait long before the scheme gets broken.

MAC - I know they can be spoofed and changed easily. But I thought they were Unique when the chip left the factory?

CPU - OUT - Not available - Agreed

Hard drive ID - these will only be desktop/towers/laptops so no Thin clients - May not work as I tried a script that was supposed to get a hard drive ID and it was Blank for my Main Hard drive but OK for the other 2 I have in the computer.... So it's out as well.

DEEP STUFF - don't need anything that complex.

  Quote

Secure unique tokens are difficult to implement in computers, are not always as secure than advertised and cost more legs and arms than most laymen or small organizations can afford to spare.

  Quote

Only thing remaining: pure software for unique ID of an session. You say you don't worry about cloning, so use a strong hash of the timestamp at first connection (salted) and keep that as a shared "secret" on both sides. Your server knows a list of IDs, will only accept connections from them (except new clients of course) and you need to consider that if an ID gets cloned and used simultaneously by two different sessions, then the original client is responsible for giving out the secret ID.

Ok just to hammer it out and apply it to my use.

1. New client connects to server.

2. Server generates a hash based on the timestamp. (Guarantied Unique for server)

3. Server passes it back to the client.

4. Client stores the hash and returns info (customer name, etc) to the server.

If Hash gets spoofed client sends a "re-request" message and server sends new hash (NOT an automatic process).

Actually once the mechanism is in place; it wouldn’t be hard to change the hash on a regular basis. Lots of possibilities...Thank you!

Any suggestions for AutoIT code to do the “strong hash”?

  Quote

The big problem with hardware UID is that anyone can have a perfectly legitimate need to split a "known" (by the server) PC in pieces and reuse the CPU elsewhere, sell the harddisk, burn the Lan adapter and install a Gigabyte add-on card ... If you rely on a single hard ID, then the once-known client can disappear forever (hardware changed). If you rely on a mix (like MS does) you have to keep track of what hardware goes where, etc... Too messy and too difficult to get right. In fact MS doesn't track down to sub-components level.

True too true!

This could be handled by a reauthenticaiton process but a server based hash is better.

Thanks for the suggestions!

[jchd]

I use trancexx code for generating any strong hash of your choice. MD5 is probably enough in your case, but feel free to use SHA-*.

There are a number of other implementations floating around and the search will fetch them for you.

Ascertain to use a conforming implementation by double checking you get consistent result among various implementations when run over the same source.

You need to "salt" your input: if people happen to determine (not hard) that you use, say, SHA-256 for hashing a _NowCalcData() string, then they could pretend having a genuine ID by building one themselves. To cut away such (marginal for you) possibility, append a server passphrase to the timestamp, like:

$Id = _SomeSHA256("This is storme's server passphrase for generating application FooBar licences!" & _NowCalcDate())

Be sure to use a unique timestamp (not more than one registration per second, or use a finer-grain imestamp (epoch or similar) then stick to it. Store the Id along customer data along with the timestamp used.

Keep the server passphrase jalously secret and you're home. Take a well deserve rest and watch licence fees increase your income!

I think that's reasonable and secure enough for most needs.

[storme]

  On 4/11/2010 at 2:00 PM, 'jchd said:

I use trancexx code for generating any strong hash of your choice. MD5 is probably enough in your case, but feel free to use SHA-*.

There are a number of other implementations floating around and the search will fetch them for you.

Ascertain to use a conforming implementation by double checking you get consistent result among various implementations when run over the same source.

I've already got trancexx code in my Include folder ready. I was going to use MD5 but saw that SHA-1 was more recent. I'll have a play with trancexx code and see which suits. Probably the more recent SHA. I used to know all this stuff but it's been a few years since I graduated and havn't kept up as much as I should have.

  Quote

You need to "salt" your input: if people happen to determine (not hard) that you use, say, SHA-256 for hashing a _NowCalcData() string, then they could pretend having a genuine ID by building one themselves. To cut away such (marginal for you) possibility, append a server passphrase to the timestamp, like:

$Id = _SomeSHA256("This is storme's server passphrase for generating application FooBar licences!" & _NowCalcDate())

Thanks, I was going to ask what you meant by Salt (I know the phrase just need to know the use in this case) :-).

Better to be safe then sorry!

  Quote

Be sure to use a unique timestamp (not more than one registration per second, or use a finer-grain imestamp (epoch or similar) then stick to it. Store the Id along customer data along with the timestamp used.

Keep the server passphrase jalously secret and you're home.

The Passphrase will ONLY be at the office and seeing as it's a one man business it should be safe. :-)

SQLite will be by storage method of choice when I get the TCP side of things hamered out.

Hmmm just realised once I move beyond 1 client it will have to have the SQLite then.... are well interesting times ahead.

  Quote

Take a well deserve rest and watch licence fees increase your income!

I think that's reasonable and secure enough for most needs.

It'd be nice to have a rest but I think that will be a far way down the road. But it is FUN to get back to a real project again something that may produce a sumstantial program at the other end.

Thanks AGAIN mate for your help it's been GREAT!!

[jchd]

You're welcome John.

SQLite is powerful and reliable. Go ahead using it but don't hesitate to ask if you have questions about design choices or implementation issues. Beware nonetheless than AutoIt not being threaded, you'll have to serialize things strictly if you intend to have anything AutoIt-based serving your clients. OTHO, there is available or in-the-box support for SQLite in all webserver languages. Even if your server uses language XYZ for webservice and an SQLite base that doesn't preclude having AutoIt applications using the same SQLite base running on the server at the same time. The only issue is with remote access to an SQLite base in concurrent context.

[storme]

  On 4/11/2010 at 3:17 PM, 'jchd said:

You're welcome John.

SQLite is powerful and reliable. Go ahead using it but don't hesitate to ask if you have questions about design choices or implementation issues. Beware nonetheless than AutoIt not being threaded, you'll have to serialize things strictly if you intend to have anything AutoIt-based serving your clients. OTHO, there is available or in-the-box support for SQLite in all webserver languages. Even if your server uses language XYZ for webservice and an SQLite base that doesn't preclude having AutoIt applications using the same SQLite base running on the server at the same time. The only issue is with remote access to an SQLite base in concurrent context.

Threading is a little bit of a worry (it's be nice to have shrug but we dont' have it) I'm keeping that in mind and the way the server is developing it is aware of which client each message is recieved from and will have a seperate set of varaiables (array) for each one. I am assuming that if multiple messages come in at the same time KIPS UDP will just trigger for each of the packets and the computer will store the TCP packets till I get to them.

That is one of the reasons I'm trying to keep the code simple...Just accept the packets put them in the database and move on. Other programs will handle what the packets contain.

I use the term "server" very loosly. My Email server is an OLD pentium III running Window XP (GOD HOME edition, I thought it was PRO), a Commercial custom Email server a mate of mine wrote some time ago. When this program goes in the computer will be upgrade to whatever the most powerfull of old machines I have here at the time. Running XP Pro!

SO no troubles about webserver compatibility. I could even go MSSQL as that is what the email server uses BUT I'd prefer to keep it simple and use SQLite.

Well I better get to it tomorrow night and produce soemthing to how you.. it's all vapour ware at the moment

Thanks again