[Just got Jon's email as I typed this, so I guess it's academic, but still interesting...]
> -----Original Message----- > From: Marc Zampetti [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 10, 2002 10:15 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Design Question > > > 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. Not if the wallets are separately encrypted with the end-user password. > 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. This really isn't sufficient for reasonable security. When I go home at night, I want to know that even if a hacker gets through one layer of my firewall that there isn't anything he is going to be able to do except start hacking another firewall. My pager might go off while i'm not at the office (then, it might not, if they are good), and if I feel like dealing with it, I'll log in and see what's up and whether I can get them out. You can bet I don't want to deal with it if I am in meat space and having a good time. Hackers *will* get in, and when they do, they don't just disappear. They create backdoors that take a while to get rid of, as in, plan a couple of long days. Unless you have packet sniffing trace units monitoring the wire, there is *no* way to be absolutely sure which machines have been compromised and which ones haven't, so you have to assume they are all bad. (This is where you wish your cluster was diskless boot with hardware-locked BIOS, so you could just restart the machines one by one.) But regardless, this all takes time, and unless you are prepared, the offense has the upper hand. I've been hacked a couple of times (once seriously) and it's scary. It's hard enough to figure out how they got in to start with much less fix the source problem *and* get them out before they actually do something really bad (steal/destroy data that will kill business) If your DB unencrypted and not behind a second firewall, you might as well have just handed over the list of customer credit cards to them. Hopefully it's clear that "should not be a problem" doesn't cut it when you are talking about customer credit cards, IMHO. > 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. For systems that do not make periodic purchases, this is not a bad thing. I don't want *anyone* to make a purchase unless it is made by the owner of the card. > 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. For systems that need periodic access to the card (monthly billing cycle, etc.), that's correct. In that case, I'd almost argue that it's not even worth bothering putting the CC behind an encryption function since anyone with access to the business object source is going to have ability to nab a credit card. So just put the DB and the business objects behind a second firewall and leave it at that. This is true up to the point that you are so big that you can afford a security officer to keep the keys, a release organization to make sure that the released code is what it says it's supposed to be, and developers that can only change the code through the release organization, which checks the changes. To start with though, the security officer can be the president and the release organization simply someone different than the programmers (i.e., a responsible manager) > 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. Well, I never test anything and my code sux, so I have to have an audit trail to give me a way of fixing my fukups... :) Seriously, no auditor except Anderson is going to let you by without an audit log. The question is how to manage the problem, it's not going to disappear because it's "hard". I know, small businesses don't need all this. Same businesses that will be small forever. Think small, stay small. I'm sure not going to be remembered on the same page as Egghead... peas, -b > > 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 > ------------------------------------------------------- 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
