"Boget, Chris" wrote:
>
> One other thing that I forgot to include in my previous message as
> a concern of mine and it relates to the above. If we did it that way,
>
> someone who was listening to a port on the client's server, or who
> came by later to use the same machine the client was using previously
> to do this could get this somehow encrypted information and log in
> as the previous user since we wouldn't require authentication because
> said authentication would have already been done on the trusted
> website. So essentially a 3rd party could concievably obtain this
> information that was posted with the URL (which is why I didn't
> want to pass this information via GET) to access our site and wreak
> havoc. I definitely want to minimize this possibility.
True, this is a possibility.
Do a post, not a get. Might eliminate a small possibilty.
A lot of this coordination (or other gyrations you could come up with)
require some cooperation from this 'outside' server. How 'outside' is
it? If you need to change a key or algorithm, how much can they
accomodate? Rhetorical questions mostly - you'll have to take all this
into account.
Not sure I see the whole benefit of a scheme like this. I mean, I sort
of do, but it's a lot of hassle, and introduces extra security issues at
the expense of an extremely small amount of user inconvenience (which
they need to put up with at every other site on the web anyway - you're
not at a significant usability disadvantage).
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
