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 > > > >>-----Original Message----- >>From: Jon Swinth [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, July 09, 2002 8:41 PM >>To: [EMAIL PROTECTED] >>Subject: [JBoss-user] Design Question >> >> >>What is the best way to keep a object bound in memory for >>stateless session bean use? >> >>Specifically, I have a java.security.Key that I need to make >>available to very specific stateless session bean. >>Since the key is the private RSA key for the credit card >>database, I do not want to put it in the DB >>or on the file system. I do not want it available should the >>server be compromised. I realize that >>having it in memory is still somewhat accessable for a hacked >>system, but it is the only thing I have come >>up with to make the key available to the bean and still make >>it difficult for a hacker. >> >>The original thought is to put the key into a private static >>variable within the bean so that all copies of the >>bean in the JVM would have access to the same key. The >>question is, wouldn't there come a time when all copies >>of the bean are removed for lack of access and the key would >>be lost? This is not a huge problem since the first >>user to receive an error would simply request that the >>manager upload the key again. That is unless it happens >>frequently throughout the day. The idea is that the manager >>would also specify a timeout when uploading the key >>so that it would drop from memory after a certain amount of time. >> >>I am open to any suggestions. >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Stuff, things, and much much more. >>http://thinkgeek.com/sf >>_______________________________________________ >>JBoss-user mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-user >> >> >> > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Stuff, things, and much much more. >http://thinkgeek.com/sf >_______________________________________________ >JBoss-user mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-user > > ------------------------------------------------------- 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
