Re: Privileges by session

From: Michael Fontana <>
Date: Fri, 8 Jan 2010 15:49:14 -0600 (CST)
Message-ID: <>

There are standardized security protocols in the market to handle such issues, were they unable to be dealt with by removing them from the code.

Ideally, there should be no hard-coded passwords in application source. This is very dangerous in that it can be easily uncovered by outside entities, which is even a bigger problem than internal people having access.

Secondly, even if this were true, we've had developers send the source code to security and operations with instructions on how to change and compile the code before implementation, so that the developers would not know it's value.

It all comes down to the political necessity of securing applications. It is not a technical issue at all. When there are tasks to be done to secure an application, and a company doesn't really want to pay the cost to implement it, this indicates it's true priority.

  • Original Message ----- From: "Thomas A. La Porte" <> To: Sent: Friday, January 8, 2010 3:13:36 PM GMT -06:00 US/Canada Central Subject: Re: Privileges by session

If the developers own the source code for the app, and the application user password is stored in the source code of the application, changing the password will, of necessity, entail informing the developers of the new password.

This is no where near "best practices" from a security standpoint, but it is such a common occurrence in all of our environments that the discussion here is worthwhile.

On Fri, 8 Jan 2010, Joan Hsieh wrote:

> I don't get it, even hard coded in the app. There must be a way to change the
> pw. In our peoplesoft environment, the sysadm pw on dev and production are
> different. All the developers must logon as their individual account which
> grant a select role privilege. No one knows the sysadm (application account)
> pw except dba and peoplesoft admin.
> Blanchard, William wrote:
>> Correct.
> --



Michael Fontana 

Sr. Technical Consultant 

Enkitec M: 214.912.3709 



Received on Fri Jan 08 2010 - 15:49:14 CST

Original text of this message