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 > > > > ------------------------------------------------------- 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
