views:

1269

answers:

10

I have looked all of the place for this and I can't seem to get a complete answer for this. So if the answer does already exist on stackoverflow then I apologize in advance.

I want a unique and random ID so that users in my website can't guess the next number and just hop to someone else's information. I plan to stick to a incrementing ID for the primary key but to also store a random and unique ID (sort of a hash) for that row in the DB and put an index on it.

From my searching I realize that I would like to avoid collisions and I have read some mentions of SHA1.

My basic requirements are

  • Something smaller than a GUID. (Looks horrible in URL)
  • Must be unique
  • Avoid collisions
  • Not a long list of strange characters that are unreadable.

An example of what I am looking for would be www.somesite.com/page.aspx?id=AF78FEB

I am not sure whether I should be implementing this in the database (I am using SQL Server 2005) or in the code (I am using C# ASP.Net)

EDIT:

From all the reading I have done I realize that this is security through obscurity. I do intend having proper authorization and authentication for access to the pages. I will use .Net's Authentication and authorization framework. But once a legitimate user has logged in and is accessing a legimate (but dynamically created page) filled with links to items that belong to him. For example a link might be www.site.com/page.aspx?item_id=123. What is stopping him from clicking on that link, then altering the URL above to go www.site.com/page.aspx?item_id=456 which does NOT belong to him? I know some Java technologies like Struts (I stand to be corrected) store everything in the session and somehow work it out from that but I have no idea how this is done.

+12  A: 

If you don't want other users to see people information why don't you secure the page which you are using the id?

If you do that then it won't matter if you use an incrementing Id.

David Basarab
The pages are secure but I will need a list of items that belong to that user to appear in the page. So I don't want them to try and see items which aren't theirs by tampering with the URL.
uriDium
If the page is secure, how could they see items which aren't theirs by tampering?
Jon Skeet
LongHorn is saying if it was secured properly it wouldn't matter if they guessed the URL.
DJ
This is the right answer. Why do you (the questioner) care what people do if the site is secure?
paxdiablo
Let me try clarify, I am not talking about guessing URLs. Those pages will be protected and I will use .Nets Authentication and Authorization. I am talking about www.site.com/page.aspx?item=123 what is stoping him from changing the url to www.site.com/page.aspx?item=456 and item 456 is not his.
uriDium
You should check the userId of the user that is logged in. If there userId is 123 and they put item 456 123 != 456 reject them.
David Basarab
Is this a 3+ tier arch ? If so it seem to me that the "who can see what data" security should be enforced below UI layer. What if you want to open up the API to 3rd parties ? Or customer decide one day that they want an WPF app also on top of that ?
Petar Repac
"User can see only their items" have nothing to do with UI presentation.
Petar Repac
+2  A: 

You could randomly generate a number. Check that this number is not already in the DB and use it. If you want it to appear as a random string you could just convert it to hexadecimal, so you get A-F in there just like in your example.

webjunkie
+7  A: 

Raymond Chen has a good article on why you shouldn't use "half a guid", and offers a suitable solution to generating your own "not quite guid but good enough" type value here:

GUIDs are globally unique, but substrings of GUIDs aren't

Zhaph - Ben Duguid
Deleted my answer on the basis of this :) I still think that securing the pages properly and then using an incrementing ID is the best option.
Jon Skeet
Thanks, it's an excellent article on GUID anatomy! (and not because it made Jon Skeet remove his answer ;)
DK
Actually, reading that link and given he's using the same algorithm from the same machine, he could easily cut that from 16 bytes to 10 and still have room left over (128 - 48 - 6 = 74). Raymond even suggests trimming another 10 'uniquifier' bits, getting it down to 8 bytes.
Joel Coehoorn
Why's there not a badge for this? ;)
Zhaph - Ben Duguid
Agreed that properly securing the page and then using incrementing id's would be the way to go - infact there are good perf. reasons not to use a GUID or GUID-like as an id in a database, especially for indexed columns
Zhaph - Ben Duguid
A: 

How long is too long? You could convert the GUID to Base 64, which ends up making it quite a bit shorter.

Kibbee
+1  A: 

A GUID is 128 bit. If you take these bits and don’t use a character set with just 16 characters to represent them (16=2^4 and 128/4 = 32 chacters) but a character set with, let’s say, 64 characters (like Base 64), you would end up at only 22 characters (64=2^6 and 128/6 = 21.333, so 22 characters).

