Jon Swinth wrote: >Thanks Brian and Marc for the responses. > >The credit card database is used for audit and for capture. When an order is placed, >the user must enter their credit card info and the system authorizes the charge right >then >while it still has the unencrypted cc number. The system then uses the public key to >encrypt the cc number and write the results to the audit trail. The user must put >their >credit card information in every time, so the front end site is not impacted if the >private key >is not available. > >The private key is used in the backend portion of the site. It is needed when the >orders >have shipped and now the charges need to be captured (batch). Unfortunately, the >credit >card processor being used requires the cc number again even though we already have a >transaction number and authorization code. Beyond capture, there is a couple of other >times that customer service needs to do something that would result in a new charge >on an existing credit card. If the key were to be unavailable then the function >requiring >the key would error and the customer service person would just notify the manager. > >Putting the key in a different DB is no more secure. If JBoss can get to it then a >hacker >can given enough time. I wont be able to prevent a hacker from sniffing what is on >the >machine, including the cc numbers that are comming in at that moment. I just don't >want >someone to be able to get at the whole database. This way, if the machines were ever >compromised then the most a hacker would have access to is the cc numbers that went by >while he was on the box. Hopefully, he would spend a lot of time looking for the >private >key and we would have time to detect him before he got much. This is all theory. > >I would actually not like the key to be on the box at all, not even in memory. This >would >make some functions difficult to code as they would need to wait for some outside >process >to come along and decrypt the needed cc number. Your idea of a separate JBoss behind >another firewall has merit. It would be rather complex since I wouldn't want to have >a function >exposed anywhere that would simply decode the cc number. I would have to bundle the >call to the cc processor in the separate JBoss so that it could only be used to >generate charges >and not to get at the cc number itself. This involves extra hardware and testing. >If I can >solve the issue of pegging the key in memory, I would explore the separate JBoss on >the >next version. > >Jon > > > >>From: Marc Zampetti <[EMAIL PROTECTED]> >>To: [EMAIL PROTECTED] >>Subject: Re: [JBoss-user] Design Question >>Reply-To: [EMAIL PROTECTED] >> >>I'm not sure I understand the desire to not have the key in a >>persistence store. This would mean that if your systems (or jBoss) >>crashes, your site is unusable until a human being inputs a new key. If >>you are worried about putting the stuff on a Internet-accessible >>machine, put another copy of jBoss inside your firewall and call out to >>a statefull session bean to get the key if you need it. Or another db >>would also work. In fact, I would put it in the database, locked down >>under another user id. The DB shouldn't be outside the firewall either, >>so hacking really should not be a problem. >> >>I see several issues with using the user's password. Most systems use a >>one-way encoding algorythm to store the password, so you can't recover >>the cleartext of the password that the user entered. Thus, you could >>never decrypt the cc info, since you can't get the cleartext password >>back. If you use a two-way encryption algorithm to encrypt the password, >>then you are back to your original problem, where do you store the >>key.Also, I'm assuming you are encrypting the cc number itself, so the >>idea of having an audit trail of the cc numbers defeats the whole >>purpose to begin with. >> >>Marc >> >>Brian Topping wrote: >> >> >>>How about using an entity bean against a separate data source pointing at >>>a memory DB such as hypersonic? You could configure it not to cache, >>>then when the process died, your single data entry would go with it. To >>>prime the db, the operator would hit an operator page that also had >>>access to that data source. >>> >>>But it seems like you could avoid this problem altogether by crypting each >>>user's wallet with the password that they selected in their account setup. >>>In this manner, each account would have a different key against the >>>respective wallets, eliminating the ability for a cracker to get all the >>>credit card numbers if the master password was cracked. Then you don't >>>have to have so much concern about a persistent password, they are always >>>based on the session. Lost passwords would be managed by assigning a new >>>password, not sending it back to them via email or whatnot. And if they >>>change their password, they lose their wallet, which is smart business >>>anyway. You'll need to keep audit trails of the credit card used with >>>each transaction, but that can be run off to a separate database. >>> >>>If you had a business reason to persist the encrypted cache (wallet), you >>>could keep a lookaside password cache that works in the way you are >>>already working with. The wallets would each still have a different key, >>>but there is a "key escrow" that is managed more securely... since the >>>private key isn't needed for operation within the business objects. >>> >>>-b >>> >>> >>> >>> Look into using JMS and message-driven beans. You could bundle up your requests that require the cc number and send it via JMS (using a SSL connection maybe), and let the back-end jBoss handle the rest, sending some sort of confirmation message.
Marc ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
