views:

145

answers:

2

Hi, I'm using ASP.NET and the membership provider for my site. If the user is able to easily see their GUID, would that be considered a security risk? Should I take extra steps to prevent users from easily finding their GUID such as when they confirm their verification process. Although there are ways around this, such as using a seperate GUID for 'front-end' activities, is this an unnecessary increase in overheads and development time?

An example of possible spoofing is when I'm authenticating a user's permission to access a resource.

Guid cUser = (Guid)Membership.GetUser().ProviderUserKey; //if this is publicly viewed, then  there's no reason to call the DB or store in a session as it can be placed in the QueryString
bool grantAccess = CheckGroupPermission(cUser, groupID);

Thanks

+2  A: 

It is generally not a good idea to expose keys to a database to the outside world, but if you had to choose what kind of field to expose, a GUID is not that bad of a choice. It is much better than exposing a sequence number where it can be guessed (rather easily) what constitute an unknown valid identifier in a DB.

You can, instead of providing the GUID to the outside world, provide the username. It should be unique.

Wayne Hartman
In my case, the username is the user's email address. I may be wrong, but would displaying a unique username be no different from displaying the GUID since at the backend, they'd be used appropriately? i.e. a user spoofs the username, which is then converted to the GUID at the backend anyway, thus granting the same access as directly inputting the GUID. Thanks.
keyboardP
True, but by exposing the username, you are not exposing the inner workings of your application the way you would via another identifier.
Wayne Hartman
Ah, fair enough. Thanks for your help.
keyboardP
+4  A: 

No, displaying the id of the user record is not a security risk in itself. You should not rely on it being secret anyway, as it would be hard to make yourself totally independent of them.

It is however a security risk if you are using only the id as verification to grant access to resources. You can never rely completely on any information sent from the client, you should always use some information that can't be tampered with so easily, like a value in a session variable that is only placed there after proper user verification.

Guffa
Would you suggest that I use "Session["userID"] = Membership.GetUser().ProviderUserKey;" (at some event such as page_load), and then use the session for future authentication? Or are there further steps I should be taking? Thanks
keyboardP
@Tenaciouslmpy: Using a session variable only withing the page is pointless. Set the session variable at the login page where you have the full authentication, then use it throughout the session. If the ProviderUserKey already is based on session data, you can of course use that instead.
Guffa
The problem with using ProviderUserKey is that it hits the database everytime it's called, so I thought it'd be easier to store in a session. Good call on the login page authentication!Thanks for the help.
keyboardP