Gumbo
A: 

What you could do is something I do when I want exactly what you are wanting.

  1. Create your GUID.

  2. Get remove the dashes, and get a substring of how long you want your ID

  3. Check the db for that ID, if it exists goto step 1.

  4. Insert record.

This is the simplest way to insure it is obscured and unique.

Jeremy
+4  A: 

[In response to the edit]
You should consider query strings as "evil input". You need to programmatically check that the authenticated user is allowed to view the requested item.

if( !item456.BelongsTo(user123) )
{
  // Either show them one of their items or a show an error message.
}
Greg
I had just come to that conclusion :)
uriDium
+4  A: 

One interesting mechanism I've used in the past is to internally just use an incrementing integer/long, but to "map" that integer to a alphanumeric "code".

The following code shows a simple class that will change a long to a "code" (and back again!):

public static class ShortCodes
{
private static Random rand = new Random();

// You may change the "shortcode_Keyspace" variable to contain as many or as few characters as you
// please.  The more characters that aer included in the "shortcode_Keyspace" constant, the shorter
// the codes you can produce for a given long.
const string shortcode_Keyspace = "abcdefghijklmnopqrstuvwxyz0123456789";

// Arbitrary constant for the maximum length of ShortCodes generated by the application.
const int shortcode_maxLen = 12;


public static string LongToShortCode(long number)
{
    int ks_len = shortcode_Keyspace.Length;
    string sc_result = "";
    long num_to_encode = number;
    long i = 0;
    do
    {
        i++;
        sc_result = shortcode_Keyspace[(int)(num_to_encode % ks_len)] + sc_result;
        num_to_encode = ((num_to_encode - (num_to_encode % ks_len)) / ks_len);
    }
    while (num_to_encode != 0);
    return sc_result;
}


public static long ShortCodeToLong(string shortcode)
{
    int ks_len = shortcode_Keyspace.Length;
    long sc_result = 0;
    int sc_length = shortcode.Length;
    string code_to_decode = shortcode;
    for (int i = 0; i < code_to_decode.Length; i++)
    {
        sc_length--;
        char code_char = code_to_decode[i];
        sc_result += shortcode_Keyspace.IndexOf(code_char) * (long)(Math.Pow((double)ks_len, (double)sc_length));
    }
    return sc_result;
}

}

This is essentially your own baseX numbering system (where the X is the number of unique characters in the shortCode_Keyspace constant.

To make things unpredicable, start your internal incrementing numbering at something other than 1 or 0 (i.e start at 184723) and also change the order of the characters in the shortCode_Keyspace constant (i.e. use the letters A-Z and the numbers 0-9, but scamble their order within the constant string. This will help make each code somewhat unpredictable.

If you're using this to "protect" anything, this is still security by obscurity, and if a given user can observe enough of these generated codes, they can predict the relevant code for a given long. The "security" (if you can call it that) of this is that the shortCode_Keyspace constant is scrambled, and remains secret.

EDIT: If you just want to generate a GUID, and transform it to something that is still unique, but contains a few less characters, this little function will do the trick:

public static string GuidToShortGuid(Guid gooid)
{
    string encoded = Convert.ToBase64String(gooid.ToByteArray());
    encoded = encoded.Replace("/", "_").Replace("+", "-");
    return encoded.Substring(0, 22);
}
CraigTP
+1  A: 

Take your auto-increment ID, and HMAC-SHA1 it with a secret known only to you. This will generate a random-looking 160-bits that hide the real incremental ID. Then, take a prefix of a length that makes collisions sufficiently unlikely for your application---say 64-bits, which you can encode in 8 characters. Use this as your string.

HMAC will guarantee that no one can map from the bits shown back to the underlying number. By hashing an auto-increment ID, you can be pretty sure that it will be unique. So your risk for collisions comes from the likelihood of a 64-bit partial collision in SHA1. With this method, you can predetermine if you will have any collisions by pre-generating all the random strings that this method which generate (e.g. up to the number of rows you expect) and checking.

Of course, if you are willing to specify a unique condition on your database column, then simply generating a totally random number will work just as well. You just have to be careful about the source of randomness.

Emil
A: 

I have just had an idea and I see Greg also pointed it out. I have the user stored in the session with a user ID. When I create my query I will join on the Users table with that User ID, if the result set is empty then we know he was hacking the URL and I can redirect to an error page.

uriDium