> Makes me glad I havn't used the parse option (what is it for?)
the only thing I know about it has been taken form odbc faq:
Parse Statements option -- driver parses the SQL statement and retrieves
characteristics such as precision, nullability, aliases, etc. for the
columns.
I'd like to know in which situations it's useful and when it can be safely
turned off.
>
> > > 5) I disagree. If I'm having problems connecting I want to see all
> > > the options in the connection string. Don't log when you're not
> > debugging,
> > > it slows everything down.
> >
> > You can find the authentication response into the backend logs (like the
> > (in)famous "password authentication failed for user admin")
> >
> yes, but it doesn't give the ODBC side of the story.
>
> > Instead somebody could activate the logger without my authorization
> > (consider a pc that shares the hard drive, just put the right reg file
> > into
> > the startup folder and wait for the next reboot - considering win9x
> > stability you don't have to wait too much :-)) - so that the log can be
> > produced... you can grab the password from a network environment even
> > without ever seeing that pc).
> > I think it's a security risk.
> >
> True. Howeversomeone could just make a little alteration to
> the source, recompile the ODBC driver then drop it into \windows\system.
> Having sensitive areas of the disk shared is inherently unsafe. Or someone
> could write a wrapper DLL that just passed everything along while grabbing
> the PWD. Or drop a Trojan into your startup to expose your PC. I suppose
> these would be trickier, but not ridiculously so. Maybe have two driver
> builds. A production model that disables logging (plus anything else
deemed
> a risk) and a developer version that allows it to be enabled. I really
must
> get MSVC so I can fiddle with the driver like this.
making two versions of odbc could be an idea.
certainly in a production environment it's a risk to cache locally a plain
text password.
regards,
David Ciarniello
