This is a discussion about <B>Microsoft Computing: ODBC Security</b>.<p align='center'><a href=http://www.mcpressonline.com/mc? This e-mail address is being protected from spam bots, you need JavaScript enabled to view it @.6b2216b1>Click here for the article</a>.</p>

Chris, this is a good article covering the issues and risks of ODBC security, but there are two areas that jumped out at me that call for clarification - one in the Exit Program section and one in the Password Sniffing section. <p>In the Exit program section you write... <p>"... there are no guarantees that third-party ODBC drivers call programs registered in the IBM exit points." <p>and... <p>"This means that your data is secure only when people are using the iSeries Access ODBC drivers, and that isn't an acceptable solution." <p>My concern about these two sections is that it could leave you readers with the impression that Exit Programs can't see activity generated by non-IBM ODBC drivers, and that is simply not true. <p>While I am also unaware of any third party ODBC drivers that use the *SQL and *SQLSRV IBM servers and their related exit programs, Non-IBM ODBC drivers use either the *DRDA or the *CLI server, for which there are exit programs. This means that you can see users who attempt ODBC over these routes, and that you can regulate the traffic. I'm not sure which release IBM added the *CLI exit point, but *DRDA has been around since V4R1. These exit points don't offer the same wealth of information as the *SQLSRV exit point, but you can easily prevent users from using these non-IBM ODBC drivers by restricting access to these servers. <p>Your article also states... <p>"Theoretically, you could interpret each SQL statement sent by client programs to determine whether the actions are permissible. However, this method has several problems. One problem is that taking apart each SQL statement as it is executed requires considerable overhead and will slow performance noticeably. Also, the program required to interpret the SQL statements correctly would be quite complex and difficult to program." <p>Exit Point Programming is not a trivial task, but it can be done well if one has the time and resources to focus on this discipline. It is for these reasons that most people choose to purchase an exit program solution that was professionally designed to overcome the obstacles you list. <p>With regard to password sniffing, I do not believe that iSeries Access suffers from this weakness. In all modern versions of iSeries Access (V3R2 and above), user ID's and passwords are never sent in clear text. Instead IBM flows a hash algorithm that the other side can use to check the password with, which makes sniffing them somewhere between extraordinarily difficult and impossible. <p>And if you've been watching the energy that IBM has devoted to promoting Kerberos and Single Sign-on, you'll see that there is a very elegant solution to authentication that can eliminate passwords on the iSeries altogether, thereby eliminating an area of vulnerability that is most often exploited. <p>Thanks for the article Chris, it covered a number of the security issues re: ODBC that the iSeries community should be thinking about. <p>Sincerely, <p>John Earl <BR>
CTO <BR>
The PowerTech Group