Shorter GUID using CRC

Question

I am making a website in ASP.NET and want to be able to have a user profile which can be accessed via a URL with the users id at the end. Unique identifier is obviously a bad choice as it is long and (correct me if i am wrong) not really URL friendly.

I was wondering if i produced a unique idnetifier on the ASP page then hashed it using CRC (or something similar) if it would still be as unique (or even unique at all) as just a GUID.

For example:

The GUID 6f1a7841-190b-4c7a-9f23-98709b6f8848 equals CRC E6DC2D44.

Thanks

Answer 1

A CRC of a GUID would not be unique, no. That would be some awesome compression algorithm otherwise, to be able to put everything into just 4 bytes.

Also, if your users are stored in the database with a GUID key, you'd have trouble finding the user that matches up to this particular CRC.

You'd be better off using a plain old integer to uniquely identify a user. If you want to have the URL unguessable, you can combine it with a second ticket (or token) parameter that's randomly generated. It doesn't have to be unique, because you use the integer ID for identifying the user. You can think of it more or less as a password.

Answer 2

Any calculated hash contains less information (bits) than the original data and can never be as unique. There are always collisions.

Answer 3

If the users have a username then why not use that? It should be unique (I would hope!) and would probably be short and URL friendly. It would also be easy for users to remember, too, and fits in the with the ASP.NET membership scheme (since usernames are the "primary key" in membership providers). I don't see any security issue as (presumably) only authenticated users would be able to access it, anyway?

Answer 4

No, it won't be as unique, because you're losing information from it. If you take a 32 character hex string and convert it to an 8 character hex string then, by definition, you're losing 75% of the data.

What you can do is use more characters to represent the data. A guid uses ony 16 characters (base 16) so you could use a higher base (e.g. base 64) which lets you encode the same amount of information in fewer characters.

Answer 5

I don't see any problem with the normal GUID in HTTP URL. If you want the shorted form of Guid use the below.

var gid = Guid.NewGuid().ToString("N");

This will give a GUID without any hyphen or special characters.

Answer 6

A GUID is globally unique, meaning that you won't run into clashes, hopefully ever. These are usually based on some sort of time based calculation with randomness interjected. If you want to shorten something using a hash, such as CRC, then then uniqueness it not automatic, but as long as you manage your uniqueness yourself (checking to see if the hash is not currently assigned to another user and if so, regenerating until you get a unique one) then you could use almost anything.

This is the way a lot of url-shorteners work.

Answer 7

If you use a CRC of a UUID/GUID as ID you could also use a shorter ID in the first place.

The idea of an UUID/GUID as ID is IMO that you can create IDs on disconnected systems and should have no problem with duplicate IDs.

Anyway who is going to enter the URL for the profile page by hand anyway?

Also I see no problems with URL friendliness of an UUID/GUID - there are no chars which are not allowed by http.

Answer 8

How are users identified in the database (or any other place you use to store your data)?

If they are identified using this GUID I'd say, you have a really good reason for this, because this makes searching for a special ID really complicated (even when using a binary tree); there is also more space needed to store these values.

If they are identified by an unique integer value, why not using this to call the user profile?

Answer 9

You can shorten a GUID to 20 printable ASCII characters, with it still being unique and without losing any information.

Take a look at this blog post by Jeff Atwood:
Equipping our ASCII Armor