Re: Client/server security

In article <54bdp8$m8g@nntp.idgonline.no>, Nils Myklebust <Nils.Myklebust@idg.no> writes >I think, I think (I hope :-)... > >If Informix had implemented password checking on the set role statment >we could possibly have solved the security issues that have reasantly >been discussed in a very easy and elegant way. > >The statement would be: > >set role rolename identified by password > >We could then store the password somewhere in an encrypted form. It >could be in a database table every user had select rights only to. > >The application would then have to decrypt the password, plug it into >the above statement and execute it. We could write encryption and >decryption algoritms so that it whould not be easy for a user to >decrypt the password. In this way the user wouldn't be able to set the >role outside of an application that have the built in functionallity >to do it. > What stops the user disassemnling the application to see how it works? >I can see three possible holes in this: > >1. If you use the current I-Net or some primitive ODBC driver the >above set role statement would be sent in the clear over the net. It >would be relatively easy to see it. >With Openlink ODBC drivers there is an encryption option that could >solve this. >A malisious user could still run an ODBC spy on his own machine and >see the above statement. > >2. The encryption/decryption algorithm could be difficult or >impossible to write in such a way that someone couldn't do the same >thing. Additionally if it was done in a DLL on MS Windows it wouldn't >be too hard to use the functions in the DLL in some other program. >Even without documentation for the DLL. > >3. Someone with access to the real encryption/decryption algorithms >could use them to gain access to a database that he should not have >had. > >These are still only problems for those who require a fairly high >level of security. If you do there may be solutions using the >Universal Server. A datablade, spl or possibly Java code in the server >could be used to make the whole procedure fully secure - possibly. > >Does anyone see any problems with the above? (It's so easy to forget >some stupid little thing that opens glaring wholes in sceems like >this.) >Problem 3 above may be the most difficult to solve. Any concrete >ideas? Could one make it secure via a public key algorithm or in some >other way - even to those with access to the algorithms? >Whether these problems can be solved fully or not, I do at least >believe we could get another level of security in this way. > >Please respond even if you think it would work. > >If it works I will talk to Informix and get them to implement such a >password. (I am an optimistic person you see :-) >I will also urge everybody else to do the same - call or mail Informix >and say you need this. But *please* wait until we have gotten some >responses so we know that I haven't suggested something stupid! > > >Nils.Myklebust@idg.no >NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway >My opinions are those of my company >The Informix FAQ is at http://www.iiug.org > Have you considered looking at Online/Secure ? -- David Williams