Re: Increase Security

In article <472v99$fak@flood.weeg.uiowa.edu> dshirazi@labyrnth.uhl.uiowa.edu (Dariush Shirazi) writes: >Subject: Re: Increase Security >From: dshirazi@labyrnth.uhl.uiowa.edu (Dariush Shirazi) >Date: 30 Oct 1995 16:42:17 GMT >In article <ian.goddard.33.0015B6E5@geo2.poptel.org.uk>, > ian.goddard@geo2.poptel.org.uk (Ian Goddard) writes: >> >>It seems to me that we need the client/server protocols to enable a client >>*program* to identify itself in a manner which will be proof against tampering >>(as far as this is possible) and will let the server check the client against >>an approved list. As a by-product this would also enable the server lock out >>incorrect versions of the clients. Whilst it's easy to define the >>requirement, however, it's less easy to see how it might be met. Anyone got >>any ideas? >> >Again, this can be done using the same thing. All you have to do is to make >the program switch into another user once the first user is authenticated. >I think newera can do this. >Also, Informix 7.1 or 7.2 has a role future. I think it should do what you >want. But how do you know that the program which is switching the user ID is an auhorised program? My point here is that we may be dealing with an authorised user (authenticated by password or instant DNA profile - whatever you can achieve and deem necessary!) with legitimate access to the database and tables, running from an authorised client workstation (authenticated, say, by Kerberos) but running an unauthorised APPLICATION. The application may be one the user has written or bought from an unauthorised source or even a former authorised program which has been replaced by a newer version. How do we recognise that this is an unauthorised version? We cannot rely on simply having the application simply say "I am program x" in plain text in the source code. We need at least to have the identification provided by some shrouded means. Some form of digital signature should be built into the protocols. I reiterate "protocols" here because I think this should be a standard means of client-server communication; what I am thinking of is a secure CLI. Bearing in mind that the executable program may have SQL strings which could be altered with a debugger the signature mechanism should be sensitive to changes in the executable - perhaps based on a checksum of the executable itself. This, of course, raises the issue of a flexible from end such as Dbaccess or Isql, both as a tool for entering raw SQL and as an interpreter of Perform or Ace. In the latter case perhaps the authentication would be based on the .per or .arc files although I think it more likely that one would rank them with raw if one were thinking of security. A tool capable of entering raw SQL would only be permitted to privileged users. The requirement, therefore is for a means of authenticating the application, difficult to fake and sensitive to changes in the applications. The applications and users would them become dimensions of an authorisation matrix. Perhaps the client workstation would also be included, making this a 3-dimensional matrix. If one were really concerned about security one might also require the server to authenticate itself to the client. As I said in the original posting, the requirement is easier to define than to answer. I do, however, believe that the answer must be implemented at protocol level and must be based on a digital signature. Ian