How to secure this

Hi everyone

There may be blinding bits of total ignorance in this so don't ignore
the obvious.

This is a security question, but a sentence of background: I'm writing
software for a mapping/location website and I want to be able to provide
something others can plug into their website that would display their map.

So I'm providing a URL like
http://www.mydomain.com?h=300&w=250&username=name&password=p assword

The idea is they can define their own height and width and it plugs in
as an iframe.

That takes the username and password and throws it over web services to
get back the data from which we can create the map.

My question (and it might be the wrong question) is how can I not give
away the password to all and sundry yet still provide a self-contained URL?

Thanks in advance :-)

Cheers
J



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: How to secure this

John Allsopp wrote:
> Hi everyone
>
> There may be blinding bits of total ignorance in this so don't ignore
> the obvious.
>
> This is a security question, but a sentence of background: I'm writing
> software for a mapping/location website and I want to be able to provide
> something others can plug into their website that would display their map.
>
> So I'm providing a URL like
> http://www.mydomain.com?h=300&w=250&username=name&password=p assword
>
> The idea is they can define their own height and width and it plugs in
> as an iframe.
>
> That takes the username and password and throws it over web services to
> get back the data from which we can create the map.
>
> My question (and it might be the wrong question) is how can I not give
> away the password to all and sundry yet still provide a self-contained URL?

MD5() (or SHA()) hash the information and supply that along with the
settings. Then you know it was generated by your site. So you can do the
following:


$height = 300;
$width = 250;
$username = 'username';
$key = md5( "SECRET_SALT-$heigh-$width-$username" );

$url =
"http://www.mydomain.com?h=$height&w=$width&username=$userna me&key=$key";

?>

Then when you get this URL via the iframe, you re-compute the expected
key and then compare it against the given key. Since only you know the
SECRET_SALT value then nobody should be able to forge the key.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: How to secure this

--=-yCdE3nxJKKwlPnNY9lyu
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:

> John Allsopp wrote:
> > Hi everyone
> >
> > There may be blinding bits of total ignorance in this so don't ignore
> > the obvious.
> >
> > This is a security question, but a sentence of background: I'm writing
> > software for a mapping/location website and I want to be able to provide
> > something others can plug into their website that would display their map.
> >
> > So I'm providing a URL like
> > http://www.mydomain.com?h=300&w=250&username=name&password=p assword
> >
> > The idea is they can define their own height and width and it plugs in
> > as an iframe.
> >
> > That takes the username and password and throws it over web services to
> > get back the data from which we can create the map.
> >
> > My question (and it might be the wrong question) is how can I not give
> > away the password to all and sundry yet still provide a self-contained URL?
>
> MD5() (or SHA()) hash the information and supply that along with the
> settings. Then you know it was generated by your site. So you can do the
> following:
>
> >
> $height = 300;
> $width = 250;
> $username = 'username';
> $key = md5( "SECRET_SALT-$heigh-$width-$username" );
>
> $url =
> "http://www.mydomain.com?h=$height&w=$width&username=$userna me&key=$key";
>
> ?>
>
> Then when you get this URL via the iframe, you re-compute the expected
> key and then compare it against the given key. Since only you know the
> SECRET_SALT value then nobody should be able to forge the key.
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>


What about requiring them to sign in the first time to use your service,
and then give them a unique id which i tied to their details. You could
then get them to pass across this id in the url. You could link their
account maybe to some sorts of limits with regards to what they can
access maybe?

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-yCdE3nxJKKwlPnNY9lyu--

Re: How to secure this

