XMDS register will register clients with non-unique ID

[Alex Harrington]

When calling the XMDS register method, persistent calls with identical options generates multiple displays with the same ID.

Contents of my display table:

http://pastebin.ubuntu.com/103977/

[Alex Harrington (alexharrington)]

I have a theory on this. The DB defines license as varchar(32). I expect I'm returning something longer than 32 characters, in which case the comparison fails each time.

Possible solutions. I could shorten my MD5, but this leads to possible collisions between clients.
Increase the length of the license field in the display table.
I could hash on something different to shorten the MD5 by implication.

However, perhaps xmds should enforce this limit somehow.

[Dan Garner (dangarner)]

The reason its 32 characters is that MD5 is normally 128-bit? Therefore 32 hexadecimal characters. I don't see any problem increasing the size of the column on the display table - and XMDS should definitely enforce the size. Before I make such a change what do we think the appropriate size would be?

What are you passing through MD5 to generate a unique key? The MD5 is only going to be as unique as that you are using to get it. If you made it a MD5 of date, server key and a random number I doubt that another client would ever conflict.

[Alex Harrington (alexharrington)]

I was going to based MD5 on a MAC address and a string entered by the user. I'm having problems getting the MAC at the moment - so currently it's just an MD5 of a string "password".

I'll try and check exactly what I'm sending you shortly.

[Dan Garner (dangarner)]

FYI - When I MD5 password I get:

5f4dcc3b5aa765d61d8327deb882cf99

[Alex Harrington (alexharrington)]

OK - partly my fault.

My security conscious "Security Now!" listening side is actually sending you "password" as "5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8" which is an SHA1 hash, as MD5 has been proven to be weak over the last few months.

Since the server doesn't really care what the hash is, I'd like to keep it as SHA1 in the interests of not engineering something that is questionable at design time!

[Alex Harrington (alexharrington)]

... that said, does the string hold any cryptographic significance? It's not as if we care what it is a hash of? The server doesn't know what the data hashed is?

If so, I'll switch to MD5. xmds still needs to enforce string length tho.

[Alex Harrington (alexharrington)]

... but on thinking again it's been proven that MD5 is relatively collision prone - that is that more than one input can yield the same output hash. Perhaps SHA1 would be a good move?

[Dan Garner (dangarner)]

OK, I will expand the column size to 40 - to update your copy just do:

 ALTER TABLE `display` CHANGE `license` `license` VARCHAR( 40 ) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL

I will also update the web service to check that it will not accept a key longer than 40 characters