If you have a vendor that hard codes user profiles and passwords into their products, you better take very close look at that vendor. Any vendor hard coding profiles and passwords has access to your system(s). If you have a program with a hard coded password dump the object (DMPOBJ). Scan the resulting dump for the password. Can you find it? -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of Steve Martinson Sent: Friday, December 14, 2001 10:22 AM To: 'email@example.com' Subject: RE: QUSER on ODBC requests This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. -- [ Picked text/plain from multipart/alternative ] I believe what Kurt was addressing by saying "BAD IDEA" was the simple fact that you don't want to just start playing around with business systems in the middle of the day, as the "playing" may impact the processes. So, he also asked, if you end up affecting the ability to conduct business as usual, how are you going to get the password set back to what it was hard coded for? Then you're really screwed, because the CEO will be down in your neck of the woods spouting numbers about how much money the down time is costing him!! I'm sure that among those who are security conscious, there is nearly unanimous agreement that IDs and PWDs should not be hardcode. A good QA and change management process can catch those before they get into production. The bottom line here is that you must be cautious when troubleshooting. By the way... Motion Seconded! re: the comment about not using "Q" profiles for daily processes. Steve -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] Sent: Friday, December 14, 2001 11:55 AM To: firstname.lastname@example.org Subject: RE: QUSER on ODBC requests One vote for good one vote for bad.......any others?....... I lamented whether or not I would suggest changing the password, I had thought about just disabling the profile but thought it could cause other problems. I do not believe it is good practice to use ANY of the "Q" profiles for day-to-day activities. These should be assigned to a profile created to meet company naming/authority standards. This was mearly a troubleshooting exersize. Bryan ======================================================== GOOD IDEA! My experience has been that administrators, not to mention managers, want to know if applications have hardcoded passwords. ========================================= BAD IDEA. If you change the password for QUSER and there are applications with user and password hardcoded then they will stop working. Clearly you don't know if this is the case so how are you going to set the password back? =========================================== John one way to check and see if it is really QUSER, Change the password for QUSER. If QUSER is hardcoded into a DSN or some such thing this would surely break it. You should then be able to narrow down what is happening. _______________________________________________ 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-Lemail@example.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ 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-Lfirstname.lastname@example.org Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.