question about plain text password in db2cli.ini 
Author Message
 question about plain text password in db2cli.ini
HI,

When I try to connect db2 client to server throught ODBC using
"Server" authentication , I found the password is written into the
db2cli.ini file.
It is not secure.
Is there any way to prevent it?



Wed, 26 May 2004 04:28:26 GMT
 question about plain text password in db2cli.ini

Hi Jane,

The only way I was able to re-create that was to go through the ODBC
Driver Manager configure the source, and put in my Username/Password in
the CLI/ODBC Settings.  If these are left blank then the driver will
prompt you for the information (and it won't be saved in the db2cli.ini
file).  Or if you want the UserID just to be saved, only enter that,
etc.  HTH

I've had many users who save their password and then freak out when they
see me bring it up in notepad (usually because they call me when they
can't connect after changing their password). =]

Does anybody know if this password in the ini file might be encrypted or
have some sort of security in future versions of the Runtime client?

Regards,
Jamie

Quote:

> HI,

> When I try to connect db2 client to server throught ODBC using
> "Server" authentication , I found the password is written into the
> db2cli.ini file.
> It is not secure.
> Is there any way to prevent it?



Wed, 26 May 2004 04:56:38 GMT
 question about plain text password in db2cli.ini

These files should be secured via the OS features.
Login, File Ownership, ...

The first step to acces the file is to logon on a Workstation.
Implied that if you can see the content of the file, someone has already the
password
to logon on the system

In the case of Jamie, the user is already logged on or is sharing the file.
That's where the security breach is.
If the user PC is off then Jamie is probably unable to use the notepad to
fix it.
(would have to logon first)

PM



Wed, 26 May 2004 12:32:01 GMT
 question about plain text password in db2cli.ini
You are correct, in my case I am already logged on as that user when Windows
NT/2000 is being used.

If a user is using Windows 95/98 this is not the case, as I can hit escape at
the login to the system and have at any files that I want, including db2cli.ini.

Either way, I don't like having any password being visible in plain text,
regardless as to who has access to the file.  If I get up and walk away from my
workstation without locking it (which I don't, but many people here do), I know
the worst someone could do is delete/corrupt files.  Were my password available
simply by double-clicking my db2cli.ini file and bringing it up in notepad, my
files, mail, information on the host, etc, is all subject to compromise (if the
passwords are the same, which for most of my users is the case).  The same
applies to anyone in the many groups that may have access to my C$ share in NT;
they can play with my files to their heart's content, but they can't do anything
to my password without knowing the old one first.

For the sake of users who do not know about this and save their password in
ODBC, I would like to see *some* sort of encryption applied to this in future
versions of the client.  Until then I will discourage any of my users from using
this feature.

Best Regards,
Jamie

Quote:

> These files should be secured via the OS features.
> Login, File Ownership, ...

> The first step to acces the file is to logon on a Workstation.
> Implied that if you can see the content of the file, someone has already the
> password
> to logon on the system

> In the case of Jamie, the user is already logged on or is sharing the file.
> That's where the security breach is.
> If the user PC is off then Jamie is probably unable to use the notepad to
> fix it.
> (would have to logon first)

> PM



Fri, 28 May 2004 22:50:54 GMT
 question about plain text password in db2cli.ini
1) NEVER register your password.
2) Use client authentication, limited to secure clients (e.g. NT/W2K/XP).
For W2K, use Kerberos authentication.
3) For non-secure clients (e.g. W95/98/ME), the user will be required to
enter his password.
4) See 1.

To resolve 3, upgrade to XP.


Quote:
> You are correct, in my case I am already logged on as that user when
Windows
> NT/2000 is being used.

> If a user is using Windows 95/98 this is not the case, as I can hit escape
at
> the login to the system and have at any files that I want, including
db2cli.ini.

