"Hard-coded" profiles/passwords (was RE: QUSER on ODBC requests )

On Fri, 14 December 2001, rob@dekko.com wrote:

> Everyone may rant on how hard coding user id's and passwords are a bad idea
> but there are some applications where this is a necessity.  Well, I suppose
> you could put them in a dataarea or some such animal but you get the same
> results.

I think I have to agree with Rob on this to a degree. In the real world of 
interoperable and interconnected business systems, it's simply a business 
necessity at times to have applications exchange profiles/passwords without 
human interaction. You can't have absolute control over the practices of 
business partners.

However, at least a couple things can be done.

First, avoid protocols that transmit such info via clear-text (Duh!)

And second, rather than hard-coding, use soft-coding. The application itself 
should never need the actual profile/password. It should only need to know 
where and how to obtain it. Accessing it externally (and securely, of course) 
helps reduce the impact of the situation that started this debate -- i.e., even 
if the QUSER password is changed, big deal; the location containing the 
profile/password should simply be changed as well.

Of course, in that original situation (QUSER being used within an application 
without the knowledge of the tech responsible for QUSER), the system is 
effectively being held hostage by the application(s). If QUSER is being used 
without knowledge, it now becomes difficult to change QUSER password. The 
impact is currently unpredictable; and I'd find that unacceptable.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788
Fax  253-872-7904
http://www.400Security.com


___________________________________________________
The ALL NEW CS2000 from CompuServe
 Better!  Faster! More Powerful!
 250 FREE hours! Sign-on Now!
 http://www.compuserve.com/trycsrv/cs2000/webmail/