Ashley Sheridan wrote:
> On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:
>
>> John Allsopp wrote:
>>> Hi everyone
>>>
>>> There may be blinding bits of total ignorance in this so don't ignore
>>> the obvious.
>>>
>>> This is a security question, but a sentence of background: I'm writing
>>> software for a mapping/location website and I want to be able to provide
>>> something others can plug into their website that would display their map.
>>>
>>> So I'm providing a URL like
>>> http://www.mydomain.com?h=300&w=250&username=name&password=p assword
>>>
>>> The idea is they can define their own height and width and it plugs in
>>> as an iframe.
>>>
>>> That takes the username and password and throws it over web services to
>>> get back the data from which we can create the map.
>>>
>>> My question (and it might be the wrong question) is how can I not give
>>> away the password to all and sundry yet still provide a self-contained URL?
>> MD5() (or SHA()) hash the information and supply that along with the
>> settings. Then you know it was generated by your site. So you can do the
>> following:
>>
>> >>
>> $height = 300;
>> $width = 250;
>> $username = 'username';
>> $key = md5( "SECRET_SALT-$heigh-$width-$username" );
>>
>> $url =
>> "http://www.mydomain.com?h=$height&w=$width&username=$userna me&key=$key";
>>
>> ?>
>>
>> Then when you get this URL via the iframe, you re-compute the expected
>> key and then compare it against the given key. Since only you know the
>> SECRET_SALT value then nobody should be able to forge the key.
>>
>> Cheers,
>> Rob.
>> --
>> http://www.interjinn.com
>> Application and Templating Framework for PHP
>>
>
>
> What about requiring them to sign in the first time to use your service,
> and then give them a unique id which i tied to their details. You could
> then get them to pass across this id in the url. You could link their
> account maybe to some sorts of limits with regards to what they can
> access maybe?

Presumably they ARE logged in when you create this URL for them...
otherwise someone else could generate it :)

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: How to secure this

--=-lPnPgQsqmPGXBUlUv2sD
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Fri, 2010-02-12 at 18:25 -0500, Ryan Sun wrote:

> authenticate by remote domain name or remote ip
>
> $_SERVER['HTTP_REFERER']
>
> then your clients will not have to put their username/password in clear text
> http://www.mydomain.com?h=300&w=250
> and you will just check if you have their domain on your list
>
> I'm not sure if there is better one but
> " 'HTTP_REFERER'
> The address of the page (if any) which referred the user agent to
> the current page. This is set by the user agent. Not all user agents
> will set this, and some provide the ability to modify HTTP_REFERER as
> a feature. In short, it cannot really be trusted. "
>
>
> On Fri, Feb 12, 2010 at 4:26 PM, Robert Cummings wrote:
> > Ashley Sheridan wrote:
> >>
> >> On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:
> >>
> >>> John Allsopp wrote:
> >>>>
> >>>> Hi everyone
> >>>>
> >>>> There may be blinding bits of total ignorance in this so don't ignore
> >>>> the obvious.
> >>>>
> >>>> This is a security question, but a sentence of background: I'm writing
> >>>> software for a mapping/location website and I want to be able to provide
> >>>> something others can plug into their website that would display their map.
> >>>>
> >>>> So I'm providing a URL like
> >>>> http://www.mydomain.com?h=300&w=250&username=name&password=p assword
> >>>>
> >>>> The idea is they can define their own height and width and it plugs in
> >>>> as an iframe.
> >>>>
> >>>> That takes the username and password and throws it over web services to
> >>>> get back the data from which we can create the map.
> >>>>
> >>>> My question (and it might be the wrong question) is how can I not give
> >>>> away the password to all and sundry yet still provide a self-contained URL?
> >>>
> >>> MD5() (or SHA()) hash the information and supply that along with the
> >>> settings. Then you know it was generated by your site. So you can do the
> >>> following:
> >>>
> >>> > >>>
> >>> $height = 300;
> >>> $width = 250;
> >>> $username = 'username';
> >>> $key = md5( "SECRET_SALT-$heigh-$width-$username" );
> >>>
> >>> $url =
> >>> "http://www.mydomain.com?h=$height&w=$width&username=$userna me&key=$key";
> >>>
> >>> ?>
> >>>
> >>> Then when you get this URL via the iframe, you re-compute the expected
> >>> key and then compare it against the given key. Since only you know the
> >>> SECRET_SALT value then nobody should be able to forge the key.
> >>>
> >>> Cheers,
> >>> Rob.
> >>> --
> >>> http://www.interjinn.com
> >>> Application and Templating Framework for PHP
> >>>
> >>
> >>
> >> What about requiring them to sign in the first time to use your service,
> >> and then give them a unique id which i tied to their details. You could
> >> then get them to pass across this id in the url. You could link their
> >> account maybe to some sorts of limits with regards to what they can
> >> access maybe?
> >
> > Presumably they ARE logged in when you create this URL for them... otherwise
> > someone else could generate it :)
> >
> > Cheers,
> > Rob.
> > --
> > http://www.interjinn.com
> > Application and Templating Framework for PHP
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>