> Either way, I don't like having any password being visible in plain text,
> regardless as to who has access to the file.  If I get up and walk away
from my
> workstation without locking it (which I don't, but many people here do), I
know
> the worst someone could do is delete/corrupt files.  Were my password
available
> simply by double-clicking my db2cli.ini file and bringing it up in
notepad, my
> files, mail, information on the host, etc, is all subject to compromise
(if the
> passwords are the same, which for most of my users is the case).  The same
> applies to anyone in the many groups that may have access to my C$ share
in NT;
> they can play with my files to their heart's content, but they can't do
anything
> to my password without knowing the old one first.

> For the sake of users who do not know about this and save their password
in
> ODBC, I would like to see *some* sort of encryption applied to this in
future
> versions of the client.  Until then I will discourage any of my users from
using
> this feature.

> Best Regards,
> Jamie


> > These files should be secured via the OS features.
> > Login, File Ownership, ...

> > The first step to acces the file is to logon on a Workstation.
> > Implied that if you can see the content of the file, someone has already
the
> > password
> > to logon on the system

> > In the case of Jamie, the user is already logged on or is sharing the
file.
> > That's where the security breach is.
> > If the user PC is off then Jamie is probably unable to use the notepad
to
> > fix it.
> > (would have to logon first)

> > PM



Sun, 30 May 2004 16:32:24 GMT
 question about plain text password in db2cli.ini
Those are good guidelines (ones I follow myself for the most part).  I'll be
sure to pass those on to the 2000+ people scattered all over the globe whose
clients I support that might unwittingly save their password or have a different
NT password than their password on the host.  Hopefully Jane (the original
poster) can apply these, unfortunately I can't.

It's impossible to police users to make sure they *don't* save their passwords
in their ODBC settings.  It's also ludicrous to ask them to spend <insert large
amount of money here> to upgrade to 2000/XP/whatever so we could use the client
authentication across the board (this would be *really* nice for this and many
other reasons, but not probable).

I realize that if even if the passwords were encrypted, they could be easily
decrypted and used by someone who knows what they're doing.  I guess it'd just
be a tad more comforting to know that a user can save his or her password
(intent on doing so aside) and not make it available to someone who can double
click on an INI file and have at their password.

This is more of a question to those at IBM than a "How do I work around this"
type of thing.

Best Regards,
Jamie

Quote:

> 1) NEVER register your password.
> 2) Use client authentication, limited to secure clients (e.g. NT/W2K/XP).
> For W2K, use Kerberos authentication.
> 3) For non-secure clients (e.g. W95/98/ME), the user will be required to
> enter his password.
> 4) See 1.

> To resolve 3, upgrade to XP.



> > You are correct, in my case I am already logged on as that user when
> Windows
> > NT/2000 is being used.

> > If a user is using Windows 95/98 this is not the case, as I can hit escape
> at
> > the login to the system and have at any files that I want, including
> db2cli.ini.

> > Either way, I don't like having any password being visible in plain text,
> > regardless as to who has access to the file.  If I get up and walk away
> from my
> > workstation without locking it (which I don't, but many people here do), I
> know
> > the worst someone could do is delete/corrupt files.  Were my password
> available
> > simply by double-clicking my db2cli.ini file and bringing it up in
> notepad, my
> > files, mail, information on the host, etc, is all subject to compromise
> (if the
> > passwords are the same, which for most of my users is the case).  The same
> > applies to anyone in the many groups that may have access to my C$ share
> in NT;
> > they can play with my files to their heart's content, but they can't do
> anything
> > to my password without knowing the old one first.

> > For the sake of users who do not know about this and save their password
> in
> > ODBC, I would like to see *some* sort of encryption applied to this in
> future
> > versions of the client.  Until then I will discourage any of my users from
> using
> > this feature.

> > Best Regards,
> > Jamie


> > > These files should be secured via the OS features.
> > > Login, File Ownership, ...

> > > The first step to acces the file is to logon on a Workstation.
> > > Implied that if you can see the content of the file, someone has already
> the
> > > password
> > > to logon on the system

> > > In the case of Jamie, the user is already logged on or is sharing the
> file.
> > > That's where the security breach is.
> > > If the user PC is off then Jamie is probably unable to use the notepad
> to
> > > fix it.
> > > (would have to logon first)

> > > PM



Mon, 31 May 2004 04:02:48 GMT
 
 [ 6 post ] 

 Relevant Pages 

1. db2cli.ini question

2. Default schema in db2cli.ini intermittantly ignored

3. Cannot set SCHEMA in db2cli.ini

4. Settings in DB2CLI.INI

5. Login and password are transported in plain text?

6. Login and password are transported in plain text?

7. Passwords in plain text in bytecode using JDBC API

8. Password protection - don't want to store password as plain test

9. Getting plain/text from text/html????

10. Programming an Interbase Filter to decode RTF Text to ASCII Plain text

11. Bypassing Password in a ODBC Connection (REG x INI)

12. Bypassing Password in a ODBC Connection (REG x INI)


 
Powered by phpBB® Forum Software