Thread: Password security [where is the password]

Hi list,

I would like to know where is the password setted on the connection Dialog. If it remains after the client shutdown it must be in some place in the hard disk. I am afread about it. Can anyone tell me if someone can catch it (hacker) ?


Regards
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                                  Atenciosamente (Sincerely)
                        Ezequias Rodrigues da Rocha
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
A pior das democracias ainda é melhor do que a melhor das ditaduras
The worst of democracies is still better than the better of dictatorships
http://ezequiasrocha.blogspot.com/

> I would like to know where is the password setted on the connection Dialog.
> If it remains after the client shutdown it must be in some place in the hard
> disk. I am afread about it. Can anyone tell me if someone can catch it
> (hacker) ?

It's stored in registry:
System DSN:
HKLM\Software\ODBC\ODBC.INI\<DSN name> in string value Password.
All the users with access to the computer can read it (don't forgot
the network registry access).

User DSN:
HKCU\Software\ODBC\ODBC.INI\<DSN name> in string value Password.
If everything is properly only the user and Admin can read it.

File DSN:
in file
All the users with access to the file can read it.

Regards,

Luf

P.S. The admin could change the default ACL on registry tree.

Mon, Jan 22, 2007 at 09:39:17AM -0200, Ezequias Rodrigues da Rocha napsal(a):
> The latest item (FILE) where is it specifically?

Hmmm, what OS are you using?
I suppose it's Windows. Have you already used "ODBC Data Source
Administrator"? If you aren't  let's try it. It's located in Administrative
tools (in Control panel). There are some tabpages:
1) User DSN (stored in HKCU)
2) System DSN (stored in HKLM - you can specify the ACL with regedt32)
3) File DSN - you specify the file when you adding the DSN

> I must garantee that only admin users can see this password by now. Any
> other help

You can do it with 2) System DSN with correct registry ACL on the DSN or
with 3) File DSN with correct File ACL.

You have to try it yourself. I never need this.

Regards,

Luf

P.S. Please use group reply so users on the list could read it too.

> 2007/1/22, Ludek Finstrle <luf@pzkagis.cz>:
> >
> >> I would like to know where is the password setted on the connection
> >Dialog.
> >> If it remains after the client shutdown it must be in some place in the
> >hard
> >> disk. I am afread about it. Can anyone tell me if someone can catch it
> >> (hacker) ?
> >
> >It's stored in registry:
> >System DSN:
> >HKLM\Software\ODBC\ODBC.INI\<DSN name> in string value Password.
> >All the users with access to the computer can read it (don't forgot
> >the network registry access).
> >
> >User DSN:
> >HKCU\Software\ODBC\ODBC.INI\<DSN name> in string value Password.
> >If everything is properly only the user and Admin can read it.
> >
> >File DSN:
> >in file
> >All the users with access to the file can read it.
> >
> >Regards,
> >
> >Luf
> >
> >P.S. The admin could change the default ACL on registry tree.

2007/1/22, Ludek Finstrle <luf@pzkagis.cz>:


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                                  Atenciosamente (Sincerely)
                        Ezequias Rodrigues da Rocha
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
A pior das democracias ainda é melhor do que a melhor das ditaduras
The worst of democracies is still better than the better of dictatorships
http://ezequiasrocha.blogspot.com/

Mon, Jan 22, 2007 at 10:48:15AM -0200, Ezequias Rodrigues da Rocha napsal(a):
> 2007/1/22, Ludek Finstrle <luf@pzkagis.cz>:
> >Mon, Jan 22, 2007 at 09:39:17AM -0200, Ezequias Rodrigues da Rocha
> >napsal(a):
> >> The latest item (FILE) where is it specifically?
> >
> >Hmmm, what OS are you using?
> >I suppose it's Windows. Have you already used "ODBC Data Source
> >Administrator"? If you aren't  let's try it. It's located in
> >Administrative
> >tools (in Control panel). There are some tabpages:
> >1) User DSN (stored in HKCU)
> >2) System DSN (stored in HKLM - you can specify the ACL with regedt32)
> >3) File DSN - you specify the file when you adding the DSN
> >
> >> I must garantee that only admin users can see this password by now. Any
> >> other help
> >
> >You can do it with 2) System DSN with correct registry ACL on the DSN or
> >with 3) File DSN with correct File ACL.
>
> Many acronyms. My clients are Windows. I really don't know how to make this
> work. What is ACL ?

