I'm posting this back to the list to keep the conversation there. I hope
you don't mind. My comments are at the bottom . . .
On 11/9/05 10:10 AM, Tony Di Croce wrote:
The reason I even wanted to do this had more to do with sharing some
data between two sites, and less with really maintaining a login.
It occured to me that I need not "share sessions" at all. Instead, all
of the data B needs could simply be encrypted by A and sent in a post field.
Now, this does bring up the problem that someone could sniff this
packet, capture this encrypted packet, and use it to authenticate
themselves on B. They never had to decrypt it, just capture from A, and
send to B at their leisure...
Let me give some background here on exactly what I'm doing, as it may
clear things up a bit.
B is a secure page, with a CC info form that when submitted will process
their card, charging the amount of money passed in the encrypted packet,
and if the charge succeeds, redirecting back to A. A would probably need
to send an order number to B, and B could pass that back to A upon
success or failure.
All of this is to get around the Apache limitation of allowing only one
virtual host to use SSL.
Anyhow, B could keep track of all of the order numbers it was sent by A,
and if it was re-sent a duplicate could simply deny the whole
transaction. Thus, if someone sniffed my encrypted "data burrito", and
attempted to re-use it to gain access to B, they would fail, since B
will only allow that burrito ONCE. Perhaps these order numbers could be
GUID's.
How does this sound?
I think someone else here could probably offer some better advice, but
here's what I would do.
I would definitely use SSL when dealing with CC data, but I don't think
there's an Apache limitation that restricts the use of SSL to one host.
There is a limitation that restricts the use of an SSL certificate to
one host, so, if you had two certificates, both hosts could use SSL
sockets, but I don't think that's what you need here. (You could still
use the same certificate across multiple hosts, but then the user is
going to be prompted in the browser whether or no to allow the
certificate to be used, and this is generally not a good idea.)
What you need to do is ensure that your FORM action on domain A (the
unsecured domain) is POSTing to https://domain-b.org. Note the usage of
HTTPS. This will ensure that the data is sent along the secure channel
and not in clear text. You don't need to perform any encryption, since
SSL takes care of that for you.
Then, B could simply redirect back to A after processing the order and
pass the order number through the query string (since it's probably not
very sensitive).
Does this answer your question?
And, yeah, denying used order numbers would be a good idea.
--
Ben Ramsey
http://benramsey.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
