Like I suggested above, not sure if you saw that email. I was thinking of adding such a filter API for the Resources utility. Sound good?
>> Most people like
>> encrypting SQL when stored procedures are not available.
I would change "most" to "a very select few" -- which makes it no less important to those few. But let's not exaggerate.
>> You'd be surprised how many companies do only stored procedures because that's considered "unhackable";
>> not only would you have to get into the web server, but through the internal firewall, and into the DB with a password
>> to read them.
Those companies are sadly at risk of depending upon security through obscurity.
>> With hibernate, the SQL is not generated until runtime, and so it cannot be looked at.
That's absolute BS. :-) Not only can it be seen easily with database profiling tools, it can be predicted, because Hibernate is based upon very specific algorithms for generating SQL based on various types of mappings. Given the mapping, you can predict the SQL without ever running it. And there is certainly no IP in the SQL that Hibernate generates.
Not only that, but Hibernate can also use plain SQL and/or HQL for queries, which would have the same problem (or worse) than what we're discussing here. String literals cannot be obfuscated without injecting a codec into the code which I'm not sure any obfuscators do -- even if they did, that would also be predictable.
>> But SQL is valuable stuff, it can be years worth of efforts. And some people like to take
>> some zealous steps to make sure it's safe..
That's goofy too. But at least you said "some" this time. ;-)
>> it's source code, not binary.
It's equivalent to a scripting language. It's compiled (and cached) at runtime. I hope such companies never use Perl, Python, Ruby, PHP, JSP, ASP or _javascript_. Actually, I hope they do, and I hope they encrypt it using some goofy encryption algorithm. And I hope someday someone hacks into their system by pretending to be a Network Admin asking their CIO for his password. That way I can read about it in WSJ and then eventually in a Dilbert comic. ;-)
Anyway...
I think we're in agreement. The need is there for something, even if it's a false sense of security for someone. Sometimes perception and feelings are valuable in business, especially for consultants.
Cheers,
Clinton
On 6/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
I believe iBATIS started out as an encryption program, and so I find it ironic I cannot hook in anywhere to do encryption :-) It would be nice if there was a callback so I could wrap one stream in another.
iBATIS should have not encryption, but hooks to do that -- or whatever (compression?) -- would be wonderful. Most people like encrypting SQL when stored procedures are not available. You'd be surprised how many companies do only stored procedures because that's considered "unhackable"; not only would you have to get into the web server, but through the internal firewall, and into the DB with a password to read them.
With hibernate, the SQL is not generated until runtime, and so it cannot be looked at. But SQL is valuable stuff, it can be years worth of efforts. And some people like to take some zealous steps to make sure it's safe.. it's source code, not binary.
Paul
Clinton Begin <[EMAIL PROTECTED] > wrote:
What are you protecting though?
-- The SQL? (why?)
-- The Passwords? (fair enough, but you don't have to put those in the XML file)
I've always said that encryption of iBATIS XML files should be outside of the scope of ibatis. That said, we haven't made it easy for you, as the obvious place to encrypt/decrypt the configuration files is in the Resources utility class -- which is not easily extended or replaced.
Perhaps we could offer a configurable a stream filter hook in the Resources class so you can use whatever means you feel comfortable with to encrypt and decrypt your configuration files with.
Thoughts?
Trivia: Who knows the history of the iBATIS name and how it relates to cryptography?
Cheers,
ClintonOn 6/21/06, Paul Benedict < [EMAIL PROTECTED]> wrote:Larry, why would it slow me down? :-) Configuration files are read once and thrown away. If it is slower to boot up, oh well, the 2 AM deployment team is going to have to stay up a few more minutes! hehe. But seriously, encrypting the file is only a pre-cautionary safe-guard; decrypting probably also requires a key to be stored somewhere so if that is also found on the file system, I am toast (point granted). But if someone managed to steal the jar only, they can't do a thing. -- Paul
Larry Meadors <[EMAIL PROTECTED]> wrote:You know, if someone has access to your filesystem, encrypting that
file is just going to slow you down, not them.
I would focus on securing the filesystem so that only the one user
that needs access to it has access to it, and letting it protect you.
Encrypting that file IMO is a total waste of time.
LarryOn 6/21/06, Paul Benedict wrote:
> Andre, the concern would be if you have to deploy your application to
> servers you do not own. Most companies own their servers, but sometimes
> small businesses use external providers. -- Paul
>
>> Andre Peterka wrote:
>
> I have thought about encrypting the sqlmaps also. But will it be worth all
> the hassle since every RDBMS will provide some kind of monitoring and all
> the sqls will be available anyway.
>
> Andre
>
> > -----Urspr�ngliche Nachricht-----
>
> > Von: Paul Benedict [mailto: [EMAIL PROTECTED]]
> > Gesendet: Mittwoch, 21. Juni 2006 14:52
> > An: [email protected]
> > Betreff: Re: Obsfucation in iBatis xml file
> >
> > I am looking for the same thing. I'd like to encrypt my
> > sqlmap files during my packaging phase. But how to decrypt
> > them? I can only imagine with a custom class loader, maybe AspectJ.
> >
> > Tom Henricksen wrote:
> >
> > We are working on looking into code obfuscation for
> > Java application. Is there some way to obfuscate the iBatis
> > xml file? My guess is probably not as this would be very difficult.
> > Thanks,
> > Tom
> >
> >
> >
> >
> >
> > ________________________________
> >
> > Do you Yahoo!?
> > Everyone is raving about the all-new Yahoo! Mail Beta.
> > > ahoo.com/handraisers>
> >
>
>
>
> ________________________________
> How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates.
>
>
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
Ring'em or ping'em. Make PC-to-phone calls as low as 1¢/min with Yahoo! Messenger with Voice.
