Mac Address or other unique address

#1 What's the lifetime of the uniqueness?

If you're talking "lifetime of the machine", eg licenses for software, then there are many ways to get the mac address, all of which are system-dependant.

If you're talking "lifetime of the connection to the server", you jsut need something sufficiently unique for today; the md5 of a random 10-digit number plus the player name should produce pretty few collisions... Of course, if you're talking lifetime of the connection to the server, then you probably have a unique handle to it already...


Overall, never forget that changing the mac address is trivial, for a variety of reasons.

On linux:
ifconfig eth0 hwaddr DE:AD:BE:EF:12:34:56:78

This works for several reasons, the most salient being:
Mac address is a register on the card, normally.
A round-trip to the card would take a while for each and every packet, so most drivers cache the mac address in ram, then create the packet, then send it out. All you have to do is make one simple call to the driver to change that. Best of all, it's completely volatile.

Even people not attempting clandestine things can just change their network card, and it breaks.

A little more information and I might be able to help a little more...

Gary (-;

PS Yes, I wrote the license server we currently use at work, which works on many platforms. I have a small idea of what I'm talking about :-)

#2 Hmm, Intels CPU id still working ?? (no wait you could disable that)

A HDD will get a unique "volume-id" after a format (and should contain some kind of id that is hardcoded)...

#3 Probably the "easiest" method would be to use an an account system.

Torque can log send/receive information from webservers. So you could write a script based function that sends login and password to a webserver, if it matches send back a hald of a guid you created on the webserver.

When the client connects to the server the server queries the webserver with it's own login/password with a request for the second half of the guid, and the hash or crc of the complete key.

#4 Yeah. Overall, it turns out that there's no garaunteed way to get a unique ID for every system in existence.

What our system does is essentially create a hash based on a list of things that it could be; the user never knows what the hash represents:
On some systems [such as solaris, sgi, or aix], grab the gauranteed unique system ID
On some systems, grab the intel cpuid if we can
On some systems, grab the mac address...
On other systems.....

Turns out that just grabbing the mac address in a reliable manner across all systems is *hard*. Sometimes you need administrative access to grab some things [solaris's unique system ID, iirc].

And then you have to work out how on earth to convince windows to tell you anything useful. *giggle*.

Gary (-;

PS Want a real way to do this? Hardware dongles. Non-crappy hardware dongles [do your own research] are a surprisingly good way to do copy protection. unfortunately, there aren;t too many [none] that work on all the platforms we support with all the physical interfaces necessary. If Torque is your platform, then you're somewhat restricted, so a USB expectiation isn't so bad...

PPS It's also just occured to me that the question was only how "... to attain an address of some sort that -should- be unique to a user's machine", where it seems that IP address might have been sufficiently unique. I suspect this is a bit more depth than was asked for...

#5 Harold -- I am trying to do this FOR a login system -- my current login system is vulnerable because people behind NATs have the same IP... I want to use something other than IP that will not have this same problem.

#6 Interesting article posted to SlashDot a couple days ago.

#7 Uniquely differentiable logins with lifetimes on the order of hours?

Random 10 digit number appended to username and possibly time in epoch seconds, hashed.

Bish Bosh, Job Done.

Gary (-;

#8 That won't work with what I want to do though.

Currently, when you login, it sets in an SQL database the IP variable on your username. Every few minutes, clients are set to "update". If their IP does not match the one in the SQL database, they are disconnected.

That being said, users behind a NAT could all be on at once under the same username. I think you can see the problem, and why I want to use something other than IP.

#9 Probably be easier to set the client to write out a file with a unique ID when it is first installed or run. Then every subsequent time it is run, query the file.

Use this unique ID to guarantee that only one particular client is attempting to login at once.

Set a timeout of like 5 minutes between last packet recieved from any particular client, and the next time it is allowed to login.

#10 What sort of transport is this?
Someone in a load balanced firewall environment is probably being regularly kicked off your server.

Is the client app home brew? If so, then the server should generate a unique token that it sends to the client, and the client is required to ping with it once in a while... [think "cookie"]

Way way WAY more information necessary if my answer above isn't sufficient.

Gary (-;

#11 Couldn't a user simply copy the ID file over?

#12 Gary -- i like that last idea, the cookie one. I think that might work---what should I use to generate their unique token -- username + login time?

#13 1) When NAT is utilized, the reference IP address is almost always contained in the packet (so the NAT can decode who the destination is on return packets).

2) While the IP is the same, the IP and port number shouldn't be. Create a token on a copy of these two.

3) Neither of the above are actually needed, since TGE already does what Gary mentioned--it creates a handshaking challenge/response to authentication a connection request in the first place. You could use this as your check value yourself if you like. See the TGE Connection Sequence Overview to see what files and methods to look at.

#14 Are we talking unix, or something else?

On linux or OSX, username plus login time in epoch seconds, plus an optionally random number would be sufficiently unique for most tasks.

Hash it with MD5 or something for good measure [so you can change the scheme without changing the actual output token format].

On Windows, you probably want something similar, but epoch seconds isn't very native to windows, so you might want something else.

Gary (-;