Click to See Complete Forum and Search --> : how do i securely handle credit card number from the client.


pramod
02-19-2001, 12:35 PM
we are developeing desktop application in vc++
the project is web based,so i have to handle credit card information
from the customer,i know that if we use https protocol, then security is
taken care, but i want to use java security on the server side,and
take verisign as the certifying authoruty(CA),since CA is only for the code
or documents which reside on the server side, how do i make use of CA if
it
comes to handling credit card information from the client?
any answers please?
thanks pramod

Michael Howard
02-19-2001, 03:52 PM
ssl doesn't buy you anything if i can attack your server's directly and read
the creditcard info from your database. this is what happened to cduniverse.com.
my book offers some guidelines for handling credit cards. the best way to
reduce the threat is not to handle them!!! :-)

http://marketplace.devx.com/product.asp?pf%5Fid=5654


"pramod" <ppkumar90@hotmail.com> wrote:
>
>we are developeing desktop application in vc++
>the project is web based,so i have to handle credit card information
>from the customer,i know that if we use https protocol, then security is
>taken care, but i want to use java security on the server side,and
>take verisign as the certifying authoruty(CA),since CA is only for the code
>or documents which reside on the server side, how do i make use of CA if
>it
>comes to handling credit card information from the client?
>any answers please?
>thanks pramod
>

Don Bevis
03-01-2001, 12:27 PM
And the best way to avoid someone hacking your website is... Not have a
website?

I happen to be wrestling with exactly the problem "pramod" expressed.
"Wrestling" in that I am trying to make some sense out of the CryptoAPI
calls.

My scheme will be to implement a public key on the webserver, and store ONLY
encrypted data (credit card # at least, maybe cardholder name, too). There
will be nothing on the server that decrypts the card data or persists the
unencrypted data.

A client piece holds the (encrypted) private key and is the only one able to
decrypt the data. All data goes over the wire via SSL, of course. The
client must enter a password to unlock the private key

It's just a matter of figuring out the right sequence of API calls and the
multitude of flags words and parameters that they require.


"Michael Howard" <mikehow@microsoft.com> wrote in message
news:3a91796c$1@news.devx.com...
>
> ssl doesn't buy you anything if i can attack your server's directly and
read
> the creditcard info from your database. this is what happened to
cduniverse.com.
> my book offers some guidelines for handling credit cards. the best way to
> reduce the threat is not to handle them!!! :-)
>
> http://marketplace.devx.com/product.asp?pf%5Fid=5654
>
>
> "pramod" <ppkumar90@hotmail.com> wrote:
> >
> >we are developeing desktop application in vc++
> >the project is web based,so i have to handle credit card information
> >from the customer,i know that if we use https protocol, then security is
> >taken care, but i want to use java security on the server side,and
> >take verisign as the certifying authoruty(CA),since CA is only for the
code
> >or documents which reside on the server side, how do i make use of CA if
> >it
> >comes to handling credit card information from the client?
> >any answers please?
> >thanks pramod
> >
>

Michael Howard
03-02-2001, 07:23 PM
hhmm - giving out public and private keys is easy, you can call xenroll.dll,
but how do people access the data in the browser? the technique you propose
is technically sound, but from my own experience you have to make it braindead
simple for users to grok... or they won't use it!


"Don Bevis" <dbweb1@premiersi.com> wrote:
>And the best way to avoid someone hacking your website is... Not have a
>website?
>
>I happen to be wrestling with exactly the problem "pramod" expressed.
>"Wrestling" in that I am trying to make some sense out of the CryptoAPI
>calls.
>
>My scheme will be to implement a public key on the webserver, and store
ONLY
>encrypted data (credit card # at least, maybe cardholder name, too). There
>will be nothing on the server that decrypts the card data or persists the
>unencrypted data.
>
>A client piece holds the (encrypted) private key and is the only one able
to
>decrypt the data. All data goes over the wire via SSL, of course. The
>client must enter a password to unlock the private key
>
>It's just a matter of figuring out the right sequence of API calls and the
>multitude of flags words and parameters that they require.
>
>
>"Michael Howard" <mikehow@microsoft.com> wrote in message
>news:3a91796c$1@news.devx.com...
>>
>> ssl doesn't buy you anything if i can attack your server's directly and
>read
>> the creditcard info from your database. this is what happened to
>cduniverse.com.
>> my book offers some guidelines for handling credit cards. the best way
to
>> reduce the threat is not to handle them!!! :-)
>>
>> http://marketplace.devx.com/product.asp?pf%5Fid=5654
>>
>>
>> "pramod" <ppkumar90@hotmail.com> wrote:
>> >
>> >we are developeing desktop application in vc++
>> >the project is web based,so i have to handle credit card information
>> >from the customer,i know that if we use https protocol, then security
is
>> >taken care, but i want to use java security on the server side,and
>> >take verisign as the certifying authoruty(CA),since CA is only for the
>code
>> >or documents which reside on the server side, how do i make use of CA
if
>> >it
>> >comes to handling credit card information from the client?
>> >any answers please?
>> >thanks pramod
>> >
>>
>
>