Unique URL as an identifier

[Nel]

From your (group) opinion, when sending a unique URL to a user, what steps
are a must in making sure the link can't be hacked.

i.e. Bad link
www.example.com?id=10&action=reset_password
would be better as
http://www.example.com?id=505B6EF413...reset_password

But ultimately a hacker could work their way through all combinations and
reset all passwords on all users.

So you could use
http://www.example.com?id=505B6EF413...indexnumber=10
(probably not using dbindexnumber as a variable) That way the hacker would
need to get both right to reset the password.

But how far do you go reasonably, without getting paranoid?

Nel.

[Justin Koivisto]

Nel wrote:

From your (group) opinion, when sending a unique URL to a user, what steps
are a must in making sure the link can't be hacked.

i.e. Bad link
www.example.com?id=10&action=reset_password
would be better as
http://www.example.com?id=505B6EF413...reset_password

But ultimately a hacker could work their way through all combinations and
reset all passwords on all users.

So you could use
http://www.example.com?id=505B6EF413...indexnumber=10
(probably not using dbindexnumber as a variable) That way the hacker would
need to get both right to reset the password.

But how far do you go reasonably, without getting paranoid?

For that kind of thing what I usually do is generate a new unique key
for the action and store it in a database table with a structure similar to:

req_id varchar (md5 or other unique key)
user_id varchar (the user record id)
action varchar (the action to which this code is for)
issue_date datetime (just for tracking purposes)
expire_date datetime
verified int

Then I simply send the url like:

http://example.com/verify.php?reques...19c16b82c3b80e

At that page, if the record exists, ask for username or other
identifying information, and if that is good, process the action.

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

[Gordon Burditt]

>From your (group) opinion, when sending a unique URL to a user, what steps

are a must in making sure the link can't be hacked.
You check the authority of the user to perform the action *AT THE
TIME IT IS SUBMITTED*. (For example, you verify that the user is
logged in, although this is problematic with password changes. You
can, however, ensure that *NO* URL works if a password change hasn't
been requested, and that password change requests expire a few days
after they are requested.) This may seem to duplicate the check
when you produced the page, but it's not. In addition to link
hacking, something about the user may have changed (e.g. his account
expired and he didn't pay for the next month, or he got fired, or
he's not an authorized user on the account any more.)

If a user has to answer a security question ("What kennel was your
mother-in-law born in?") to even *get* that link, ask the same
question again when they try to *use* it.
i.e. Bad link
www.example.com?id=10&action=reset_password
would be better as
http://www.example.com?id=505B6EF413...reset_password

But ultimately a hacker could work their way through all combinations and
reset all passwords on all users.
That's a 128 bit hex number. Working their way through all combinations,
at 1 nanosecond per try, would take about 10 thousand billion billion years.
And I bet your server isn't nearly that fast. Be careful about your
random-number generator, though. A random number generator that uses
a 16-bit seed can reduce that time to 65 microseconds.
So you could use
http://www.example.com?id=505B6EF413...indexnumber=10
(probably not using dbindexnumber as a variable) That way the hacker would
need to get both right to reset the password.
This is a reasonable approach and it saves your server a bunch of
checking when it is submitted: it only has to check it against
one record, not all of them. If there is something public about
the account that is unique (such as a posting "handle" that appears
on notes posted to a forum), that might be better than the
db index.
But how far do you go reasonably, without getting paranoid?

I think something that takes more than a billion times your life expectancy
(the brute-force attack) isn't much of a concern. It's much more
likely that someone would manage to get access to the legitimate user's
computer or sniff packets.

Gordon L. Burditt

[Nel]

"Gordon Burditt" <go***********@burditt.org> wrote in message
news:11*************@corp.supernews.com...

From your (group) opinion, when sending a unique URL to a user, what
steps
are a must in making sure the link can't be hacked.

You check the authority of the user to perform the action *AT THE
TIME IT IS SUBMITTED*. (For example, you verify that the user is
logged in, although this is problematic with password changes. You
can, however, ensure that *NO* URL works if a password change hasn't
been requested, and that password change requests expire a few days
after they are requested.) This may seem to duplicate the check
when you produced the page, but it's not. In addition to link
hacking, something about the user may have changed (e.g. his account
expired and he didn't pay for the next month, or he got fired, or
he's not an authorized user on the account any more.)

If a user has to answer a security question ("What kennel was your
mother-in-law born in?") to even *get* that link, ask the same
question again when they try to *use* it.

i.e. Bad link
www.example.com?id=10&action=reset_password
would be better as
http://www.example.com?id=505B6EF413...reset_password

But ultimately a hacker could work their way through all combinations and
reset all passwords on all users.

That's a 128 bit hex number. Working their way through all combinations,
at 1 nanosecond per try, would take about 10 thousand billion billion
years.
And I bet your server isn't nearly that fast. Be careful about your
random-number generator, though. A random number generator that uses
a 16-bit seed can reduce that time to 65 microseconds.

So you could use
http://www.example.com?id=505B6EF413...indexnumber=10
(probably not using dbindexnumber as a variable) That way the hacker
would
need to get both right to reset the password.

This is a reasonable approach and it saves your server a bunch of
checking when it is submitted: it only has to check it against
one record, not all of them. If there is something public about
the account that is unique (such as a posting "handle" that appears
on notes posted to a forum), that might be better than the
db index.

But how far do you go reasonably, without getting paranoid?

I think something that takes more than a billion times your life
expectancy
(the brute-force attack) isn't much of a concern. It's much more
likely that someone would manage to get access to the legitimate user's
computer or sniff packets.

Gordon L. Burditt

Thanks to both of you for your comments.

Nel.