Posted by Gordon Burditt on 10/22/53 11:40

>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
>www.example.com?id=505B6EF41388913908D9B65B35DEAAEE&action=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
>www.example.com?id=505B6EF41388913908D9B65B35DEAAEE&action=reset_password&dbindexnumber=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

[Back to original message]