|
-- -- [ Picked text/plain from multipart/alternative ] John, I am unaware of hard-coded profile/passwords being mandatory, even in the new applications. I can see a good case for Level-10 security in many applications however and would find it inappropriate to require jumping through security hoops for any typical Level-10 uses. The more important question in my mind is: Is it clear to everyone what the different levels achieve, and are those different levels consistent and uniform throughout our own design and development strategy. -------------------------------------------- Booth Martin MartinB@Goddard.edu 802-454-8315 x235 -------------------------------------------- -------Original Message------- From: midrange-l@midrange.com Date: Monday, December 17, 2001 07:01:23 AM To: midrange-l@midrange.com Subject: Re: "Hard-coded" profiles/passwords (was RE: QUSER on ODBC requests ) Tom What do you think of Java and Websphere hard coding profile/passwords? It seems to me it's done thru-out this new stuff. No? John Carr 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 _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. . -- [ Content of type unknown/unknown deleted ] --
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.