I think Google does both the referrer check coupled with an id passed in
the URL. At least, this is what it did the last time I embedded one of
their maps.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-lPnPgQsqmPGXBUlUv2sD--

Re: How to secure this

authenticate by remote domain name or remote ip

$_SERVER['HTTP_REFERER']

then your clients will not have to put their username/password in clear text
http://www.mydomain.com?h=300&w=250
and you will just check if you have their domain on your list

I'm not sure if there is better one but
" 'HTTP_REFERER'
The address of the page (if any) which referred the user agent to
the current page. This is set by the user agent. Not all user agents
will set this, and some provide the ability to modify HTTP_REFERER as
a feature. In short, it cannot really be trusted. "


On Fri, Feb 12, 2010 at 4:26 PM, Robert Cummings wrote:
> Ashley Sheridan wrote:
>>
>> On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:
>>
>>> John Allsopp wrote:
>>>>
>>>> Hi everyone
>>>>
>>>> There may be blinding bits of total ignorance in this so don't ignore
>>>> the obvious.
>>>>
>>>> This is a security question, but a sentence of background: I'm writing
>>>> software for a mapping/location website and I want to be able to provide
>>>> something others can plug into their website that would display their map.
>>>>
>>>> So I'm providing a URL like
>>>> http://www.mydomain.com?h=300&w=250&username=name&password=p assword
>>>>
>>>> The idea is they can define their own height and width and it plugs in
>>>> as an iframe.
>>>>
>>>> That takes the username and password and throws it over web services to
>>>> get back the data from which we can create the map.
>>>>
>>>> My question (and it might be the wrong question) is how can I not give
>>>> away the password to all and sundry yet still provide a self-contained URL?
>>>
>>> MD5() (or SHA()) hash the information and supply that along with the
>>> settings. Then you know it was generated by your site. So you can do the
>>> following:
>>>
>>> >>>
>>> $height = 300;
>>> $width = 250;
>>> $username = 'username';
>>> $key = md5( "SECRET_SALT-$heigh-$width-$username" );
>>>
>>> $url =
>>> "http://www.mydomain.com?h=$height&w=$width&username=$userna me&key=$key";
>>>
>>> ?>
>>>
>>> Then when you get this URL via the iframe, you re-compute the expected
>>> key and then compare it against the given key. Since only you know the
>>> SECRET_SALT value then nobody should be able to forge the key.
>>>
>>> Cheers,
>>> Rob.
>>> --
>>> http://www.interjinn.com
>>> Application and Templating Framework for PHP
>>>
>>
>>
>> What about requiring them to sign in the first time to use your service,
>> and then give them a unique id which i tied to their details. You could
>> then get them to pass across this id in the url. You could link their
>> account maybe to some sorts of limits with regards to what they can
>> access maybe?
>
> Presumably they ARE logged in when you create this URL for them... otherwise
> someone else could generate it :)
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: How to secure this

--0050450159f4d392f0047f6fb195
Content-Type: text/plain; charset=ISO-8859-1

In that case, referer is for authentication, and id is for authorization, I
think

On Fri, Feb 12, 2010 at 6:23 PM, Ashley Sheridan
wrote:

