tags:

views:

83

answers:

3

Is it recommended to create a column (unique key) that is a hash. When people view my URL, it is currently like this:

url.com/?id=2134

But, people can look over this and data-mine all the content, right? Is it RECOMMENDED to go 1 extra step to make this through hash?

url.com?id=3fjsdFNHDNSL

Thanks!

+3  A: 

The first and most important step is to use some form of role-based security to ensure that no user can see data they aren't supposed to see. So, for example, if a user should only see their own information, then you should check that the id belongs to the logged-in user before you display it.

As a second level of protection, it's not a bad idea to have a unique key that doesn't let you predict other keys (a hash, as you suggest, or a UUID). However, that still means that, for example, a malicious user who obtained someone else's URL (e.g. by sniffing a network, by reading a log file, by viewing the history in someone's browser) could see that user's information. You need authentication and authorization, not simply obfuscating the IDs.

JacobM
Additional comment: hashes are completely predictable with a known text, still leaving you open to dictionary style attacks - applying a random salt to the hash can help - though depending on how you do it, you can still potentially leave yourself open to replay attacks. All this to underscore that you absolutely *must* implement a strong role based security mechanism.
Nathan
A: 

It sort of depends on your situation, but off hand I think if you think you need to hash you need to hash. If someone could data mine by, say, iterating through:

...
url.com?id=2134
url.com?id=2135
url.com?id=2136
...

Then using a hash for the id is necessary to avoid this, since it will be much harder to figure out the next one. Keep in mind, though, that you don't want to make the hash too obvious, so that a determined attacker would easily figure it out, e.g. just taking the MD5 of 2134 or whatever number you had.

Gordon Worley
A: 

Well, the problem here is that an actual Hash is technically one way. So if you hash the data you won't be able to recover it on the receiving side. Without knowing what technology you are using to create your web page it's hard to make any concrete suggestions, but if you must have sensitive information in your query string then I would recommend that you at least use a symmetric encryption algorithm on it to keep people from simply reading off the values and reverse engineering things.

Of course if you have the option - it's probably better to not have that information in the query string at all.

Streklin
The hash is one way, but in this case it is only used as an obfuscation technic to emulate a global-id with perhaps more randomness, so as long as the hash is stored in the database alongside its 'id', there is no need for encryption.
Matthieu M.
Ah ok - I misunderstood the question.
Streklin