ACL = access control list
file ACL (in explorer mouse right click on file -> Properties -> tab Security)
registry ACL (in regedt32 choose the key and in menu Security -> Permissions)
DSN = ODBC DataSource

Let's run "DataSources (ODBC)" or how is the manager named in Control Panel,
define some DSN (User x System x File) and then let's try change the
ACL for it in registry or in filesystem. Then you can verify it as admin
and normal user.

Feel free to ask more if something doesn't work as you expect.
I hope I give you all informations what you need.

Regards,

Luf

> >> 2007/1/22, Ludek Finstrle <luf@pzkagis.cz>:
> >> >
> >> >> I would like to know where is the password setted on the connection
> >> >Dialog.
> >> >> If it remains after the client shutdown it must be in some place in
> >the
> >> >hard
> >> >> disk. I am afread about it. Can anyone tell me if someone can catch
> >it
> >> >> (hacker) ?
> >> >
> >> >It's stored in registry:
> >> >System DSN:
> >> >HKLM\Software\ODBC\ODBC.INI\<DSN name> in string value Password.
> >> >All the users with access to the computer can read it (don't forgot
> >> >the network registry access).
> >> >
> >> >User DSN:
> >> >HKCU\Software\ODBC\ODBC.INI\<DSN name> in string value Password.
> >> >If everything is properly only the user and Admin can read it.
> >> >
> >> >File DSN:
> >> >in file
> >> >All the users with access to the file can read it.
> >> >
> >> >Regards,
> >> >
> >> >Luf
> >> >
> >> >P.S. The admin could change the default ACL on registry tree.

I know that the correct odbc usage (on windows) is with a  "Application Server" on only one machine, but now we only have the capability to use direct connection.

Further more in the future we will implement a server application. Now I have another question:

My clients are Fat32 and I don't meant to change all clients to NTFS so my Security TAB doesn't appears (I consider it occurs becouse the Filesystem).

Did I correct ?

Thank you so much for the explanations.

Regards




--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                                  Atenciosamente (Sincerely)
                        Ezequias Rodrigues da Rocha
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
A pior das democracias ainda é melhor do que a melhor das ditaduras
The worst of democracies is still better than the better of dictatorships
http://ezequiasrocha.blogspot.com/

Mon, Jan 22, 2007 at 12:48:17PM -0200, Ezequias Rodrigues da Rocha napsal(a):
> Further more in the future we will implement a server application. Now I
> have another question:
>
> My clients are Fat32 and I don't meant to change all clients to NTFS so my
> Security TAB doesn't appears (I consider it occurs becouse the Filesystem).

Yes. You're right. All users are admins when you use Fat32. So you're
not able to store the password in the secure way on local machines.
You have to specify the password all the time or maybe some network
share from server should work?

Regards,

Luf