> On Fri, 2010-02-12 at 18:25 -0500, Ryan Sun wrote:
>
> authenticate by remote domain name or remote ip
>
> $_SERVER['HTTP_REFERER']
>
> then your clients will not have to put their username/password in clear texthttp://www.mydomain.com?h=300&w=250
> and you will just check if you have their domain on your list
>
> I'm not sure if there is better one but
> " 'HTTP_REFERER'
> The address of the page (if any) which referred the user agent to
> the current page. This is set by the user agent. Not all user agents
> will set this, and some provide the ability to modify HTTP_REFERER as
> a feature. In short, it cannot really be trusted. "
>
>
> On Fri, Feb 12, 2010 at 4:26 PM, Robert Cummings wrote:
> > Ashley Sheridan wrote:
> >>
> >> On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:
> >>
> >>> John Allsopp wrote:
> >>>>
> >>>> Hi everyone
> >>>>
> >>>> There may be blinding bits of total ignorance in this so don't ignore
> >>>> the obvious.
> >>>>
> >>>> This is a security question, but a sentence of background: I'm writing
> >>>> software for a mapping/location website and I want to be able to provide
> >>>> something others can plug into their website that would display their map.
> >>>>
> >>>> So I'm providing a URL like
> >>>> http://www.mydomain.com?h=300&w=250&username=name&password=p assword
> >>>>
> >>>> The idea is they can define their own height and width and it plugs in
> >>>> as an iframe.
> >>>>
> >>>> That takes the username and password and throws it over web services to
> >>>> get back the data from which we can create the map.
> >>>>
> >>>> My question (and it might be the wrong question) is how can I not give
> >>>> away the password to all and sundry yet still provide a self-contained URL?
> >>>
> >>> MD5() (or SHA()) hash the information and supply that along with the
> >>> settings. Then you know it was generated by your site. So you can do the
> >>> following:
> >>>
> >>> > >>>
> >>> $height = 300;
> >>> $width = 250;
> >>> $username = 'username';
> >>> $key = md5( "SECRET_SALT-$heigh-$width-$username" );
> >>>
> >>> $url =
> >>> "http://www.mydomain.com?h=$height&w=$width&username=$userna me&key=$key";
> >>>
> >>> ?>
> >>>
> >>> Then when you get this URL via the iframe, you re-compute the expected
> >>> key and then compare it against the given key. Since only you know the
> >>> SECRET_SALT value then nobody should be able to forge the key.
> >>>
> >>> Cheers,
> >>> Rob.
> >>> --
> >>> http://www.interjinn.com
> >>> Application and Templating Framework for PHP
> >>>
> >>
> >>
> >> What about requiring them to sign in the first time to use your service,
> >> and then give them a unique id which i tied to their details. You could
> >> then get them to pass across this id in the url. You could link their
> >> account maybe to some sorts of limits with regards to what they can
> >> access maybe?
> >
> > Presumably they ARE logged in when you create this URL for them... otherwise
> > someone else could generate it :)
> >
> > Cheers,
> > Rob.
> > --
> > http://www.interjinn.com
> > Application and Templating Framework for PHP
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> I think Google does both the referrer check coupled with an id passed in
> the URL. At least, this is what it did the last time I embedded one of their
> maps.
>
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>

--0050450159f4d392f0047f6fb195--

Re: How to secure this

--0016e68ee2d95c8a44047f705377
Content-Type: text/plain; charset=UTF-8

On Sat, Feb 13, 2010 at 7:33 AM, Ryan Sun wrote:

