I have a client that provides a list of companies on their web site (powered
by PHP/MySQL.) These companies advertise their services to visitors. The
company information has been maintained exclusively by the client, but now
they would like to provide a way for the companies to update their own
information.

Can someone suggest a reasonable secure method to allow the companies to
edit their own information without a login and authentication procedure? One
idea is to provide each customer an URL which includes an encrypted token.
The token could be generated using a unique piece of data like an email
address or telephone number. It could be decrypted serverside and validated.
I've done something similar for other clients on a tight budget and it
worked well, but am wondering if there's a better approach without adding
full-fledge authentication.

All comments/suggestions are appreciated.

>I have a client that provides a list of companies on their web site (powered[color=blue]
>by PHP/MySQL.) These companies advertise their services to visitors. The
>company information has been maintained exclusively by the client, but now
>they would like to provide a way for the companies to update their own
>information.
>
>Can someone suggest a reasonable secure method to allow the companies to
>edit their own information without a login and authentication procedure? One
>idea is to provide each customer an URL which includes an encrypted token.[/color]

I hope that's a http*S* URL.

What's the real difference between something like:

https://www.mysite.com/cgi-bin/editm...corp&pw=hackme

vs., say, a .htaccess setup (on a secure site) where the client has
to provide the user name 'bigcorp' and the password 'hackme'?
The only important difference I see is that the URL probably gets
cached in the client's browser, and that might be a weakness.

[color=blue]
>The token could be generated using a unique piece of data like an email
>address or telephone number. It could be decrypted serverside and validated.[/color]

The token itself *IS* the password. What it contains after you
decrypt it is irrelevant. You don't have to decrypt it to get in.
It might be a big problem if someone can figure out your token-generating
scheme and guess *ALL* of them. It's more secure to generate the
token from something more random, like coin flips.
[color=blue]
>I've done something similar for other clients on a tight budget and it
>worked well, but am wondering if there's a better approach without adding
>full-fledge authentication.[/color]

Unless your clients like to see their info changed to something obscene,
I suggest they spring for triple-fledge authentication.
[color=blue]
>All comments/suggestions are appreciated.[/color]

Gordon L. Burditt

In article <%CEgd.332796$3l3.106562@attbi_s03>,
"Bosconian" <bosconian@planetx.com> wrote:
[color=blue]
> I have a client that provides a list of companies on their web site (powered
> by PHP/MySQL.) These companies advertise their services to visitors. The
> company information has been maintained exclusively by the client, but now
> they would like to provide a way for the companies to update their own
> information.
>
> Can someone suggest a reasonable secure method to allow the companies to
> edit their own information without a login and authentication procedure? One
> idea is to provide each customer an URL which includes an encrypted token.
> The token could be generated using a unique piece of data like an email
> address or telephone number. It could be decrypted serverside and validated.
> I've done something similar for other clients on a tight budget and it
> worked well, but am wondering if there's a better approach without adding
> full-fledge authentication.
>
> All comments/suggestions are appreciated.[/color]

Allowing only a specific IP address to access and change a page is about
the closest you'll get to any sort of unique access. It's not very
secure and I think any sort of proxy server in between the client and
the server won't correctly send the IP address. This is the nature of
stateless client/server systems.

I'd push back with this client and point out the benefits of some sort
of authentication with usernames and passwords. Add a SSL certificate
and it will be even more secure. You're essentially being asked to
build a car without any sort of internal combustion engine.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Thanks for your replies.

I completely concur that username/password authentication is the way to go.
SSL, while the most secure, is not essential since there's no confidential
or financial information being stored or shared.

I will "push back" with the client and tell them they'd be better off
continuing to edit the information themselves without implementing proper
authentication (albeit sans SSL.)

<Michael Vilain <vilain@spamcop.net>> wrote in message
news:vilain-2DD758.23172629102004@news.giganews.com...[color=blue]
> In article <%CEgd.332796$3l3.106562@attbi_s03>,
> "Bosconian" <bosconian@planetx.com> wrote:
>[color=green]
> > I have a client that provides a list of companies on their web site[/color][/color]
(powered[color=blue][color=green]
> > by PHP/MySQL.) These companies advertise their services to visitors. The
> > company information has been maintained exclusively by the client, but[/color][/color]
now[color=blue][color=green]
> > they would like to provide a way for the companies to update their own
> > information.
> >
> > Can someone suggest a reasonable secure method to allow the companies to
> > edit their own information without a login and authentication procedure?[/color][/color]
One[color=blue][color=green]
> > idea is to provide each customer an URL which includes an encrypted[/color][/color]
token.[color=blue][color=green]
> > The token could be generated using a unique piece of data like an email
> > address or telephone number. It could be decrypted serverside and[/color][/color]
validated.[color=blue][color=green]
> > I've done something similar for other clients on a tight budget and it
> > worked well, but am wondering if there's a better approach without[/color][/color]
adding[color=blue][color=green]
> > full-fledge authentication.
> >
> > All comments/suggestions are appreciated.[/color]
>
> Allowing only a specific IP address to access and change a page is about
> the closest you'll get to any sort of unique access. It's not very
> secure and I think any sort of proxy server in between the client and
> the server won't correctly send the IP address. This is the nature of
> stateless client/server systems.
>
> I'd push back with this client and point out the benefits of some sort
> of authentication with usernames and passwords. Add a SSL certificate
> and it will be even more secure. You're essentially being asked to
> build a car without any sort of internal combustion engine.
>
> --
> DeeDee, don't press that button! DeeDee! NO! Dee...
>
>
>[/color]

>I completely concur that username/password authentication is the way to go.[color=blue]
>SSL, while the most secure, is not essential since there's no confidential
>or financial information being stored or shared.[/color]

But the PASSWORD is confidential information (I hope) ...

It does matter what the password is protecting, but in this
case it seems to be protecting the ability to CHANGE information
rather than the ability to see it.

Gordon L. Burditt