> 2007/1/22, Ludek Finstrle <luf@pzkagis.cz>:
> >
> >Mon, Jan 22, 2007 at 10:48:15AM -0200, Ezequias Rodrigues da Rocha
> >napsal(a):
> >> 2007/1/22, Ludek Finstrle <luf@pzkagis.cz>:
> >> >Mon, Jan 22, 2007 at 09:39:17AM -0200, Ezequias Rodrigues da Rocha
> >> >napsal(a):
> >> >> The latest item (FILE) where is it specifically?
> >> >
> >> >Hmmm, what OS are you using?
> >> >I suppose it's Windows. Have you already used "ODBC Data Source
> >> >Administrator"? If you aren't  let's try it. It's located in
> >> >Administrative
> >> >tools (in Control panel). There are some tabpages:
> >> >1) User DSN (stored in HKCU)
> >> >2) System DSN (stored in HKLM - you can specify the ACL with regedt32)
> >> >3) File DSN - you specify the file when you adding the DSN
> >> >
> >> >> I must garantee that only admin users can see this password by now.
> >Any
> >> >> other help
> >> >
> >> >You can do it with 2) System DSN with correct registry ACL on the DSN
> >or
> >> >with 3) File DSN with correct File ACL.
> >>
> >> Many acronyms. My clients are Windows. I really don't know how to make
> >this
> >> work. What is ACL ?
> >
> >ACL = access control list
> >file ACL (in explorer mouse right click on file -> Properties -> tab
> >Security)
> >registry ACL (in regedt32 choose the key and in menu Security ->
> >Permissions)
> >DSN = ODBC DataSource
> >
> >Let's run "DataSources (ODBC)" or how is the manager named in Control
> >Panel,
> >define some DSN (User x System x File) and then let's try change the
> >ACL for it in registry or in filesystem. Then you can verify it as admin
> >and normal user.
> >
> >Feel free to ask more if something doesn't work as you expect.
> >I hope I give you all informations what you need.
> >
> >Regards,
> >
> >Luf
> >
> >> >> 2007/1/22, Ludek Finstrle <luf@pzkagis.cz>:
> >> >> >
> >> >> >> I would like to know where is the password setted on the
> >connection
> >> >> >Dialog.
> >> >> >> If it remains after the client shutdown it must be in some place
> >in
> >> >the
> >> >> >hard
> >> >> >> disk. I am afread about it. Can anyone tell me if someone can
> >catch
> >> >it
> >> >> >> (hacker) ?
> >> >> >
> >> >> >It's stored in registry:
> >> >> >System DSN:
> >> >> >HKLM\Software\ODBC\ODBC.INI\<DSN name> in string value Password.
> >> >> >All the users with access to the computer can read it (don't forgot
> >> >> >the network registry access).
> >> >> >
> >> >> >User DSN:
> >> >> >HKCU\Software\ODBC\ODBC.INI\<DSN name> in string value Password.
> >> >> >If everything is properly only the user and Admin can read it.
> >> >> >
> >> >> >File DSN:
> >> >> >in file
> >> >> >All the users with access to the file can read it.
> >> >> >
> >> >> >Regards,
> >> >> >
> >> >> >Luf
> >> >> >
> >> >> >P.S. The admin could change the default ACL on registry tree.
> >
>
>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>                                  Atenciosamente (Sincerely)
>                        Ezequias Rodrigues da Rocha
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> A pior das democracias ainda é melhor do que a melhor das ditaduras
> The worst of democracies is still better than the better of dictatorships
> http://ezequiasrocha.blogspot.com/

Hello,

I've read a post [1] about how MS Access is enjoyable and efficient when tables are connected to MS SQL.

But I have MS Access front end containing linked tables to Postgres via ODBC. And I'm struggling with slow performance.
WhenI want to open a table which contains about 8000 records it takes more then 20 sec. When I want to move cursor at
thelast record it takes more than 60 extra seconds. 
I'm not able to bind comboboxes directly to larger (more than 60 records) linked table because unrolling takes 20 sec.
All tables has defined primary key, of course.
I was trying to change indexes without any result.

I've already checked Postgres server log and MS Access queries are executed quickly (<500 ms).

Is this normal behavior? Does MS Access cooperates with MS SQL such better than with other DBMS via odbc?

Does anybody have better experience?

I was trying to communicate from ASP.NET with Postgres via OLE DB driver and it was without any performance problems.

Thank you

Jirka

[1]

http://www.utteraccess.com/forums/showflat.php?Cat=&Board=53&Number=1321886&Zf=&Zw=odbc%20myth&Zg=0&Zl=a&Main=1321886&Search=true&where=&Zu=&Zd=g&Zn=&Zt=1&Zs=a&Zy=#Post1321886&Zp=

