Rename URL to hide values

[vanroojdotcom]

At the moment I have a url parameter like this example.php?userID=1 ~ which
means people will type in 2, 3, or four to see the web page of those users.

So I created a column in the user table to create a 32 random number
md5(uniqid(rand(), true)), so it now looks like this
example.php?userID=1234refdgtf5768594320 (etc) which makes it very difficult
for people to guess other user's IDs. The chance of a duplicate 32 random
number is very unlikely. HOWEVER!

I kind of like the idea of merging the user ID (auto_increment) column AND the
random number column, to make absolutely sure that there won't be duplicate ID
keys. AND also to rename the ULR parameter to a completely innocent looking one.

So the Recordset would be something like this:

SELECT * CONCAT(users.userID, users.userTab) AS innocentURL
FROM users
WHERE innocentURL = colname

So the resulting url would look like this (the first 1 being the number from
the userID)

example.php?innocentURL=1eagfd23456789gverdirto667890

Is this possible?

many thanks
vanrooj

[Michael Fesser]

.oO(vanroojdotcom)

>At the moment I have a url parameter like this example.php?userID=1 ~ which
>means people will type in 2, 3, or four to see the web page of those users.

If user 1 is not supposed to see the page of user 4, you have to capture
that in your application. You must always test on each and every page if
the current user is authorized to view it. Of course user 1 might still
try to access other pages, but then all he should get would be an error
message or the login form again.

> So I created a column in the user table to create a 32 random number
>md5(uniqid(rand(), true)), so it now looks like this
>example.php?userID=1234refdgtf5768594320 (etc) which makes it very difficult
>for people to guess other user's IDs.

_Never_ rely on security by obscurity! It's not going to work. There are
a dozen ways how even an obscured or "hidden" URL may leak or be broken/
guessed. So the hash doesn't serve any purpose in this case. Instead you
should fix the authorization bug in your code.

Micha

[vanroojdotcom]

Thanks for the reply - however- it's not really security issue; it like the URL
at the top, forumid=12&catid=217&threadid=1436836&enterthread=y

This is not a log-in out it just lists articles from a database:

userID=1 "Headline_01"
userID=2 "Headline_02"

By switching the number you can view a different article (read a different
story) I don't want people to change the URL at the top to see a different
article. As the database is new and = 1 it's pretty obvious and tempting to
change the number to 2! I want the url to be random so that it's not obvious
what the other articles are named, but I don't want the articles to have the
same random number, so I want to join the article random ID with the
auto_increment primary key ID to make sure two articles are not pulled, if they
happen to have the same random number.

many thanks
vanrooj

[Michael Fesser]

.oO(vanroojdotcom)

>Thanks for the reply - however- it's not really security issue; it like the URL
>at the top, forumid=12&catid=217&threadid=1436836&enterthread=y
>
> This is not a log-in out it just lists articles from a database:

OK. But then I don't understand the problem.

> userID=1 "Headline_01"
> userID=2 "Headline_02"
>
> By switching the number you can view a different article (read a different
>story)

Indeed. But I consider that a good thing. It would also keep the URL
shorter and more "human-friendly".

>I don't want people to change the URL at the top to see a different
>article.

Why not? It doesn't really makes sense to me trying to prevent that.

>As the database is new and = 1 it's pretty obvious and tempting to
>change the number to 2! I want the url to be random so that it's not obvious
>what the other articles are named, but I don't want the articles to have the
>same random number, so I want to join the article random ID with the
>auto_increment primary key ID to make sure two articles are not pulled, if they
>happen to have the same random number.

Why not simply hash the article number? Should be obscure enough, while
still being (almost) unique. But as said - even this is too much effort
for nothing, IMHO.

Micha

[vanroojdotcom]

There are many reasons why I don't want userID=1 - part of which is
visualization, (I think it makes the website seem more impressive) second I for
what ever reason want to control the entry point into each section and to get
the visitor to come back to the home page rather than concentrating on the
exciting game of "I wonder what comes up if I change the ID to 47"

It's not that I want to 'prevent' it just to discourage it - a random set of
numbers is not going to catch the eye of a curious browser but =123456 is - its
just waiting to change the last digit.

But anyway... wondered if it was possible to do.

[vanroojdotcom]

Thanks for the input - i appreciate your views and your preference.

There are many reasons why I don't want userID=1 - part of which is

visualization, (I think a long random set of number makes the URL blend into
the background more + gives no indication to its size) second I want to control

the entry point into each section and to get the visitor to come back to the
home page rather than concentrating on the exciting game of "I wonder what
comes up if I change the ID to 47"

It's not that I want to 'prevent' it just to discourage it - a random set of

numbers is not going to catch the eye of a curious browser but =123456 is.

But anyway... I don't think we agree on this solution -
but wondered if anybody knows how to do it.

[vanroojdotcom]

Plus, it's bugging me that I don't know.

[Michael Fesser]

.oO(vanroojdotcom)

> But anyway... I don't think we agree on this solution -

Seems so. Anyway.

> but wondered if anybody knows how to do it.

I already posted a simple idea - you could just hash the article number.
Assuming MD5, you would get

1 => c4ca4238a0b923820dcc509a6f75849b
2 => c81e728d9d4c2f636f067f89cc14862c
3 => eccbc87e4b5ce2fe28308fd9f2a7baf3
...

Some people might guess that this could be an MD5 hash and might still
play with it, but most users won't even know what a hash is.

Micha