To answer both questions about unauthorized client access and then about encryption:
Brian wrote: >The only way is to add a new security layer to the >server. I think the way to do this on the client side (wherever the UO DLL is kept and a connection initiated) is to have a separate DLL which fully encapsulates UO and exposes all of the methods and properties, but adds a simple layer of authorization. Any authorized application built with this component would incorporate the key to unlock access to it - any code attempting to use the component without a valid key would fail to initiate a connection, let alone get to a user login. Doing this manually would involve way too much work, and a simple wrapper used by legit apps would still leave the uniobjects.dll on the client system for renegade coders, so it should be done by IBM. Two DLLs can be provided, one with the key mechanism and one without, and existing apps can choose which they want and swap references and recompile as they wish. Do I think this will happen with UO or any other MV connectivity component? Nah. Gerry wrote: >If you're not worried about every shmoe with a password >having access to your system why worry about session >encryption ? User/password authentication is pretty much the only thing most IT installations have for access control. When companies start using biometrics for fingerprint, voice, and retinal scans, things will get better, but even with this technology, an authorized user IS authorized when they have valid credentials. There's nothing you can do about this except implement server-side restrictions, field-level ACLs (not supported by U2 anyway), etc. If that privilege is being abused then less technical remedies need to be pursued, like job termination - or maybe baseball bats, an effective italian solution. The original thread point is that there can be abuse by people with credentials. My point on encryption was that even people without credentials can easily sniff the wire. Those are the people you really need to worry about. I'm not portraying either problem to be more or less significant, just pointing out yet another problem that's unfortunately industry-wide. Will wrote: >The point isn't whether you can "get in". The point is what >you can do once you "get in". That's yet another problem that's left to the app developers to solve. Related, but at another level, the database model itself isn't very secure either. Ask the MV DBMS vendors whether their product is SOX compliant and see what kind of response you get. Have a nice insecure day. ;) Tony Gravagno Nebula Research and Development TG@ removethisNebula-RnD .com ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