> In that case, referer is for authentication, and id is for authorization, I
> think
>
> On Fri, Feb 12, 2010 at 6:23 PM, Ashley Sheridan
> wrote:
>
> > On Fri, 2010-02-12 at 18:25 -0500, Ryan Sun wrote:
> >
> > authenticate by remote domain name or remote ip
> >
> > $_SERVER['HTTP_REFERER']
> >
> > then your clients will not have to put their username/password in clear
> texthttp://www.mydomain.com?h=300&w=250
> > and you will just check if you have their domain on your list
> >
> > I'm not sure if there is better one but
> > " 'HTTP_REFERER'
> > The address of the page (if any) which referred the user agent to
> > the current page. This is set by the user agent. Not all user agents
> > will set this, and some provide the ability to modify HTTP_REFERER as
> > a feature. In short, it cannot really be trusted. "
> >
> >
> > On Fri, Feb 12, 2010 at 4:26 PM, Robert Cummings
> wrote:
> > > Ashley Sheridan wrote:
> > >>
> > >> On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:
> > >>
> > >>> John Allsopp wrote:
> > >>>>
> > >>>> Hi everyone
> > >>>>
> > >>>> There may be blinding bits of total ignorance in this so don't
> ignore
> > >>>> the obvious.
> > >>>>
> > >>>> This is a security question, but a sentence of background: I'm
> writing
> > >>>> software for a mapping/location website and I want to be able to
> provide
> > >>>> something others can plug into their website that would display
> their map.
> > >>>>
> > >>>> So I'm providing a URL like
> > >>>> http://www.mydomain.com?h=300&w=250&username=name&password=p assword
> > >>>>
> > >>>> The idea is they can define their own height and width and it plugs
> in
> > >>>> as an iframe.
> > >>>>
> > >>>> That takes the username and password and throws it over web services
> to
> > >>>> get back the data from which we can create the map.
> > >>>>
> > >>>> My question (and it might be the wrong question) is how can I not
> give
> > >>>> away the password to all and sundry yet still provide a
> self-contained URL?
>


How about RESTful like checking ?
It is much like what Rob said already.
but join all params by order and md5 it altogether


Regards,
Eric,


> > >>>
> > >>> MD5() (or SHA()) hash the information and supply that along with the
> > >>> settings. Then you know it was generated by your site. So you can do
> the
> > >>> following:
> > >>>
> > >>> > > >>>
> > >>> $height = 300;
> > >>> $width = 250;
> > >>> $username = 'username';
> > >>> $key = md5( "SECRET_SALT-$heigh-$width-$username" );
> > >>>
> > >>> $url =
> > >>> "
> http://www.mydomain.com?h=$height&w=$width&username=$usernam e&key=$key";
> > >>>
> > >>> ?>
> > >>>
> > >>> Then when you get this URL via the iframe, you re-compute the
> expected
> > >>> key and then compare it against the given key. Since only you know
> the
> > >>> SECRET_SALT value then nobody should be able to forge the key.
> > >>>
> > >>> Cheers,
> > >>> Rob.
> > >>> --
> > >>> http://www.interjinn.com
> > >>> Application and Templating Framework for PHP
> > >>>
> > >>
> > >>
> > >> What about requiring them to sign in the first time to use your
> service,
> > >> and then give them a unique id which i tied to their details. You
> could
> > >> then get them to pass across this id in the url. You could link their
> > >> account maybe to some sorts of limits with regards to what they can
> > >> access maybe?
> > >
> > > Presumably they ARE logged in when you create this URL for them...
> otherwise
> > > someone else could generate it :)
> > >
> > > Cheers,
> > > Rob.
> > > --
> > > http://www.interjinn.com
> > > Application and Templating Framework for PHP
> > >
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
> >
> >
> > I think Google does both the referrer check coupled with an id passed in
> > the URL. At least, this is what it did the last time I embedded one of
> their
> > maps.
> >
> >
> > Thanks,
> > Ash
> > http://www.ashleysheridan.co.uk
> >
> >
> >
>

--0016e68ee2d95c8a44047f705377--

Re: How to secure this

