Re: logon trigger - getting program version information of application connecting

On Tue, 16 Mar 2004 21:03:56 -0000, "Niall Litchfield" <niall.litchfield_at_dial.pipex.com> wrote:

><OracleSupport-dropthis_at_shaw.ca> wrote in message
>news:r08d50lbh7k83435n23tmg04skrgona0pi_at_4ax.com...
>> On Mon, 15 Mar 2004 10:18:32 -0000, "Niall Litchfield"
>> <n-litchfield_at_audit-commission.gov.uk> wrote:
>>
>> >Do the users have their own oracle accounts or is there one for the app.
>We
>> >have the same problem with the latter scenario and just change the db
>> >password and only distribute the password to new releases - done at
>install
>> >of new release time.
>>
>> There are two levels of security (if you can call it that).
>>
>> The first level is handled by the application which stores a userid,
>> password combination for each user and a few other details in an
>> encrypted file outside the database. The second level connects all
>> users to the databases with a single (schema) password. I believe this
>> was a carry over from the initial application design when it didn't
>> use Oracle at all. The developers must have felt it was too much work
>> to do the security properly (or a nice way to cut corners and reduce
>> costs).
>>
>> As the application does the "real" security check, changing the schema
>> password has no effect on the users as long as they get authenticated
>> by the front end.
>
>I don't understand this. if you change the schema password (which must be
>stored in the app somewhere) and then only distribute the new password with
>the new version of the app doesn't that achieve what you want? Or are you
>saying that the schema password is stored in the app AND CANNOT BE CHANGED
>because all versions of the app have the same password. That would be
>remarkably stupid.
>

Now we get into why certain companies should step away from application design altogether. Although it's not quite as bad as locking in the schema password, it's pretty close.

This is an MS Windows application and what the geniuses decided to do was force the location of the server side components (security module among other things). They HARDCODED the share name into the application, as well as a few other things, so ALL (upgraded) versions of the application are installed in exactly the same place on a given server (can't run multiple versions off the same box, at least without doing several hacks).

Thus, any client pointing to a given server always finds the security module in exactly the same place. The connection to the security module is also hardcoded (they didn't change this value between the two versions as it too would have solved this problem) so the client gets verified first with the module and then the module provides the connection information to the database. I can change the schema password at any time and only have to change the encrypted value in the application's security module for the connection to be made. Sometimes without seeing these "design features" first hand, it's hard to describe.

I think you coined it perfectly... "That would be remarkably stupid." Pretty much describes the security implementation of the application.

A workaround to all this could have been installing the new version on a different server altogether. That way, all previous versions would have been pointing to the old security module location. I had only given this a cursory look due to what would be entailed in moving the application and I only had the one available box that was sized appropriately (a quite different build compared to my other Windows based application servers). Next upgrade I may not have a choice.

I was able to find several other workarounds in our test environment, but all were the result of doing one hack or another (which I wouldn't allow in our production environment anyway). I provided the software vendor with several easy to implement changes that would make life much easier, so I only hope they take heed.

There are several functions this application does extremely well, security was definitely not one of them. Based on what I've seen with this application, they had at least three separate groups doing the programming / design, with very little communication between them.

I won't even get into the difficulties in trying to tune this beast, the two (Windows) applications we run that are designed even worse (one actually writes to the system schema, preventing more than one installation of the application in a given instance - I was able to at least convince management to replace this application once the current usage ends later this year), or the obsolete NT4 / Oracle 7.3.4 database applications that are still being used in production, not to mention...

Any time I try to explain some of these issues to colleagues, I get pretty much the same response - why couldn't you just make this change, or why would you make it that complicated just...

At least I have quite a few very interesting projects on the go, a great team behind me, and upper management that doesn't usually make things worse (the latter item is often the most difficult to find).

Having a hybrid environment; OS's, databases, lan's/wan's, e-business and other web applications, development, datawarehouse, replication models and a variety of other things, make the interesting far outweigh the frustrating.

>>
>> Our stats today showed an abysmal 75% success rate for the workstation
>> upgrades.
>
>about par.
>
>> Working with these types of applications certainly make the job more
>> challenging.
>
>indeed.

Ciao,

Brad Received on Tue Mar 16 2004 - 23:36:54 CST