Whidbey Security Flaw (MembershipUser)

Revisiting the MembershipUser class, there is something that has perplexed me since day one. Why is there not a UserID associated with it? The simpleton might respond, “but is has a Username property and those are gaurenteed to be unique!” To which I would respond, “yes, until 'jsmith' is fired then another 'jsmith' comes along, you add him to the DB, and now any tables that referenced his username have all of the old 'jsmith''s data.” Of course, some of this can be solved by adding events to the base Membership providers (such as “UserDeleted”), so that you can actually remove user data from the DB if someone deletes them (which should probably happen anyway...), but that requires the user handling those events. If we want things “secure by default,” the solution is to give a proper ID in the first place that will continue to be unique (under AD, you can get the “objectSid” prop, in SQL it will most likely be an identity field or GUID).

4 Comments

  • Jesse, please take the time look at the sql tables and you'll see that we do use a unique user id. It is assigned to all usernames in the aspnet_Users tables. In fact we use a guid, all other tables, such as aspnet_Membership, aspnet_UsersInRoles, etc. use the userid guid as the fk not the username.

  • Yes, you do, but you cannot get access to this member via the interfaces, which makes it pretty useless to any code that utilizes them. What I am suggesting is that you expose that ID as a property.

  • We are planning on adding a unique id other than the username through the APIs. What we will likely do is add a property on MembershipUser called UserID that returns type string and in the case of our providers return a string version of the GUID, similar to what we've done with Request.AnonymousId.



    The title of the post is a little misleading, mainly because

    1. We take security concerns very seriously

    2. It's an Alpha

    3. We're not claiming that everything is complete.

    4. We take security concerns very seriously (repeated)



    I understand the desire to blog about it - which we love - but for design issues such as this please don't just make sweeping assumptions, just drop me a note (rhoward@microsoft.com) or just ask.

  • I understand it's an alpha, which is why I have been blogging what appear to be issues as I find them (so that they will hopefully get fixed before the final if you haven't already fixed them). It's definately nice to know it is going to be fixed in any case.

Comments have been disabled for this content.