Re: Client/server security

Hi! Nils.Myklebust@idg.no (Nils Myklebust) wrote: >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. >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. Certainly, but each ODBC-driver passes his statements to odbc.dll that can be traced with tools like ODBC-Agent by Leading Edge. Search for ODBC and TRACE at Lycos and you will find a link amongst the first five entries found. So you can spy out the password passed to the ODBC driver manager, that will alway be plain, unencrypted ASCII. >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. Even without any knowledge in any programming language the big hole in such mechanism is the open interface ODBC itself. >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.) Yes, see above. >Problem 3 above may be the most difficult to solve. My addendum to problem 1 is the worst thing, I'm afraid. Bis denne, Volker. ---------------------------------------------------------------------- Ich habe Londo das Leben gerettet, weil im All alles Leben heilig ist. Aber wenn derjenige, den man gerettet hat, diesen Glauben nicht mit einem teilt, hat man der Gegenwart gedient, indem man die Zukunft geopfert hat. (Lenier in Babylon 5) ----------------------------------------------------------------------