Unique identity string for data records

Steve777 · #1 (**permalink**) August 17th, 2009, 05:46 PM

Hi,

I am writing a classic ASP application, and need to display a web page to which is passed (in the query string) the identity field of a record in my database. Currently, these are auto-numbered identity fields (value of 1,2,3...). However, if I do this, anyone can take a guess at a value and attempt to hack into the details for a record they should not have access to. Am I right in thinking that the very long alphanumeric strings you sometimes see as values in a query string are a way to combat this problem? If so, what is the best way to generate such a string for the "identityString" field of a record, ensuring it is unique? Otherwise, please can you tell me how to address this issue so as to provide the appropriate security for my data.

Many thanks.

Imar · #2 (**permalink**) August 17th, 2009, 06:09 PM

Hi there,

What you are referring to is called "security by obscurity" which is a bad thing. E.g. you think your application is safer because data is harder to guess. However, it's still open and guessable, and thus insecure.

Is it an option to check on the destination page whether the user has the correct permissions? E.g.:

Quote:

contentId = Request.QueryString("Id")
If CheckUser(contentId) = False Then
Response.Redirect("NoRights.asp")
End If

' Get the item from the database.

Your CheckUser method could then check whether the user is allowed to view the item or not. How you check that depends on your application.

BTW: I think the long IDs you are referring to are not obscured simple IDs, but true, long IDs. Windows, for instance, has the notion of a GUID - a Globally Unique Identifier which is typically a long string (36 characters if I am not mistaken). It's not obscured, it's just very unique and thus very long ;-)

Hope this helps,

Imar

Old Pedant · #3 (**permalink**) August 17th, 2009, 08:59 PM

Quote:

What you are referring to is called "security by obscurity" which is a bad thing. E.g. you think your application is safer because data is harder to guess. However, it's still open and guessable, and thus insecure.

And even if a user can't guess a different id, he/she can copy/paste *THAT* ID and pass it all around the internet for anybody and everybody to see. And then who knows what will happen?

You really should be checking the user's status, as Imar suggested. Usually, Session variables are the easiest thing to use with ASP and they are indeed pretty darned secure. As secure as the userid/pasword system that you use to login users, say.

If you are not currently requiring logins, then you will always be somewhat vulnerable. It goes with the territory.

Steve777 · #4 (**permalink**) August 18th, 2009, 04:08 AM

Imar and OP, thank you very much - that's very helpful. I do indeed have a session variable set for the logged-in user, so I assume the right approach is to simply use the basic autonumbered identity (1,2,3...) in the query string, and before returning the data from the database check that the record it matches also matches the id of the logged-in user. Is this correct?

Also, out of interest, Imar, you mention true, long IDs are the things I will have seen sometimes in a URL. Is this not exactly the method I was suggesting? Why are those IDs something other than what you describe as obscured simple IDs? And why could they not be passed around by people in the way that OP describes? I would be grateful if you would educate me on the differences in these things. Thanks.

Imar · #5 (**permalink**) August 18th, 2009, 04:50 AM

Quote:

and before returning the data from the database check that the record it matches also matches the id of the logged-in user. Is this correct?

Yes, that's exactly what I had in mind.

The GUIDs I was referring to are globally unique. This makes them great for disconnected systems that need to exchange data. That is, you and I can generate a GUID on our system, and then when we merge data later there's no risk of you and I having the same key. With a simple identity this is more than likely. (e.g. you and I can both have an ID of 10 for two separate records). However, GUIDS are used more and more to just uniquely identify a record within a single system.

If you are working with SQL Server, Guids are a built-in type called uniqueidentifier. Just like your ID / identity column you can make this ID the primary key and assign it a default value of newid(). Then when you insert a new record SQL Server creates an ID in the form of A35B61E6-54DE-4B2F-816E-9982B95D35AE for you. Other databases might have similar constructs. (Microsoft Access has something called the ReplicationID which is similar).

Guids are nnot obscured. What you see is the real ID. That is, A35B61E6-54DE-4B2F-816E-9982B95D35AE in a query string is truely A35B61E6-54DE-4B2F-816E-9982B95D35AE in the database. This means they are open, just like plain IDs such as 34 or 56. They can still be passed around as plain IDs. As OP pointed out, they are just as forwardable to somebody else as plain IDs. The only difference is that they are harder to guess. WIth an ID of 56, it's easy to guess the next one. WIth an ID of A35B61E6-54DE-4B2F-816E-9982B95D35AE, this is slightly more difficult.... ;-) But other than that, they are pretty much the same as numeric identities in terms of security.

Hope this claridfies things.

Cheers,

Imar

Steve777 · #6 (**permalink**) August 18th, 2009, 06:01 AM

Thank you, Imar - that's really helpful.

Need to download code?

Navigation