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

[MacWheel99@xxxxxxx]

I believe that Q* passwords that are *NONE cannot be signed on & used like
users.
I believe that Q* identities that we use periodically for a variety of
functions need to have their passwords changed from time to time, just like
we ask users to do, in fact I think the Q* passwords ought to be changed more
often than we ask of the users, precisely because of the risk of abuse.
Now when we change a Q* password & notify the people who are authorized to
know that Q* password, the abuse applications may break & identify
themselves, then we have to decide what to do about each case.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)

   Tom Liotta wrote
>  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.