2

I've noticed that SO and other sites use the auto-incrementing primary key of the user table as a publicly viewable user id (at least I assume this is what they are doing). In the case of SO, the user's profile can be viewed if you know or can guess their user id.

What are some things to consider before implementing a similar style of user id generation? I am developing a non-commercial app that relies on the concept of "friends" in assigning various permissions between users, but I'd like all users' basic profiles to be viewable at a simple url such as app.com/users/userid. More detailed profile information would only be accessible to "friends" of that user who have been confirmed by that user.

I guess my question is this does the "guessability" of a user ID indicate anything about the inherent security of a system like this or, is that all in the way that individual features are actually implemented? Is there anything I might not be considering about this that would make it unwise? Anything I should absolutely avoid doing with these user ids?

A note: I have no concern for "competitors" knowing or guessing how many users I have based on the number of the most recent user or the rate of change between users.

Marcus Adams
  • 53,009
  • 9
  • 91
  • 143
itsmequinn
  • 1,054
  • 1
  • 8
  • 21
  • 1
    i give every user both an auto-inc id and a 32 char random hash, depending where i use them, the hash offers protection from guessing an id. –  Feb 23 '12 at 19:46
  • I agree with @Dagon. Keys link your tables together, you can also create unique 'IDs' that can be publicly shared and still be used to identify individual records. These IDs can be changed, whereas keys should _never_ be changed. – Jeff Lambert Feb 23 '12 at 19:48
  • This has been asked before, feel as well free to search the site to find some insightful previous discussions, e.g. [Using a “custom” user ID as opposed to the user's real, auto_incremented database ID in web applications?](http://stackoverflow.com/questions/3739833/using-a-custom-user-id-as-opposed-to-the-users-real-auto-incremented-databas) or [Is mysql auto increment safe to use as userID?](http://stackoverflow.com/q/8078912/367456) – hakre Feb 23 '12 at 19:50
  • I've been been searching half the day and couldn't really find anything that was exactly what I was interested in. The two comments already are hugely helpful in that I didn't really gather from all of the discussion on this topic that a user id and the auto_increment id from their record in a table might be two different things – itsmequinn Feb 23 '12 at 19:53
  • What can I get if I guess an ID in your proposed system? Does it affect privacy? Does it affect security, eg. is the ID their login ID? Do you care about scraping? Do you believe in security through obscurity? – Marcus Adams Feb 23 '12 at 19:55
  • @Dagon: As you do this, can you present some example code how you do that so it's more visible what exactly you're doing? – hakre Feb 23 '12 at 19:57
  • I guess that is my question. As far as I know, nothing will be gained from a person knowing my id except to view my page and see whether they are a friend to me or not. What I'm wondering is whether (as someone new to programming in general) there might be some way for a person to access more information than I want then to be able to access based on this information floating around publicly. I'm thinking no as long as I have a secure authentication system and make sure not to allow access to the information based on user id alone, but is that safe to assume? – itsmequinn Feb 23 '12 at 19:59
  • Sounds like id alone is safe for you. I require better security, so id and hash (random) for all users. All external communications use the hash, all internal use the the id. Id never exposed to the 'outside' world. you want to think about a few specifics like unsubscribe or sign ups, you don't want a guessable id sent in an email that is used to preform 'security functions. But of course there are other ways to take care of this –  Feb 23 '12 at 20:05
  • Yes, I do have a separate "requests" table that uses a hash for friend request confirmations and I do assign a hash to each user's account for the purpose of account verification, but I guess I just didn't think of them as user ids, even though each user has one... Thanks – itsmequinn Feb 23 '12 at 20:09
  • there is the scrapping issue to consider, *if* that's a problem, scrapping by looping through 1,2,3 etc is easy, not so easy on 32 char random strings. –  Feb 23 '12 at 20:11
  • I still don't buy that obscure URLs buy you much protection. If you're doing the security in the right place then they don't add anything (except, perhaps, more irritating URLs). If they're your only security then this is terrible. If someone gets hold of a URL (which could happen in many ways) the user can't revoke access. They could if someone nicked their password; by changing it. – Kevin Hughes Feb 23 '12 at 20:24

2 Answers2

2

OWASP - Insecure Direct Object References

Gives a pretty good treatment of the subject. In fact, I highly recommend OWASP in general for security guidelines when developing web applications. I always evaluate my web projects against the TOP 10 security threats found on the site.

Devin
  • 559
  • 4
  • 14
1

It's not a problem at all. In fact, I'd almost say the opposite: if you're having to obscure the params in the URL for security then you're doing it wrong; the security should be handled in the code.

From your question, it looks like you're already thinking about security the right way, so you should be fine with the primary key in the URL.

Having a primary_key which stores no information (like an auto_incremented id) is also good because it will never change. If you're putting info like the username in URLs you'll either want to never implement people being able to edit their usernames, or cope with the broken links that may be left when they do (remember they may be on sites other than yours).

The only info having the auto_incremented id in your URLs could leak is that one user will know if they were a user before or after another. This is unlikely to be a concern (and might not be reliable anyway).

Kevin Hughes
  • 600
  • 7
  • 18
  • 1
    Just make sure you make their login id different. Everybody will want the lower number because lower numbers are cool. :) – Marcus Adams Feb 23 '12 at 20:02
  • @ Marcus Adams And to be honest, I kind of like that which is why I really want to use this as a user id if it's not inherently dangerous. Thanks! – itsmequinn Feb 23 '12 at 20:04