Re: ODBC SQL security issues???

} We're developing a client-server, ODBC SQL suite of applications, and a number } of security issues are troubling us: } } 1) Embedding logon ID & password information in cleartext ODBC.INI files does } not seem to be terribly secure. Do you use this method, or do you force the } end-users to manually enter this info every time they connect to the database? } In my applications I default the ODBC datasource and database name and accept only the password from the user. If you make the user enter the password when he runs the remsql backend then the ODBC does not request for the password (this avoids the user entering the password every time he runs the application before booting the system). I do not store the password anywhere (.ini's). } 2) If you're storing an encrypted password in your own specialized .ini file } that you retrieve and decrypt prior to connecting to the database, are you } worried that the password might be revealed by ODBC driver tracing programs or } LAN sniffers? } i am not sure (I think the ODBC encrypts and stores the password internally) } 3) You've created database logon IDs & passwords, and you've granted read/write } access to the tables each user needs to access via the application. But what } do you do about Joe or Jane Poweruser who goes down to their neighborhood } software store and buys an ODBC-compliant SQL query/update tool, and they go } and modify tables in harmful ways not permitted by the applications } themselves? } Create table views for each table in the database and restrict all theselects by user-id (grant permissions to views but not to tables). All the updates can be restricted by using database triggers or by using stored procedures within your applications to do the updates. Contact if you need any examples. (I did an entire application using these techniques in Visual Basic) } Feel free to comment on any additional issues not listed above. } } Thanks! } -- } Mark Bixby Internet: markb@cccd.edu } Coast Community College District 1370 Adams Avenue } District Information Services Costa Mesa, CA, USA 92626 } Technical Support (714) 432-5064 } "You can tune a file system, but you can't tune a fish." - tunefs(1M) } +---------------------------+--------------------------+ | G.T.Madavan, | e-mail: gtmad@smi.mn.org | | 501 East Hwy 13, Suite 112| | | Systems Migration Inc., | Phone : (612) 890-0040 | | Burnsville, MN, 55337 | Fax : (612) 890-0966 | +---------------------------+--------------------------+ Disclaimer: The author's opinions are his own, and not necessarily those of Systems Migration Inc.