0

I am creating a soap service where users will be able to interact with each other. They will have a contact list where people can be added. One of the security measures(others are in place, too) is to have a local ID assigned to a contact.

To make the process clear, imagine the following scenario:

$UserA prompts $UserB to be added to $UserA's contact list. $UserB accepts and $UserA receives a local ID to use as UserID referring to the contact. The database contains a table called USER_MAP(LocalID,UserID).

Two questions:

1) Do you think this is a valid approach when dealing with user ids security? If not, why? 2) If you deem it valid, can you suggest a formula to generate said IDs?

At the moment, the idea for the formula is: ($UserA_ID+$UserB_ID)*($UserA_RegDate+$UserB_RegDate)

Consider RegDates as being in "number of days since the 0 date value".

Each user might have 1..N local ids depending on how many users are willing to add. A local ID is local to the user but global in the user space, i.e. for every interaction between users the same local id is used. To make it clearer: if $UserA requests to see $UserB profile, he will be passing the local user id which will be mapped at the server level to the correct id.

Just to make it clear: future does not mean "in a long time from now, maybe, who knows", rather means : "it is planned, I want to do it, I want to make sure I have my pieces ready and THEN I will do it" :) Thus, it's not a "maybe" rather just a matter of WHEN.

Apparently someone has issues understanding the logic behind the approach of a local id. A couple ideas that can help you understand why it's a good idea(in my opinion):

  • If your ID is local instead of global, you have only access to your own resources/contacts. Useful for instance to avoid programmatically getting access to a profile you wouldn't be allowed to see. This with third parties may be a problem, especially in case of unfair uses

  • If your ID is local, you can use it as a shortcut for local data instead of having to go to the original account. The contact list could, for instance, hold some of the original data which isn't going to change.

  • If you have a local id it's much easier to "cut the wire", because all you have to do is deleting one or two records. Say that a user wants to delete a contact. All I will have to do is to remove at best two records, all the other data stays there untouched and simply filtered out by the queries.

Better now?

Thank you for your time!

Improve this question
2
  • What do you gain by using these local id's instead of global ones? I'm not sure I understand the advantage of this. Commented Jun 13, 2011 at 8:21
  • There are multiple, actually: 1) You might want(not atm, but in future) let users bookmark profiles to be viewed on the web. Using a local id does not expose the original database id 2) It lets third parties(always, in future) create their own clients and feel safe in using the ID, knowing it will map correctly. It's the kind of thing you want to give less hooks to malicious users while opening your system to third parties or the web. Commented Jun 13, 2011 at 8:31

2 Answers 2

Reset to default
1

Unless you have a feature that requires this right now, you are over-engineering this. Don't make your solution more complicated than it has to be. If you get to the point where this is required, refactor your application to make it work, but don't try to anticipate what you might need or not need in the future.

BTW, if you do have the ability to successfully anticipate what you need in the future, then please contact me off-list. :-)

Improve this answer
5
  • LOL! I know I will need it, because I have a plan of what I want to do - and this plan includes opening the API to third parties, so, yes, I can tell before hand what I will need in future - given certain constraints :) Commented Jun 13, 2011 at 10:12
  • 1
    I still think it's over-engineered. The IDs will be numbers, so what if somebody can retrieve some numbers. Unless they can access the context, these numbers are just that. In their own context they have meaning, outside of that they don't. I would just use aut-increment integers and be done with it. Commented Jun 13, 2011 at 10:28
  • And you would have a problem the very moment you'd want to open the API to the third parties :) Allowing too much custom behaviour to be added when dealing with actual data. Let alone malicious users(who will still try to get data they shouldn't be accessing) it can be a problem with legit but imperfect clients. As I said, this is just one of the measures taken to counter problems. Commented Jun 13, 2011 at 10:49
  • 2
    I still don't get it, how would knowing IDs compromise security and if it would, how would having local IDs prevent it given that you still have a table in your db which maps the local IDs to global ones. Could you send a link to some resources which would explain the rationale to me? Commented Jun 13, 2011 at 12:15
  • The only problem is that changing an API in the future is quite expensive when dealing with 3rd parties. Commented Jun 13, 2011 at 14:25
0

A better approach to security would be to simply not allow something like a userid to be a critical piece of information. As an attacker, table names and queries are more interesting than key values.

The data in the table may be the final goal (perhaps you have Social Secuirty # in the user's personal table or patient medical records) but having the user id shouldn't get me any closer to that. All of the sensitive information should be encrypted and the private key isn't stored anywhere in the system.

What is useful to me, the attacker, is to find out which of your APIs lead to queries that don't have proper security wrappers. Maybe then I can promote myself to a super user and start making direct calls into the DB and hopefully find something unprotected. The more I know about your structure, the faster I can pull it off. Then I just hope you were too overconfident to bother protecting the data inside (e.g. Sony).

Improve this answer
1
  • This is interesting - mind to expand what you mean here? Commented Jun 13, 2011 at 15:08

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.