You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-cs@ibatis.apache.org by Pablo Lopez <pl...@tecisa74.com> on 2005/01/12 13:49:11 UTC
plaintext passwords and exposed sql in configuration files
Hi everybody,
I'm new in using iBatis and I've managed to make it up and running,
providing excellent features.
But there's one problem that I've come across: the username and password
used for the connection with the database are stored in plaintext,
either in the sqlmap.config or in the providers.config files, as also
all the SQL is in the datamaps.
So, even if my application is quite secure, if the username, password
and the SQL sentences in the datamaps are exposed, not only everyone can
connect to the database, but he also knows the methods we use to access
it, so my application security becomes useless.
Is there any known solution for that? Or doesn't iBatis cover that
problem and I must use the operating system features (for example file
read permissions) to overcome that problem?
People at my company are quite reluctant to use iBatis because of those
two problems (username, password and SQL exposed in files) but I really
want to give iBatis a try, so any kind of information in solving these
issues would help a lot.
I suppose I'm not the first one in having this issue, but I've searched
google, iBatis documentation, etc... and found nothing about it (and the
"archives" feature of this mailinglist
(http://nagoya.apache.org/eyebrowse/SummarizeList?listName=ibatis-user-cs@incubator.apache.org)
does not seem to work.
Thanks a lot,
Pablo.
Re: plaintext passwords and exposed sql in configuration files
Posted by Clinton Begin <cl...@gmail.com>.
Thanks for the clarification.
Now that we know what we're after, I wonder how hard it would be to
simply serialize the DOM of the XML structure. That would give you a
binary file. Then, with some simple obfuscation (ROT-13) on the text,
you'd have a fairly jumbled file that would have Doofy scratching his
head.
Now, we could use a keyed algorithm (AES), but then we're back to the
key chain. One approach I've used in the past was to force the
administrator to enter a password on startup. That way the key
doesn't have to be kept on the server at all.
None of this has to be done by iBATIS, it would be relatively simple
to create a stream filter for such binary/obfuscated/encrypted files.
Cheers,
Clinton
On Wed, 12 Jan 2005 16:36:37 +0100, Pablo Lopez <pl...@tecisa74.com> wrote:
> Hi,
>
> First of all, thanks Alexey and Clinton for your quick responses :)
>
> Clinton:
>
> Don't know why you've taken my question so seriously... I'm not talking
> about an NSA security product; I think I didn't even mention the word
> cryptography, and I've read -among quite a lot of other books- 'Secrets
> and Lies' from Bruce Schneier, so I'm quite aware of what security is
> and what can and cannot be achieved, especially in such a small
> application like the one we're planning to do, with no security experts
> at all among our staff.
>
> Maybe my words were not elegant or precise enough, and I'm sorry about
> that cause I agree with you in what you've said about security, so to
> make it really clear, the only thing I was just asking for was a little
> help in "hiding" the username and password from, yes, call him "special
> agent Doofy".
>
> This is what 95% of non-opensource applications do by embedding the
> connection string in the code and then just giving the binaries, being
> the program in charge of granting/denying access to the pieces accesing
> the database depending on who has logged on.
>
> Of course this is quite a stupid approach, but seems enough to keep
> "Doofy" out of connecting directly to the database and messing around,
> which is basically what we want to achieve.
>
> Maybe I have to investigate Alexey's solution a little further... I
> thought the connection string could only be stored in sqlmap.config or
> database.providers files -I'm a newbie to iBatis, remember that :)- but
> if there are other not so obvious ways (for example by using some method
> in the API that I don't know) I guess that would be enough.
>
> Thanks a lot again :)
>
> Pablo.
>
>
>
Re: plaintext passwords and exposed sql in configuration files
Posted by Pablo Lopez <pl...@tecisa74.com>.
Hi,
First of all, thanks Alexey and Clinton for your quick responses :)
Clinton:
Don't know why you've taken my question so seriously... I'm not talking
about an NSA security product; I think I didn't even mention the word
cryptography, and I've read -among quite a lot of other books- 'Secrets
and Lies' from Bruce Schneier, so I'm quite aware of what security is
and what can and cannot be achieved, especially in such a small
application like the one we're planning to do, with no security experts
at all among our staff.
Maybe my words were not elegant or precise enough, and I'm sorry about
that cause I agree with you in what you've said about security, so to
make it really clear, the only thing I was just asking for was a little
help in "hiding" the username and password from, yes, call him "special
agent Doofy".
This is what 95% of non-opensource applications do by embedding the
connection string in the code and then just giving the binaries, being
the program in charge of granting/denying access to the pieces accesing
the database depending on who has logged on.
Of course this is quite a stupid approach, but seems enough to keep
"Doofy" out of connecting directly to the database and messing around,
which is basically what we want to achieve.
Maybe I have to investigate Alexey's solution a little further... I
thought the connection string could only be stored in sqlmap.config or
database.providers files -I'm a newbie to iBatis, remember that :)- but
if there are other not so obvious ways (for example by using some method
in the API that I don't know) I guess that would be enough.
Thanks a lot again :)
Pablo.
Re: plaintext passwords and exposed sql in configuration files
Posted by Clinton Begin <cl...@gmail.com>.
This is funny, but in a very serious way.
Security is a very complex area of computer science. Simple
encryption of a file does not achieve security. Where do you plan to
store the key to decrypt the files? Given that you've already made
the assumption that your end users can gain access to the application
files and SQL Maps, how do you plan on protecting the rest of your
application files?
It sounds to me like your application security is already useless. If
your end users have access to the application files (exe, dll, config,
etc.) directly you've already lost the security game.
No amount of signing, encrypting with key chains or obfuscation will
help you. NOBODY has ever successfully achieved this. If you manage
to, call me, I'll invest in your company and we'll make CNN's Larry
King Live together.
Now, if you're simply looking to stop "Special Agent Doofy" from
casually browsing such information, then that is something we can help
you with. But please, don't call that security, or cryptography, or
even encryption. We can call it "discouragement".
Cheers,
Clinton
On Wed, 12 Jan 2005 13:49:11 +0100, Pablo Lopez <pl...@tecisa74.com> wrote:
> Hi everybody,
>
> I'm new in using iBatis and I've managed to make it up and running,
> providing excellent features.
>
> But there's one problem that I've come across: the username and password
> used for the connection with the database are stored in plaintext,
> either in the sqlmap.config or in the providers.config files, as also
> all the SQL is in the datamaps.
>
> So, even if my application is quite secure, if the username, password
> and the SQL sentences in the datamaps are exposed, not only everyone can
> connect to the database, but he also knows the methods we use to access
> it, so my application security becomes useless.
>
> Is there any known solution for that? Or doesn't iBatis cover that
> problem and I must use the operating system features (for example file
> read permissions) to overcome that problem?
>
> People at my company are quite reluctant to use iBatis because of those
> two problems (username, password and SQL exposed in files) but I really
> want to give iBatis a try, so any kind of information in solving these
> issues would help a lot.
>
> I suppose I'm not the first one in having this issue, but I've searched
> google, iBatis documentation, etc... and found nothing about it (and the
> "archives" feature of this mailinglist
> (http://nagoya.apache.org/eyebrowse/SummarizeList?listName=ibatis-user-cs@incubator.apache.org)
> does not seem to work.
>
> Thanks a lot,
>
> Pablo.
>
>
>
RE: Team iBATIS releases iBATIS.NET 1.*.458
Posted by Alexey Boroday <a....@procreditbank.com.ua>.
Hello.
Help me please. Where I can download sources? I couldn't find iBATIS at
http://svn.apache.org/ :(
Thank you.
> -----Original Message-----
> From: Gilles Bayon [mailto:gilles.bayon@laposte.net]
> Team iBATIS releases iBATIS.NET 1.*.458
> Build Date: 12-jan-2005
> Build Number: 458
___________________________________________________________________________
This communication is confidential and may be legally privileged.
If you believe you are not an intended recipient, please inform the sender,
delete the e-mail and do not copy, print or use it or disclose it to others.
You can inform the sender by replying to this e-mail or by telephone (+380 44 4906080).
Re: Team iBATIS releases iBATIS.NET 1.*.458
Posted by Gilles Bayon <gi...@laposte.net>.
+1 is for Ted message
----- Original Message -----
From: "roberto" <ro...@theaegis.org>
To: <ib...@incubator.apache.org>
Sent: Thursday, January 13, 2005 10:18 PM
Subject: RE: Team iBATIS releases iBATIS.NET 1.*.458
Pardon me since I'm slow by nature... ;-)
...but this is a +1 for what exactly? The .NET release or the Roadmap
update?
Roberto
RE: Team iBATIS releases iBATIS.NET 1.*.458
Posted by roberto <ro...@theaegis.org>.
Pardon me since I'm slow by nature... ;-)
...but this is a +1 for what exactly? The .NET release or the Roadmap
update?
Roberto
> -----Original Message-----
> From: Gilles Bayon [mailto:gilles.bayon@laposte.net]
> Sent: Thursday, January 13, 2005 1:09 PM
> To: ibatis-dev@incubator.apache.org
> Subject: Re: Team iBATIS releases iBATIS.NET 1.*.458
>
> +1
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: <ib...@incubator.apache.org>
> Sent: Thursday, January 13, 2005 11:42 AM
> Subject: Re: Team iBATIS releases iBATIS.NET 1.*.458
>
>
> On the SourceForge site, I amended the actual file names on the release
> bundles to leave out the "alpha" tag. The idea is that we can change the
> rating of the release without touching the download file. So, once we vote
> on a release, we can just change the release name without uploading the
> file
> again.
>
> The releases themselves are immutable. Once we release DataAccess 1.5.0,
> there will never be another DataAccess 1.5.0 release. If we need to make
> changes to move it to Beta or General Availability quality, then we would
> create 1.5.1. This is the approach that Apache HTTPD, Jakarta Tomcat,
> MySQL, and many others use now.
>
> I'll put the DataMapper 1.1.0 into production with my own applications
> today. I'm not using the DataAccess framework myself, but hopefully we can
> get sufficient feedback from the rest of the community.
>
> Of course, this is still a "SourceForge" release and not an "Apache"
> release. I'm sure we'll get the CVS and SVN repositories moved over soon.
> Once that step is done, we can apply for graduation and move to a top-
> level
> Apache project.
>
> One "TODO" for the iBATIS.NET RoadMap would be distributing separate code
> releases for the DataMapper and DataAccess frameworks. For now, we're
> posting a snapshot of the corresponding SVN revision, which is fine, but
> separate bundles would yield fewer questions.
>
> -Ted.
>
>
Re: Team iBATIS releases iBATIS.NET 1.*.458
Posted by Gilles Bayon <gi...@laposte.net>.
+1
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <ib...@incubator.apache.org>
Sent: Thursday, January 13, 2005 11:42 AM
Subject: Re: Team iBATIS releases iBATIS.NET 1.*.458
On the SourceForge site, I amended the actual file names on the release
bundles to leave out the "alpha" tag. The idea is that we can change the
rating of the release without touching the download file. So, once we vote
on a release, we can just change the release name without uploading the file
again.
The releases themselves are immutable. Once we release DataAccess 1.5.0,
there will never be another DataAccess 1.5.0 release. If we need to make
changes to move it to Beta or General Availability quality, then we would
create 1.5.1. This is the approach that Apache HTTPD, Jakarta Tomcat,
MySQL, and many others use now.
I'll put the DataMapper 1.1.0 into production with my own applications
today. I'm not using the DataAccess framework myself, but hopefully we can
get sufficient feedback from the rest of the community.
Of course, this is still a "SourceForge" release and not an "Apache"
release. I'm sure we'll get the CVS and SVN repositories moved over soon.
Once that step is done, we can apply for graduation and move to a top-level
Apache project.
One "TODO" for the iBATIS.NET RoadMap would be distributing separate code
releases for the DataMapper and DataAccess frameworks. For now, we're
posting a snapshot of the corresponding SVN revision, which is fine, but
separate bundles would yield fewer questions.
-Ted.
Re: Team iBATIS releases iBATIS.NET 1.*.458
Posted by Ted Husted <hu...@apache.org>.
On the SourceForge site, I amended the actual file names on the release bundles to leave out the "alpha" tag. The idea is that we can change the rating of the release without touching the download file. So, once we vote on a release, we can just change the release name without uploading the file again.
The releases themselves are immutable. Once we release DataAccess 1.5.0, there will never be another DataAccess 1.5.0 release. If we need to make changes to move it to Beta or General Availability quality, then we would create 1.5.1. This is the approach that Apache HTTPD, Jakarta Tomcat, MySQL, and many others use now.
I'll put the DataMapper 1.1.0 into production with my own applications today. I'm not using the DataAccess framework myself, but hopefully we can get sufficient feedback from the rest of the community.
Of course, this is still a "SourceForge" release and not an "Apache" release. I'm sure we'll get the CVS and SVN repositories moved over soon. Once that step is done, we can apply for graduation and move to a top-level Apache project.
One "TODO" for the iBATIS.NET RoadMap would be distributing separate code releases for the DataMapper and DataAccess frameworks. For now, we're posting a snapshot of the corresponding SVN revision, which is fine, but separate bundles would yield fewer questions.
-Ted.
RE: Team iBATIS releases iBATIS.NET 1.*.458
Posted by roberto <ro...@theaegis.org>.
Here's the original SF post from October:
https://sourceforge.net/forum/forum.php?thread_id=1164125&forum_id=376422
TinyURL: http://tinyurl.com/5wc7h
I'm going to double-check to see if there is a specific namespace test (if
not, it will be added).
Roberto
> -----Original Message-----
> From: Ron Grabowski [mailto:rongrabowski@yahoo.com]
> Sent: Thursday, January 13, 2005 3:09 PM
> To: ibatis-user-cs@incubator.apache.org
> Subject: Re: Team iBATIS releases iBATIS.NET 1.*.458
>
> > o Fixed support request 1050704, Unable to use <selectKey> with
> > useStatementNamespaces=true
>
> Where can I find more information on this. I checked here:
>
> http://sourceforge.net/projects/ibatisnet/
>
> and here (links to issues.apache.org...):
>
> http://tinyurl.com/45p34
>
> but couldn't find that bug. Are all selectKeys broken when
> useStatementNamespaces is set to true or just the ones that try to
> populate the parameterClass too? Is there a work around? I noticed
> there was a test case for this: "InsertCategoryViaInsertSatement".
>
Re: Team iBATIS releases iBATIS.NET 1.*.458
Posted by Ron Grabowski <ro...@yahoo.com>.
> o Fixed support request 1050704, Unable to use <selectKey> with
> useStatementNamespaces=true
Where can I find more information on this. I checked here:
http://sourceforge.net/projects/ibatisnet/
and here (links to issues.apache.org...):
http://tinyurl.com/45p34
but couldn't find that bug. Are all selectKeys broken when
useStatementNamespaces is set to true or just the ones that try to
populate the parameterClass too? Is there a work around? I noticed
there was a test case for this: "InsertCategoryViaInsertSatement".
Team iBATIS releases iBATIS.NET 1.*.458
Posted by Gilles Bayon <gi...@laposte.net>.
Team iBATIS releases iBATIS.NET 1.*.458
Build Date: 12-jan-2005
Build Number: 458
-----------------------------
1.*.458 Alpha - 12-jan-2005
-----------------------------
o Completed Documentation for DataAccess and DataMapper
o Added type (a CLR type) attribut in result and parameterMap element.
o Patch from Luke Yang
o Updated schema.
o Added explicit open/close connection for DataAccess framework.
o Added support for NHibernate in DataAccess framework
o Added optional tag 'daoSessionHandlers' in dao.config to support new
session handler (NHibernate)
o Changed 'name' attribut on 'context' tag to 'id' (dao.config)
o Changed 'name' attribut on 'daoSessionHandler' tag to 'id' (dao.config)
o Fixed JIRA IBATISNETo13
o Used Castle.DynamicProxy 1.0.3 for proxy.
o Fixed JIRA IBATISNETo12
o Added Unit Test for multiple/nested DAO Manager
o Added Xml Comment
o Fixed possible issue in ApplyParameterMap
(https://sourceforge.net/forum/message.php?msg_id=2841897)
o Added support for C# using syntax in DataAccess/DataMapper
* using ( IDalSession session = daoManager.OpenConnection() )
{
...db operations...
}
* using ( IDalSession session = daoManager.BeginTransaction() )
{
...db operations...
session.Complete(); // Commit
}
* using ( IDalSession session = sqlMap.OpenConnection() )
{
...db operations...
}
* using ( IDalSession session = sqlMap.BeginTransaction() )
{
...db operations...
session.Complete(); // Commit
}
o Added support for Distributed Transaction à la Indigo with
TransactionScope object in iBATIS.Common.Transaction
o Fixed bug for dynamic element isNotEqual (detected by Anders)
o Fixed possible issue in SessionContainer
o Refactoring of DaoSession
o Removed 'static' usage in DomDaoManagerBuilder
o Added support for embedded resource : only tag <properties ...>
<properties embedded="database.config, IBatisNet.Test"/>
and tag <sqlMap ...>
<sqlMap embedded="Account.xml, IBatisNet.Test"/>
will support it. Syntax for embedded attribut
'file name, the name of the assembly which contains the embedded resource'
o Removed 'assembly' attribut on <daoFactory> element of Dao.Config
the implementation structure attribut of <dao> element become the
namespaceoqualified name of the class is specified, followed by a comma,
followed by (at a bare minimum) the name of the assembly that contains the
class.
o Removed 'static' usage in DomSqlMapBuilder
o Moved Alias management to IBatisNet.Common.Utilities
o Fixed request support 1032436, ByteArrayTypeHandler misses the last byte
o Fixed support request 1050704, Unable to use <selectKey> with
useStatementNamespaces=true
o Added 'extends' attribute on statement, see Unit tests TestExtends*
o Improved configuration building
o Fixed issue on cache initialization
-Gilles
Team iBATIS releases iBATIS.NET 1.*.458
Posted by Gilles Bayon <gi...@laposte.net>.
Team iBATIS releases iBATIS.NET 1.*.458
Build Date: 12-jan-2005
Build Number: 458
-----------------------------
1.*.458 Alpha - 12-jan-2005
-----------------------------
o Completed Documentation for DataAccess and DataMapper
o Added type (a CLR type) attribut in result and parameterMap element.
o Patch from Luke Yang
o Updated schema.
o Added explicit open/close connection for DataAccess framework.
o Added support for NHibernate in DataAccess framework
o Added optional tag 'daoSessionHandlers' in dao.config to support new
session handler (NHibernate)
o Changed 'name' attribut on 'context' tag to 'id' (dao.config)
o Changed 'name' attribut on 'daoSessionHandler' tag to 'id' (dao.config)
o Fixed JIRA IBATISNETo13
o Used Castle.DynamicProxy 1.0.3 for proxy.
o Fixed JIRA IBATISNETo12
o Added Unit Test for multiple/nested DAO Manager
o Added Xml Comment
o Fixed possible issue in ApplyParameterMap
(https://sourceforge.net/forum/message.php?msg_id=2841897)
o Added support for C# using syntax in DataAccess/DataMapper
* using ( IDalSession session = daoManager.OpenConnection() )
{
...db operations...
}
* using ( IDalSession session = daoManager.BeginTransaction() )
{
...db operations...
session.Complete(); // Commit
}
* using ( IDalSession session = sqlMap.OpenConnection() )
{
...db operations...
}
* using ( IDalSession session = sqlMap.BeginTransaction() )
{
...db operations...
session.Complete(); // Commit
}
o Added support for Distributed Transaction à la Indigo with
TransactionScope object in iBATIS.Common.Transaction
o Fixed bug for dynamic element isNotEqual (detected by Anders)
o Fixed possible issue in SessionContainer
o Refactoring of DaoSession
o Removed 'static' usage in DomDaoManagerBuilder
o Added support for embedded resource : only tag <properties ...>
<properties embedded="database.config, IBatisNet.Test"/>
and tag <sqlMap ...>
<sqlMap embedded="Account.xml, IBatisNet.Test"/>
will support it. Syntax for embedded attribut
'file name, the name of the assembly which contains the embedded resource'
o Removed 'assembly' attribut on <daoFactory> element of Dao.Config
the implementation structure attribut of <dao> element become the
namespaceoqualified name of the class is specified, followed by a comma,
followed by (at a bare minimum) the name of the assembly that contains the
class.
o Removed 'static' usage in DomSqlMapBuilder
o Moved Alias management to IBatisNet.Common.Utilities
o Fixed request support 1032436, ByteArrayTypeHandler misses the last byte
o Fixed support request 1050704, Unable to use <selectKey> with
useStatementNamespaces=true
o Added 'extends' attribute on statement, see Unit tests TestExtends*
o Improved configuration building
o Fixed issue on cache initialization
-Gilles
Re: plaintext passwords and exposed sql in configuration files
Posted by Pablo Lopez <pl...@tecisa74.com>.
Gilles Bayon wrote:
> Some clarifications, there's no username/pass in the providers.config only
> in the sqlMap.config
You're right: I meant database.config, sorry for the mistake.
See you,
Pablo.
Re: plaintext passwords and exposed sql in configuration files
Posted by Pablo Lopez <pl...@tecisa74.com>.
Hi Gilles,
That's exactly what I was asking for, I guess it's the same solution
that Alexey proposed, but this mail has make it clearer for me.
Thanks a lot :)
Pablo.
PD: Sorry for attaching my company's vCard before, I think I've removed
it now.
> Some clarifications, there's no username/pass in the providers.config only
> in the sqlMap.config
>
> You must put the login/pass in the connectionsString of the dataSource
> element
> <dataSource connectionString="..." .../ >
> but if it is left empty, it's not a problem as you can assign the
> connectionSting of the datasource via the code
> as in
> just after the call to
> sqlMap = SqlMapper.Configure()
> you can access the connection string property
> by sqlMap.DataSource.ConnectionString, you can fill it at this time.
>
> -Cheers
>
> Gilles
Re: plaintext passwords and exposed sql in configuration files
Posted by Gilles Bayon <gi...@laposte.net>.
Some clarifications, there's no username/pass in the providers.config only
in the sqlMap.config
You must put the login/pass in the connectionsString of the dataSource
element
<dataSource connectionString="..." .../ >
but if it is left empty, it's not a problem as you can assign the
connectionSting of the datasource via the code
as in
just after the call to
sqlMap = SqlMapper.Configure()
you can access the connection string property
by sqlMap.DataSource.ConnectionString, you can fill it at this time.
-Cheers
Gilles
----- Original Message -----
From: "Pablo Lopez" <pl...@tecisa74.com>
To: <ib...@incubator.apache.org>
Sent: Wednesday, January 12, 2005 1:49 PM
Subject: plaintext passwords and exposed sql in configuration files
> Hi everybody,
>
> I'm new in using iBatis and I've managed to make it up and running,
> providing excellent features.
>
> But there's one problem that I've come across: the username and password
> used for the connection with the database are stored in plaintext,
> either in the sqlmap.config or in the providers.config files, as also
> all the SQL is in the datamaps.
>
> So, even if my application is quite secure, if the username, password
> and the SQL sentences in the datamaps are exposed, not only everyone can
> connect to the database, but he also knows the methods we use to access
> it, so my application security becomes useless.
>
> Is there any known solution for that? Or doesn't iBatis cover that
> problem and I must use the operating system features (for example file
> read permissions) to overcome that problem?
>
> People at my company are quite reluctant to use iBatis because of those
> two problems (username, password and SQL exposed in files) but I really
> want to give iBatis a try, so any kind of information in solving these
> issues would help a lot.
>
> I suppose I'm not the first one in having this issue, but I've searched
> google, iBatis documentation, etc... and found nothing about it (and the
> "archives" feature of this mailinglist
>
(http://nagoya.apache.org/eyebrowse/SummarizeList?listName=ibatis-user-cs@in
cubator.apache.org)
> does not seem to work.
>
> Thanks a lot,
>
> Pablo.
>
RE: plaintext passwords and exposed sql in configuration files
Posted by Alexey Boroday <a....@procreditbank.com.ua>.
Hello
I'm set up connection string manually - from application configuration
file. I store encrypted passwords in it. So in iBATIS file connectionString
attribute contains one space only.
You could ask password at runtime and concatenate it with the connection
string. Connection string should be ready ;) (ends with 'password=')
ConnectionString could be set via SqlMapper.DataSource.ConnectionString
All SQL statements will be transferred via network in plaintext AFAIK so
you should not care about it security ;)
But if you still want to be secure - encrypt iBATIS config files before
contribute it. You will need decrypt it in the runtime and configure iBATIS
with SqlMapper.Configure that takes XmlDocument as parameter.
Good luck
> -----Original Message-----
> From: Pablo Lopez [mailto:plopez@tecisa74.com]
> Sent: Wednesday, January 12, 2005 2:49 PM
> To: ibatis-user-cs@incubator.apache.org
> Subject: plaintext passwords and exposed sql in configuration files
>
> Hi everybody,
>
> I'm new in using iBatis and I've managed to make it up and running,
> providing excellent features.
>
> But there's one problem that I've come across: the username
> and password
> used for the connection with the database are stored in plaintext,
> either in the sqlmap.config or in the providers.config files, as also
> all the SQL is in the datamaps.
___________________________________________________________________________
This communication is confidential and may be legally privileged.
If you believe you are not an intended recipient, please inform the sender,
delete the e-mail and do not copy, print or use it or disclose it to others.
You can inform the sender by replying to this e-mail or by telephone (+380 44 4906080).