Re: Security options at different SQL-Databases with ODBC - who is best ?

guest wrote: You might want to tell us who you are. In the meantime I'll take your argument at face value. They are wrong and bad. I thought I explained the issues well enough below, and it has also been discussed enough not that long ago. However the issue is: 1. I develop a client application that can do updates to the server database via sql. (Not stored procedures.) It runs on a client computer (MS Windows in our case, but it could be another OS. Even Unix.) 2. The user has a login name and password used to run the application. This login name is defined to the database and to be able to run the application this user must have the necessary rights so the application can do the updates to the database. Usually update, insert and delete to one or more tables and/or columns in the server database. 3. The user has (or installs) ODBC on his PC. Starts MS Access. Selects the menu option to connect to one of the tables the application in 1 above updates. He is asked for a loginname and password. He supplies the same as the one he gives when running the application. Voila - he gets the table displayed in a grid on his screen. 4. The user can now go to any column/row, type anyting and the table is autmagically updated in the serve database. Nice! Or may be not? What do I do? Openlink has done as well as they can within the limitations they have. But it's a proprietary solutions, and only partial. Does DCE or Kerberos solve the problem? May be. I don't know. The major reason for that is these products aren't easily available. Few people know about them. They are complex. They are expensive, at least when I have asked last. Correct me if I am wrong, and explain exactly how the above problem can be solved with these products. :In <53qrcr$8dk@nntp.idgonline.no> Nils.Myklebust@idg.no (Nils Myklebust) :wrote: :: Micorsoft seems to believe that free access by everyone to all data in :: all databases is the best situation for everyone. : : No comments. : :: There is *no* mechanism built into ODBC to protect any data from free :: manipulation by any user *if* that user has access to some application :: that can do such updates. :: ... If i write a Visual Basic application using :: the Microsoft recomended way of updating data via ODBC, there is no :: standard mechanism in ODBC or anywhere else that can stop that user :: from staring MS Access, connecting to that same database via the same :: ODBC interface, giving the same username and password used for that :: application, and then manipulate the data in any way that user wants. : : If you are talking about ODBC as an implemention of CLI(ANSI or X/Open), : then you need specify which driver(s) you are talking about because : your statement is not true for ODBC drivers in general. If you are : talking about ODBC as an specification, than, you should understand : specifiction usually not offer(or build) very much *mechanism(s)*. : The only mechanism I know that ODBC preassumed is dynamic driver : loading. Usually is not interesting. Not to me at least. : For most desktop databases and their ODBC drivers, your statement : is absolute correct. However, those databases themself don't have : much mechanisms to do the protection(because there are no way to : do that without system has mechanis to protect the low level files : themselves). Thus, why bother to secure ODBC access to those : databases without securing the database engines themselves. It has : not to much sense to secure you windows without secure your door(s). : I believe this may be one reason that most desktop database ODBC : drivers don't have a real build in mechanism to protect unauthorized : access. We are *not* talking about desktop databases at all. : For database drivers for Oracle, Informix, etc. Then, you need first : answer do you allow remote native access. If you still allow remote : native access, then there are not too much sense if native client : library and network layer don't secure themselves. Many ODBC drivers : for this class of databases are build as simply a wrap of the original : native client library. then, the whole access authentication, data : transport encryption etc. are all responsible by native library. : A wraper can't/needn't do any thing beyond what the native library. : Because, even an ODBC wraper does something beyond native library : protection, an user is still easily to bypass it by using native : client directly(that is same as you protect your window without : protecting your door). If you disallow remote native access but only : use your own network layer plus a local native access on the server : host, then it is up to this particual gateway driver(or mulit-tier : driver) to implement all of access/information protection. There are : far too many ways to do all of those things, for example use DCE or : Kerberos for authenticatioin and public key data encryption, etc.etc. : and most of them can easily fit into ODBC's frame. I know many these : kind of multi-tier drivers(and the middleware servers) already did : these(i.e. using DCE/Kerberos as well as public key on wire encryption). : Of cause, 1. you still need system support to protect unauthorized : local access from file level. 2. you still can access a datasoure : with password you get form someone mouth, but it is his/her problem : not ODBC's, not DCE's and not Kerberos', etc. etc. You are right in that any native library also need the same protection built in. That was allready said some time ago and not repeated by me now. The problem with the login name/password isn't that I get it from someone else. I get it from myself. I allready have it for one application. The issue is that it musn't be usefull for some other application run by the same user. This is what OpenLink has solved to some extent. Does DCE or Kerberos solve this? Or does one of your other "far to many" ways of solving "this" actually solve the problem we all have? If so, please describe the solution with excample of products that do. : :: Microsoft and others should be pressured into doing something about :: this totaly unacceptable situation. Any help in doing this would be :: much appreciated. : : You should clearfy what is the unacceptable situation. I.e. is what : appeared in desktop databases ODBC driver implemention or is what : appeared on native remot access implementions or is what appeared : on multi-tire driver/server implementions? For the first case, the : solution is change your OS. For the 2nd case, the solution is : either fix/enhance the native implemention or simply avoid use : native remote access before it has been done and replacing it with : a multi-tire driver/server architecture. For the 3rd case, it is up : to an implemention to do it(and already many many did it) within : the frame of ODBC. But all of these are implemention issues(and : technically can/already easily be solved) not a problem of MS ODBC, : ANSI CLI, X/Open DBC or SQL in general. Many many? Who. Nobody in this group at least have been able to point to anything better than the OpenLink solution. And this *is*