Password authentication Universe on AIX
Sart Bimpson
on an AIX 5 unix box. We use the AIX user account to log on to the
Universe system. I would like to create a simple c program on AIX
that will test a users user name and password. I will then be able to
call this routine from Universe to test a users name and password.
This way when people log on to generic group user accounts I can use
there individual user name and passwords to authorize advanced
features.
The program should be really basic. Something along these lines
TEST_PASSWORD user_name password
The routine could then return the a text result such as "PASSED" or
"FAILED"
I could examine the output in Universe to determine the if the user
really is a "power" users or just a toadie!
It should not be difficult.... my Universe skills are fine but I am
struggling with the AIX program.
Thanks
Tony Gravagno
the challenge is to work on your C skills then another forum might be
better.
You don't need C. The /etc/passwd file identifies all users and their
primary group Ids. The /etc/group file has all groups, their names
and ID's, and the users assigned to them. I believe you should be
able to check these files from Universe if you have the proper
permissions.
Another way to do this would be with a shell script:
# code not verified
ME=$(whoami)
if [ ME = "sbimpson" || ME = "slimpson"]
then
echo "poweruser"
elif [ ME = "rbubble" ]
echo "normaluser"
else
echo "toad"
fi
Putting passwords in scripts that you execute from the command line is
considered bad security.
HTH
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Sart Bimpson
I don't have an issue reading the user names from UNIX. What I am
struggling is testing that users password. I need confirmation that
the user who is accessing a higher level function is that user. I
know that this is not an issue if that user logged on initially... but
in this case they are not the user that is logged on. For example...
We have a system where a toadie can log on and log some lab
information against our product. If that lab information is out of
spec the material gets quarantined and can not be used unless a
supervisor releases the product. One way would be for the power user
to log on themselves and release the product - I don't wish to do that
- too many steps. I would like the toadie to remain logged in but
the power user be able to walk up to the terminal and "override" the
quarantine - by supplying their log on name and password.
x
> the power user be able to walk up to the terminal and "override" the
> quarantine - by supplying their log on name and password.
From my own experience there are several issues with this approach.
After a little while:
1) To save on typing the supervisor is going to use a very simple
password.
2) The toad will sit in its (his/hers) chair and the supervisor will
type over toad's head therefore the supervisor's keystrokes will be
visible to the toad.
3) In the end the supervisor will shout the password and ask the toad
to do the change.
If you are in a situation where the supervisor has to service several
requests, the aggravation factor will be enough to jump in no time to
number 3 above.
I would suggest to have the supervisor sitting at his/hers desk and
manage the approval process from there.
Instead of waiting for input from the console, your process should
write a message to a file and wait.
The supervisor may check the file and answer, let's say Yes/No to each
request, then the toad's program will check the file every so often,
10 seconds or so, to see if the Yes/No field has been updated and
continue its work accordingly.
Lucian
Sart Bimpson
You are probably correct. Regardless I would like to find a solution
to my original problem. There are other reasons for wanting this
ability... I just don't wish to go into them. If you know how this
can be achieved please let me know. Else I will have to surrender and
resort to Reading the AIX manual....... I would rather peel my
eyeballs.
Tony Gravagno
Maybe this is over-simplifying, but you could just exec a command that
does a loopback telnet to localhost:
EXECUTE "SH -C telnet localhost"
The manager can enter his/her login info, do the function, and when
he/she exits, processing is returned to the line after the EXECUTE.
That solution is not elegant at all but I think going through a real
login is better than capturing a user/password in your application
code and then passing it in an Execute to a shell prompt. Go ahead
and shell out with a command like "ps -ef | grep grep" and you'll see
your own command in the open - it's just not secure.
Have you tried "su" or "sudo"?
Also lookup writing an Expect script. That's probably your best bet.
T
x
The link below may help.
http://www.chm.tu-dresden.de/edv/manuals/aix/libs/basetrf1/getuserpw.htm#A16691aca
Lucian
x
handy to play with.
There are at least 2 functions, "getuserpw" and "getuserpwx" that
should return a pointer to a structure that contains the password.
The password should be encrypted.
To encrypt your user's plain password you should use the "crypt"
function.
The problem is that this function uses a "salt" value.
This value is probably same for all passwords in the "etc/passwd"
file.
You should get a known password and test the "salt" until the result
from "crypt" matches the "upw_passwd" value returned by "getuserpwx".
If the "salt" is different from user to user, you may store a list of
found "salt" values for each user and still preserve the security of
the system, but at a lesser level of course.
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/getuserpw.htm
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/crypt.htm
Lucian
x
If you have a known, pretty static, list of "supervisors" you can
easily create your own security file.
Have a restricted program that would allow a supervisor to enter a
password.
For security reasons, this password should be different from their
login password !
Take the plain password and encrypt it as you like.
Then, your test user program would check the entered password against
your private security file.
Below you have the Basic programs to do that.
Lucian
SUBROUTINE CODE(PASS,BUFF)
* PASS : Plain user password
* BUFF : Encoded string
* Look in the documentation an pick an algorithm; these are 2 I know
of
ALG = 'aes-128-cbc' ;* 128 bit AES-128
ALG = 'rc2-cbc' ;* 128 bit RC2
INBUFF = 'JFw;K0J-KJkjbi;3unv0[3mSC' ;* Any string, make it long
KEY = ICONV(PASS,'MX') ;* Plain password converted to
hex
IV = ICONV('k.','MX') ;* SALT value in hex
ACTION = 2 ;* Output string in Base64
BUFF = '' ;* Must be defined
STAT = ENCRYPT(ALG,ACTION,INBUFF,1,KEY,1,3,'',IV,BUFF,1)
RETURN
END
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OPEN 'SUPERVISOR-FILE' TO FILE ELSE STOP
CRT 'Enter login ID ':
INPUT ID
ID = TRIM(ID)
IF LEN(ID) ELSE STOP
ID = UPCASE(ID)
READ REC FROM FILE, ID ELSE REC = ''
CRT 'Enter new password ':
HUSH ON
INPUT PASS1
HUSH OFF
PASS1 = TRIM(PASS1)
IF LEN(PASS1) ELSE STOP
CRT 'Enter new password ':
HUSH ON
INPUT PASS2
HUSH OFF
PASS2 = TRIM(PASS2)
IF LEN(PASS2) ELSE STOP
IF PASS1 = PASS2 ELSE
PRINT 'ERROR - mismatched password'
STOP
END
IF LEN(REC) THEN
CRT 'Enter old passowrd ':
HUSH ON
INPUT PASS3
HUSH OFF
IF PASS3 = REC ELSE
PRINT 'ERROR - Invalid old password'
STOP
END
END
CALL CODE(PASS1,BUFF)
WRITE BUFF ON FILE, ID
END
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SUBROUTINE TEST.USER(OK)
OK = 0
CRT 'User ID ':
ID = UPCASE(TRIM(ID))
IF LEN(ID) ELSE RETURN
OPEN 'SUPERVISOR-FILE' TO FILE ELSE RETURN
READ REC FROM FILE, ID ELSE RETURN
CRT 'Password ':
HUSH ON
INPUT PASS
HUSH OFF
IF LEN(PASS) ELSE RETURN
CALL CODE(PASS,BUFF)
IF BUFF = REC THEN OK = 1
RETURN
END
Peter McMurray
I have no doubt that entering a supervisor password is a pain in the nether
regions for busy operators and supervisors as we replaced that system with a
much simpler solution because of all the reasons already mentioned.
The supervisor simply issues a code from a master list that the operator
enters. At an appropriate time - daily, monthly, whatever - the manager
does a list of the altered documents by code and operator and checks that
all is sweet. One manager who had several depot area credit supervisors
simply photocopied a page of random numbers and wrote the operator details
next to the number he issued, in that way nobody could guess the next number
and bypass him. This works just as easily over the phone as shouting across
the office.
As for checking passwords there is a very simple way in D3. We simply
convert the password entered using the standard ICONV(PASSWORD,"UC") and
compare the converted variable with the entry in the USERS file.
Peter McMurray
"x" <lucia...@yahoo.com> wrote in message
news:9b095e10-a8b4-451b...@x16g2000prn.googlegroups.com...
x
Change:
IF PASS3 = REC ELSE
PRINT 'ERROR - Invalid old password'
CALL CODE(PASS3,BUFF)
IF BUFF = REC ELSE
PRINT 'ERROR - Invalid old password'
Change:
CRT 'User ID ':
ID = UPCASE(TRIM(ID))
CRT 'User ID ':
INPUT ID
ID = UPCASE(TRIM(ID))
lamb1962
I had a bad experience with "su" and "sudo". The fellow that setup the
security behind them did not understand the needs of root. There were
phantoms that needed to be kicked off in the nightly process. If
something caused a break in the nightly process I would have to manually
kick off the phantoms as the user root. I explained many times there was
a difference and it took the screen shots to prove it to the boss to
either restore root or take responsibility for the processes.
Just thought I would pass that along.
Laurie