Robert Cummings wrote:
> Ashley Sheridan wrote:
>> On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:
>>
>>> John Allsopp wrote:
>>>> Hi everyone
>>>>
>>>> There may be blinding bits of total ignorance in this so don't
>>>> ignore the obvious.
>>>>
>>>> This is a security question, but a sentence of background: I'm
>>>> writing software for a mapping/location website and I want to be
>>>> able to provide something others can plug into their website that
>>>> would display their map.
>>>>
>>>> So I'm providing a URL like
>>>> http://www.mydomain.com?h=300&w=250&username=name&password=p assword
>>>>
>>>> The idea is they can define their own height and width and it plugs
>>>> in as an iframe.
>>>>
>>>> That takes the username and password and throws it over web
>>>> services to get back the data from which we can create the map.
>>>>
>>>> My question (and it might be the wrong question) is how can I not
>>>> give away the password to all and sundry yet still provide a
>>>> self-contained URL?
>>> MD5() (or SHA()) hash the information and supply that along with the
>>> settings. Then you know it was generated by your site. So you can do
>>> the following:
>>>
>>> >>>
>>> $height = 300;
>>> $width = 250;
>>> $username = 'username';
>>> $key = md5( "SECRET_SALT-$heigh-$width-$username" );
>>>
>>> $url =
>>> "http://www.mydomain.com?h=$height&w=$width&username=$userna me&key=$key";
>>>
>>>
>>> ?>
>>>
>>> Then when you get this URL via the iframe, you re-compute the
>>> expected key and then compare it against the given key. Since only
>>> you know the SECRET_SALT value then nobody should be able to forge
>>> the key.
>>>
>>> Cheers,
>>> Rob.
>>> --
>>> http://www.interjinn.com
>>> Application and Templating Framework for PHP
>>>
>>
>>
>> What about requiring them to sign in the first time to use your service,
>> and then give them a unique id which i tied to their details. You could
>> then get them to pass across this id in the url. You could link their
>> account maybe to some sorts of limits with regards to what they can
>> access maybe?
>
> Presumably they ARE logged in when you create this URL for them...
> otherwise someone else could generate it :)
>
> Cheers,
> Rob.
Well no they are not logged in, it's just an embedded iframe so that's
my main issue with my method, anyone could look at the web page source,
pinch the URL of the iframe and they'd have the username and password.

I'd got as far as MD5, but not the Secret Salt bit.

The thing that warped my head was .. if the URL then becomes
http://www.mydomain.com?h=$height&w=$width&username=$usernam e&key=$key
that's the same thing isn't it .. a URL anyone could use anywhere? In a
sense, we would have simply created another password, the MD5 key, which
was a valid way to get into the system.

So then validating the domain from a list stops anyone using it anywhere
and means we can switch it off by domain if we need to.

And .. we're not passing the password, right? We're not mixing that into
the MD5? We are just saying, if you have the right username, if we know
you've come via our code (secret salt), and you're from an approved
domain, we'll let you in.

Sorted, I think .. unless you spot any faulty reasoning in the above.
Thanks very much guys :-)

J







--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: How to secure this

At 12:36 PM +0000 2/13/10, John Allsopp wrote:
>
>Sorted, I think .. unless you spot any faulty reasoning in the
>above. Thanks very much guys :-)

The faulty reasoning is that you want to provide something to a
select group of people but are exposing it to the world. That's not
going to work.

You must devise a way to identify your group of people before you
provide something to them -- else, what you provide is going to be
public.

Cheers,

tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: How to secure this

