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
