hi john -
in the early days of eCom apps i participated in
desiging i was against storage of credit cards.
the reasoning being don't do it if it isn't necessary
and why open one's self upto potential liabilities.
well, for some transaction scenarios it is likely
necessary. i see most consumer oriented web transactions
as akin to traditional mail order catalog transactions
and i'd be willing to bet that every one of those
systems store credit card data.
as time rolled on, it turns out that a merchant
can potentially run the risk of not being able to
collect on a pre-authorized amount against a card
if the authorization time has expired (eg back order,
external billing systems troubles -- both of which
have happended and are real issus).
i came to the conclussion that we may have to store
the card info (eg number, expiration, bill to) for
at least some period of time ... till the merchant
has collected the last penny ... after which it may
be wise to purge the card data. as such, we chose to
store the card info internally for a period of time
in an encoded format (our own internal code per a
java security algorithms book).
around that same time i believe amazon.com started
advertising that it is actually more secure (and
easier for you to make repeat purchases) for them
to perminently store the card on their site (the
card data will be transmitted over the web one less
time, the data won't potentially be stored in a
kiosk browser cache, etc).
at this time and depending on the type of transactions
your system is doing, i believe following the amazon.com
model is good (it helps greatly if customers have faith
and trust in your brand).
hope this helps,
- jame
"Lame, John" wrote:
>
> >>We receive credit card information (and we are using SSL) and we would
> >>simply like to encrypt the data before we place it in the database and
> >>decrypt it after retrieving it.
>
> >Why do you need to decrypt the number?
> >You have the encrypted number in your database.
> >You receive a number that is not encrypted.
>
> The short answer is that management wants two-way encryption.
> I suppose a longer answer is that we probably need to decrypt
> the credit card number in order to bill our customers. (I say
> probably because I'm new to this project so I'm unfamiliar with
> most of what it does.).
>
> John.
>
> p.s. I'm making progress btw. http://www.cryptix.org seems to have
> a usefull library of tools for this sort of this thing. If I do come up
> with something short and sweet. I'll post.
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