John Allsopp wrote:
> Robert Cummings wrote:
>> Ashley Sheridan wrote:
>>> On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:
>>>
>>>> John Allsopp wrote:
>>>>> Hi everyone
>>>>>
>>>>> There may be blinding bits of total ignorance in this so don't
>>>>> ignore the obvious.
>>>>>
>>>>> This is a security question, but a sentence of background: I'm
>>>>> writing software for a mapping/location website and I want to be
>>>>> able to provide something others can plug into their website that
>>>>> would display their map.
>>>>>
>>>>> So I'm providing a URL like
>>>>> http://www.mydomain.com?h=300&w=250&username=name&password=p assword
>>>>>
>>>>> The idea is they can define their own height and width and it plugs
>>>>> in as an iframe.
>>>>>
>>>>> That takes the username and password and throws it over web
>>>>> services to get back the data from which we can create the map.
>>>>>
>>>>> My question (and it might be the wrong question) is how can I not
>>>>> give away the password to all and sundry yet still provide a
>>>>> self-contained URL?
>>>> MD5() (or SHA()) hash the information and supply that along with the
>>>> settings. Then you know it was generated by your site. So you can do
>>>> the following:
>>>>
>>>> >>>>
>>>> $height = 300;
>>>> $width = 250;
>>>> $username = 'username';
>>>> $key = md5( "SECRET_SALT-$heigh-$width-$username" );
>>>>
>>>> $url =
>>>> "http://www.mydomain.com?h=$height&w=$width&username=$userna me&key=$key";
>>>>
>>>>
>>>> ?>
>>>>
>>>> Then when you get this URL via the iframe, you re-compute the
>>>> expected key and then compare it against the given key. Since only
>>>> you know the SECRET_SALT value then nobody should be able to forge
>>>> the key.
>>>>
>>>> Cheers,
>>>> Rob.
>>>> --
>>>> http://www.interjinn.com
>>>> Application and Templating Framework for PHP
>>>>
>>>
>>> What about requiring them to sign in the first time to use your service,
>>> and then give them a unique id which i tied to their details. You could
>>> then get them to pass across this id in the url. You could link their
>>> account maybe to some sorts of limits with regards to what they can
>>> access maybe?
>> Presumably they ARE logged in when you create this URL for them...
>> otherwise someone else could generate it :)
>>
>> Cheers,
>> Rob.
> Well no they are not logged in, it's just an embedded iframe so that's
> my main issue with my method, anyone could look at the web page source,
> pinch the URL of the iframe and they'd have the username and password.
>
> I'd got as far as MD5, but not the Secret Salt bit.
>
> The thing that warped my head was .. if the URL then becomes
> http://www.mydomain.com?h=$height&w=$width&username=$usernam e&key=$key
> that's the same thing isn't it .. a URL anyone could use anywhere? In a
> sense, we would have simply created another password, the MD5 key, which
> was a valid way to get into the system.
>
> So then validating the domain from a list stops anyone using it anywhere
> and means we can switch it off by domain if we need to.
>
> And .. we're not passing the password, right? We're not mixing that into
> the MD5? We are just saying, if you have the right username, if we know
> you've come via our code (secret salt), and you're from an approved
> domain, we'll let you in.
>
> Sorted, I think .. unless you spot any faulty reasoning in the above.
> Thanks very much guys :-)

I should have been clearer... the $key part means they don't need to be
logged in, only that the URL was generated from a trusted location.
Presumably that location gained the trust of the person requesting the
URL in some manner... whether it be that they logged in, or that it
automatically generated the URL for them based on some other criteria.
The $key just embodies that relationship. The salt is necessary so that
not just anyone can generate the key since then anyone can generate the
URL and thus anyone can set the parameters as they please. This may not
be important in your case, but you seemed to think it was important
enough to originally consider their password :) This technique is also
good for displaying images on your site that you don't want other sites
linking to. You would hash in a timestamp and then if the requested time
exceeds the timestamp and duration you can serve up a "Sorry that image
is only available at www.my-awesome-site.com".

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: How to secure this

John Allsopp wrote:

> Well no they are not logged in, it's just an embedded iframe so that's
> my main issue with my method, anyone could look at the web page source,
> pinch the URL of the iframe and they'd have the username and password.

I think the only way to do it is to make a key per referring url and use
the key as a get variable.

Either the referring url matches the key or it doesn't.

That should work with an object/iframe embedding of a resource, browsers
by default send the referrer header.

A user may turn that off in a browser, but if a user turns that off, the
user is denied the resource because they changed a default setting. Kind
of like how I don't get some resources when I turn JavaScript off.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: How to secure this

Michael A. Peters wrote:
> John Allsopp wrote:
>
>> Well no they are not logged in, it's just an embedded iframe so that's
>> my main issue with my method, anyone could look at the web page
>> source, pinch the URL of the iframe and they'd have the username and
>> password.
>
> I think the only way to do it is to make a key per referring url and use
> the key as a get variable.
>
> Either the referring url matches the key or it doesn't.
>
> That should work with an object/iframe embedding of a resource, browsers
> by default send the referrer header.

Except when the object is handled by a plugin, they are notorious for
not sending that header (and thus IMHO are broken). But it sounds like
the resource you are providing is not requested by a plugin.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php