Re: Secure data transfer between servers

From: C-Pro (c-pro-29a*removethis*@mail.ru)
Date: 03/07/02 

From: C-Pro <c-pro-29a*removethis*@mail.ru>
Date: Thu, 07 Mar 2002 23:29:55 +1000

Encoding all traffic is not nesesary. You can give a cookie, containing
a unique ID of the connection (for example hash of ip and user-agent),
encrypted with strong symmetric algorythm (AES, GHOST, may be even
good-old DES), to each user, entering your site. And suppliers site
needs to decrypt the cookie, check user's ip, user-agent and if the
cookie is expired.
P.S.:I have not ever implemented this, and it was the first thing to
came to my mind, so NO GUARANTIES :)

Michael wrote:
> Can anyone help me?
>
> I am looking to find a secure alternative to the HTTP_REFERRER field in the
> header.
>
> I have customers that login to my website, and then when they click on a
> link to a supplier(there are a number of supplier options), they are
> redirected to the supplier's website along with some information like
> customer IDs etc. The supplier then needs to authenticate the fact that the
> customer has come through my website?
>
> Using the HTTP referrer is not secure, as it can easily be spoofed,
> therefore I need an alternative.
>
> I have been told that the only way to guarantee the authenticity of the
> request at the supplier end is to use private/public key encryption? Before
> the data is sent from my site it is encrypted using it's private key, and
> the supplier decrypts it at the other end using the public key, therefore
> authenticating the fact it came throughout my site.
>
> Does anyone know how you would implement this, or are there any other
> alternatives?
>
> I am running IIS 4 on NT 4. And I have no control over what platform the
> suppliers are using?
>
> Please help me
>
>
> Michael
>
>
>
>
>

Relevant Pages

  • Re: Secure data transfer between servers
    ... You can give a cookie, ... a unique ID of the connection (for example hash of ip and user-agent), ... The supplier then needs to authenticate the fact ... > request at the supplier end is to use private/public key encryption? ...
    (comp.security.misc)
  • Re: Best authentication methods for CGI <- PERL -> DBI
    ... Right now one method which seems to be really unsecured, is to take them, check them against the PW/ID stored in the database and permit/deny against that. ... The client javascript code takes the password and MD5 sums it, and sends that as the password along with the cleartext username. ... One cookie is the record id of the user in the database, ... A solution to not use https would be public key encryption. ...
    (perl.dbi.users)
  • Re: Best authentication methods for CGI <- PERL -> DBI
    ... Right now one method which seems to be really unsecured, is to take them, check them against the PW/ID stored in the database and permit/deny against that. ... The client javascript code takes the password and MD5 sums it, and sends that as the password along with the cleartext username. ... One cookie is the record id of the user in the database, ... A solution to not use https would be public key encryption. ...
    (perl.dbi.users)
  • Re: [PHP] maintaining [user] state without a session ...
    ... considering that before the user is going to be provided access to sensitive data that you require a password confirmation. ... So what if a malicious user uses a cookie to pretend to be a real user IF before they can get access to sensitive data they have to enter a correct password? ... For some sites this would not be an issue but due to some of the ways we use the data in that cookie I decided the cost of encrypting it against the cost of validating it and the risks involved made encryption the better option. ... Because that negates the whole point of doing it which is to reduce database access to the minimum possible. ...
    (php.general)
  • Re: Slightly OT: encryption
    ... > I'm trying to setup a system of secure encryption for exchanges between ... > algorithm which works with javascript - do let me know. ... But where to store it? ... > If I put it in a secure cookie or a cookie with an obfusticated path it ...
    (comp.os.linux.security)