tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikola Milutinovic" <Nikola.Milutino...@ev.co.yu>
Subject Re: Security problem?
Date Fri, 07 Jun 2002 09:14:23 GMT
> On 6/7/02 1:54 AM, "Barney Hamish" <Hamish.Barney@ect-telecoms.de> wrote:
> 
> > - the amount of money the user is to pay encrypted with the private key of
> > site X as a digest.
> > 
> > On site Y you recieve both. You decrypt the encrypted amount with site X's
> > public key. If the clear text amount matches the encrypted amount then you
> > know the request originates from X and that the user hasn't tampered with
> > the request. If the amounts differ then you know the user has tampered with
> > the request and it should be rejected.
> 
> Is this backwards?
> 
> I thought public keys encrypt and private keys decrypt..
> 
> so site X would need to use site Y's public key to encrypt the amount, and
> site Y would then decrypt it with its private key.  Am I wrong?

I don't know if I have to say this, but... I believe that with X.509 certificates there are
two courses of action:

encrypt
--------
A public entity uses the certificate (which is publicly available) to encrypt an object to
the owner of the certificate. Only the owner has the private part of the certificate with
the private key, which can decrypt the object.

sign
----
The owner of the certificate ca use the private part of certificate/key to digitally sign
the object. All public entities, who have that certificate, can verify the integrity and authenticity
of the object.

So, what is suggested is that the "shopping cart" server creates the final payment report
and signs it with it's private key/certificate. The "financial transaction" server would verify
that *that* is an authentic request from the "shopping cart" server.

I must say that this is a bit ellaborate. I think that Java Servlet/JSP should serve as a
"Web portal" towards the Enterprize application. This would be a typical case where the application
design would benefit from a real JEE environment. IOW, there would be no redirection, the
"shopping cart" servlet would fire up an Enterprize Java Bean component on the "financial
transaction" server and that EJB would do the work, return the result to the servlet. There
is no "browser leaving the server", one point of entry.

> Also, why even send the cleartext version?

Why not use HTTPS? It is a must in payment web applications.

Nix.
Mime
View raw message