At 09:51 AM 9/26/95 EDT, Evan wrote:
>Mark Bixby <[log in to unmask]> wrote:
>>We're involved in a major development effort on a new ODBC client / Allbase
>>server application suite.  We are concerned about our users bypassing our
>>official application code with off-the-shelf ODBC tools like MS Query, etc.
>>We are especially unnerved by the insecure way that ODBC handles the database
>>user ID and password:
>>        - User and password are stored in ODBC.INI in unencrypted cleartext
>
>Is that stipulated by ODBC specifications, or does the driver provider have
>an option of encrypting the user ID and password; I'm not at all clear on
>that...
Since the driver vendor controls both the client and host once the original
call is passed by the MS Driver manager, the driver can do whatever it
wants.  The specifications do not address the issue other than to provide
the "Connect String" which your application may pass to the driver and may
contain the UID and PWD.
 
>>
>>        - ODBC-level tracing with DRDBSP.EXE will reveal the user and password
>>          passed to SQLConnect
>
>I don't see that as much of a problem so long as access to tracing and
>diagnostic tools is controlled; after all, it used to be that when you
>dumped terminal buffers with TERMDSM you might catch passwords.
YES!  There is not much that we as driver developers can do until the call
gets passed to us at which time it is too late if someone is sharp enough to
insert their "driver" between the MS Driver Manager and our driver.
 
>>        - HP datacomm-level tracing with DISPLOG.EXE will reveal the user and
>>          password sent to the Allbase server
>Again, not a problem is access to tracing tools is controlled.
If the driver encrypts the info, then you would be OK.
 
>>        - "Sniffer" packet tracers from a remote location could trap these
>>          cleartext user IDs and passwords travelling over the network.
>There's no more exposure here than there is with a user logging on from a
>terminal; in both cases user IDs and passwords are visible.
EXACTLY!  What do we do in this case now?
Actually, if the data transmission is encrypted, the problem is solved for
most purposes.
 
[remainder deleted]
 
If the communication stream between the client and host components is
encrypted, the two holes are:
1) Insert a "driver" between the MS Driver manager and the "real" driver.
This would allow the lurker to see the connect string containing UID and PWD
in plain text.  The solution to this is to have the driver prompt for the
PWD interactively at run time rather than embed it into the client(s) such
as Impromptu.
 
2) Insert a "sniffer" into the host to trap calls to DBOPEN and the various
Allbase calls.  This hasn't been an issue as long as I have been in the
HP3000 community (20+ years) and is somewhat challenging technically.
 
<PLUG>
Call 1-800-ANSWERS for info on our approach to this issue or for more info
on ODBCLink.
</PLUG>
 
Brian Duncombe ([log in to unmask]) - M.B. Foster Software Labs
"Inside every large program is a small one struggling to get out."
          C. A. R. Hoare