Jiří Nouza wrote:

 > Hello,
> I've read a post [1] about how MS Access is enjoyable and efficient when tables are connected to MS SQL.
>
> But I have MS Access front end containing linked tables to Postgres via ODBC. And I'm struggling with slow
performance.When I want to open a table which contains about 8000 records it takes more then 20 sec. When I want to
movecursor at the last record it takes more than 60 extra seconds. 
> I'm not able to bind comboboxes directly to larger (more than 60 records) linked table because unrolling takes 20 sec

Aren't you turning on ODBC trace ?

regards,
Hiroshi Inoue

> But I have MS Access front end containing linked tables to Postgres
> via ODBC. And I'm struggling with slow performance. When I want to
> open a table which contains about 8000 records it takes more then
> 20 sec. When I want to move cursor at the last record it takes more
> than 60 extra seconds.
>
> I've already checked Postgres server log and MS Access queries are
> executed quickly (<500 ms).
>
> Is this normal behavior? Does MS Access cooperates with MS SQL such
> better than with other DBMS via odbc?

I see no description of your configuration.
What's your ODBC settings? What ODBC driver do you use? What OS?
I hope you haven't enabled the mylog output.
How long takes it the psql to show 8000 records?

BTW let's try play with "use declare/fetch" and "cache size" at first.
And mylog output could help you to see where's the problem.

Regards,

Luf

pgsql-odbc-owner@postgresql.org wrote:

> Hello,
>
> I've read a post [1] about how MS Access is enjoyable and efficient
> when tables are connected to MS SQL.
>
> But I have MS Access front end containing linked tables to Postgres
> via ODBC. And I'm struggling with slow performance. When I want to
> open a table which contains about 8000 records it takes more then 20
> sec. When I want to move cursor at the last record it takes more than
> 60 extra seconds. I'm not able to bind comboboxes directly to larger
> (more than 60 records) linked table because unrolling takes 20 sec.
> All tables has defined primary key, of course.
> I was trying to change indexes without any result.
>
> I've already checked Postgres server log and MS Access queries are
> executed quickly (<500 ms).
>
> Is this normal behavior? Does MS Access cooperates with MS SQL such
> better than with other DBMS via odbc?
>
> Does anybody have better experience?
>
> I was trying to communicate from ASP.NET with Postgres via OLE DB
> driver and it was without any performance problems.

Hi,

I'm using MS Access, ODBC and Postgresql in several places, with big tables as well, and I don't have any performance
problem.

I have always been using the default driver parameters, and it always worked for me. But maybe you should play with
thata little bit. And I think a few performance tuning tips have been discussed in this list in the past. 

One thing you have to check, is wether you are using the MS Access 2000 format, under MS Access 2003. There is huge
performanceloss in this configuration. Convert your database into the 2003 format, and problems will disappear. 

Second thing: have you the opportunity to run tcpdump somewhere between the server and the client? You can activate the
logof the server, too. This should give you useful "timing" informations. 

Cheers,

Philippe

Philippe Lang a écrit :
> I'm using MS Access, ODBC and Postgresql in several places, with big tables as well, and I don't have any performance
problem.
> I have always been using the default driver parameters, and it always worked for me. But maybe you should play with
thata little bit. And I think a few performance tuning tips have been discussed in this list in the past. 

I also use Access as a FrontEnd to PostgreSQL (we are migrating the backend).
The main problem is that all queries have to be written in PostgreSQL.
When joining linked tables in Access, performance is terrible ! I think I understand why, but some of my power-users
wouldlike to be able to create queries in Access and have no knowledge of SQL (so creating them in PostgreSQL is not an
option).

> One thing you have to check, is wether you are using the MS Access 2000 format, under MS Access 2003. There is huge
performanceloss in this configuration. Convert your database into the 2003 format, and problems will disappear. 

Good to know !
I might give MSAccess2003 a try then !


--
Arnaud

