Re: Unique URL as an identifier



"Gordon Burditt" <gordonb.xot15@xxxxxxxxxxx> wrote in message
news:11vk551qp60gc3f@xxxxxxxxxxxxxxxxxxxxx
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
Thanks to both of you for your comments.

Nel.


.



Relevant Pages

  • Re: Unique URL as an identifier
    ... You check the authority of the user to perform the action *AT THE ... can, however, ensure that *NO* URL works if a password change hasn't ... and that password change requests expire a few days ... something about the user may have changed (e.g. his account ...
    (comp.lang.php)
  • Re: Payment Sent to Wrong Account
    ... that the payroll co *intended* to make the mistake! ... The dosh went into the account the payrollco sent it to at the time they ... On the authority of both the sender and the recipient, ... specific requests from both of them. ...
    (uk.finance)
  • RE: cannot log on to user account following password change
    ... please paste them in the newsgroup. ... cannot log on to user account following password change ...
    (microsoft.public.windows.server.sbs)
  • Re: Password change and cached credentials
    ... and that's with a correct username and password for a domain ... password on the cached credentials machine ... ... remember the password change is not an option, ... > domain user account gets access to resources on the domain by logging on ...
    (microsoft.public.win2000.security)
  • Re: Advanced Password Policies
    ... Unfortunately even a password filter won't help you here. ... filters only get the new password during a password change, ... The current userpassword is 'welcome01' and I want to prevent ... compromised account could create. ...
    (microsoft.public.windows.group_policy)

Loading