|
midrange.com
Good point about the programmer knowing the password. I suppose we could
have it call a QSECOFR owned program to generate a random password and then
bury that. And then call that program every x days. Would that suffice
for solving the knowing it in the first place, and changing it on a timely
basis?
This kind of stuff is used all the time. From the 400's to clients, from
clients to 400's, and between 400's and other servers.
For example. I have an EDI system. No sane person runs their EDI system
interactively. These EDI systems sign in to VAN's to transfer data. Each
of these require a userid and a password. Every package you buy for the
400 to communicate with these VAN's store these passwords in a file
somewhere.
<snip>If the User/password within the program means that no one needs to
sign onto the machine, does that mean no one is monitoring the machine in
any shape or form?<endsnip>
Good grief no! In theory they are signing on to the system - just not via
a 5250 screen. And it is a batch process. And yes there are hundreds of
other users who use sign on to the system interactively, and many of them
via 5250 screen. Does that mean that they are monitoring the system? I
guess that can be intrepreted by what you mean by monitoring.
Rob Berendt
==================
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"alan shore"
<SHOREA@dime.com> To: <midrange-l@midrange.com>
Sent by: cc:
midrange-l-admin@mi Fax to:
drange.com Subject: RE: QUSER on ODBC
requests
12/14/2001 04:08 PM
Please respond to
midrange-l
Your too late. The buried password is available to a walking/talking
individual who can give it out to anybody else. That person is the one who
wrote/changed the program in the first place. Not only that, but the
password within that program will NOT change (major security risk) until it
is forced to do so, and then the program will need to be changed for that
password.
I'm sorry if this seems to be flogging a dead horse, and I am all for
automation, but I cannot see why a program needs this data in the first
place.
The profile/password is used to access the AS/400. If the User/password
within the program means that no one needs to sign onto the machine, does
that mean no one is monitoring the machine in any shape or form?
>>> <rob@dekko.com> 12/14/01 03:59PM >>>
In our business this is required. There are workarounds but we believe in
progress and will not hire people to do things that can be automated. Look
at it this way - which is a bigger security risk: a buried password only
available programmatically, or yet another walking talking individual who
gives the password out to his/her supervisor when asked?
Before I get into a discussion on automation being exploitation and
displacement of individuals let me say that the users would rather this
stuff run automatically than have to key mindless stuff in.
Rob Berendt
==================
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"alan shore"
<SHOREA@dime.com> To:
<midrange-l@midrange.com>
Sent by: cc:
midrange-l-admin@mi Fax to:
drange.com Subject: RE: QUSER on
ODBC requests
12/14/2001 03:46 PM
Please respond to
midrange-l
Absolutes is ALL our auditors speak in. We have no need to use RUNRMTCMD,
but saying that, we have been informed that this command is NOT to be used,
UNLESS a valid User Profile/password is PROMPTED for. ABSOLUTEly NO
hard-coded user/passwords to be implemented, AND we are talking immediate
dismissal if this is discovered. So by that virtue, NO RUNRMTCMD.
Is there any reason why this is required - and no other method/procedure
can be utilized?
>>> <rob@dekko.com> 12/14/01 03:32PM >>>
Isn't it so nice to spout in absolutes?
And how, pray tell, would you have a batch program, like RUNRMTCMD, access
your 400? Force it to only run interactive and prompt the userid and
password?
Rob Berendt
==================
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"alan shore"
<SHOREA@dime.com> To:
<midrange-l@midrange.com>
Sent by: cc:
midrange-l-admin@mi Fax to:
drange.com Subject: RE: QUSER on
ODBC requests
12/14/2001 02:10 PM
Please respond to
midrange-l
Speaking from experience, ANY application that requires a hard-coded User
Profile/password SHOULD be rejected by both the internal and external
auditors of any savings and thrift. The same would go for any shared User
Profiles.
>>> <rob@dekko.com> 12/14/01 02:05PM >>>
Nothing is impossible but you can make it difficult. Store it into a
variable at run time by unscrambling something. Or don't use the variable
but start concatenating several strings together in the CALLP itself.
Repeat. Given enough time, talent and drive anything can be cracked. You
can only take reasonable steps. Look at IBM - they can tell you what your
last 32 passwords are. "Oh well, that's IBM." If you feel that way - look
at all the tools and utilities that Pentasafe has for security and you'll
quickly realize that IBM isn't the only tool in the box. There are just
times when you need to 'hardcode' a userid and password.
Frankly one of the things I miss about PC support versus Client Access is
the ability to start the connection with a batch file and have the user id
and password buried in there. Now we have to tell every supervisor that
fires up this shop floor control PC to use the same user id and password or
the control programs from the 400 won't work. I wouldn't be surprised to
see a post it note on the PC with this. (See RUNRMTCMD.)
Rob Berendt
==================
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"Gary Monnier"
<garymon@powertechg To:
<midrange-l@midrange.com>
roup.com> cc:
Sent by: Fax to:
midrange-l-admin@mi Subject: RE: QUSER on
ODBC requests
drange.com
12/14/2001 01:49 PM
Please respond to
midrange-l
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: midrange-l-admin@midrange.com
[mailto:midrange-l-admin@midrange.com]On Behalf Of Steve Martinson
Sent: Friday, December 14, 2001 10:22 AM
To: 'midrange-l@midrange.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: bdietz@3x.com [mailto:bdietz@3x.com]
Sent: Friday, December 14, 2001 11:55 AM
To: midrange-l@midrange.com
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-L-request@midrange.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-L-request@midrange.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-L-request@midrange.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-L-request@midrange.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-L-request@midrange.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-L-request@midrange.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-L-request@midrange.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-L-request@midrange.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-L-request@midrange.com
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.
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.