Oh, I'm still feeling like a BFU :(

I'm using the last one version of odbc driver (08_02_0200) on Windows XP, 2000. Access is 2000 and 2003.

Of course I had commlog and mylog turned on. But I've never thought that writing some kb (ok, few megabytes) of text
couldhave such big affect :( 
When I was trying common windows odbc trace the disk worked very hard but postgres log didn't make full use of hard
disk.

It seems that turning off helps very well. Access work  by now commonly fast.

8000 rows query is prosessed in 0.8 s, see log:
2007-01-23 00:01:42 odbcuser SELECT LOG:  00000: duration: 813.000 ms  statement: select * from osoby
It could be adequate I suppose. Postgres is on laptop.

I will try to change "use declare/fetch" and "cache size" but it is hard to debug via mylog because it is unbelievable
slow.

And try to convert Access file to 2003 version further.

Thank you very much I haven't to forget to check logging settings.

Jirka

> ------------ Původní zpráva ------------
> Od: Ludek Finstrle <luf@pzkagis.cz>
> Předmět: Re: [ODBC] linked tables in MS Access
> Datum: 23.1.2007 10:26:52
> ----------------------------------------
> > But I have MS Access front end containing linked tables to Postgres
> > via ODBC. And I'm struggling with slow performance. When I want to
> > open a table which contains about 8000 records it takes more then
> > 20 sec. When I want to move cursor at the last record it takes more
> > than 60 extra seconds.
> >
> > I've already checked Postgres server log and MS Access queries are
> > executed quickly (<500 ms).
> >
> > Is this normal behavior? Does MS Access cooperates with MS SQL such
> > better than with other DBMS via odbc?
>
> I see no description of your configuration.
> What's your ODBC settings? What ODBC driver do you use? What OS?
> I hope you haven't enabled the mylog output.
> How long takes it the psql to show 8000 records?
>
> BTW let's try play with "use declare/fetch" and "cache size" at first.
> And mylog output could help you to see where's the problem.
>
> Regards,
>
> Luf

Tue, Jan 23, 2007 at 11:21:58AM +0100, Jiří Nouza napsal(a):
> Of course I had commlog and mylog turned on. But I've never thought
> that writing some kb (ok, few megabytes) of text could have such big
> affect :(

mylog is very detailed log (all SQL statement all getted values, ...)
and it's called very often in the code.
psqlodbc.log should be ok (there are few informations).

> It seems that turning off helps very well. Access work  by now commonly fast.
>
> I will try to change "use declare/fetch" and "cache size" but it is
> hard to debug via mylog because it is unbelievable slow.

You don't need it if it's ok now for you. Use declare/fetch convert
SELECT statements to cursor so the result is fetched in "cache size"
blocks. Sometime it helps sometime it kills the performance.

Regards,

Luf

> > ------------ Původní zpráva ------------
> > Od: Ludek Finstrle <luf@pzkagis.cz>
> > Předmět: Re: [ODBC] linked tables in MS Access
> > Datum: 23.1.2007 10:26:52
> > ----------------------------------------
> > > But I have MS Access front end containing linked tables to Postgres
> > > via ODBC. And I'm struggling with slow performance. When I want to
> > > open a table which contains about 8000 records it takes more then
> > > 20 sec. When I want to move cursor at the last record it takes more
> > > than 60 extra seconds.
> > >
> > > I've already checked Postgres server log and MS Access queries are
> > > executed quickly (<500 ms).
> > >
> > > Is this normal behavior? Does MS Access cooperates with MS SQL such
> > > better than with other DBMS via odbc?
> >
> > I see no description of your configuration.
> > What's your ODBC settings? What ODBC driver do you use? What OS?
> > I hope you haven't enabled the mylog output.
> > How long takes it the psql to show 8000 records?
> >
> > BTW let's try play with "use declare/fetch" and "cache size" at first.
> > And mylog output could help you to see where's the problem.
> >
> > Regards,
> >
> > Luf
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq