Partner TechTip: Do "Sensitive" Commands Need Extra Security?

[efnkay]

I am curious on your thoughts about the QSYRUPWD and QSYSUPWD API's which are Retrieve Encrypted password and Set Encrypted password. Quite awhile back, I wrote a procedural interfce to these API's and used them in a small RPGLE program that would prompt for the Userid that I wanted to use.

ie. I supplied the Userid called 'CHUCK'...The program would then call the retrieve encrypted password api into memory for CHUCK, and then call QCMD. So having sufficient authority...I changed CHUCK's password, flip to another session and login as CHUCK, do what I want as CHUCK, then log out.

Flip back to the other session still on QCMD after changing CHUCK's password, and upon exit, my little RPGLE program sets the encrypted password from the same memory it was retrieved to. In other words, logon as another user, do whatever, log off and the User never knows the difference. All without ever knowing the user's original pasword.

Now here's the kick...I'm pretty sure even though we had password rules in place not allowing the re-use of "old" passwords, it still worked. Like these API's apparently worked underneath the covers of password rules. It was back at v5r4 I believe. Anyone have any thoughts on these API's.

There is equivalent SQL commands for doing the same within Oracle databases, don't know about any others at this point.

[BVining]

I'm sorry but that scenario doesn't make any sense to me. The QSYRUPWD API simply retrieves the encrypted password of the specified user profile. The API doesn't swap to that user profile nor do you get a clear text view of the password.

It sounds to me (and this is just a guess) like your RPG program is adopting authority (perhaps to allow access to the API as the API is shipped with a default public authority of *EXCLUDE and explicity requires that the caller have *ALLOBJ and *SECADM authorities)and this adopted authority is then being propagated to QCMD when you call it. That would be a definite security problem but not one related to your API usage -- it's related to program adoption and allowing access to a command entry panel while the adoption is still in effect.

Can you expand on why you believe the QSYRUPWD (and QSYSUPWD) APIs are creating this exposure?

[BVining]

Oh, forgot one item -- you had asked about password validation rules.

When you called QCMD I assume (guess really) you then ran the CHGUSRPRF command. The CHGUSRPRF command documents in the help text:

"Note: The new password is not checked against the
password validation rules. The password validation
rules are defined by i5/OS system values. For a
description of the password validation rules, see the
iSeries Security Reference, SC41-5302 book."

This is done in part so that a knowledgeable user can always set/reset a *USRPRF password. This is real handy when the password validation rules accidently create a situation where you cannot make a valid password for a profile such as QSECOFR and you also can't remember the current password

Again I'm just guessing on what you might be doing in your scenario. But I don't see where the APIs you mention come into play at all.

[efnkay]

Thanks for asking.The API's allow me to "get" and hold onto the encrypted password and use that retrieved password to set the password back to whatever it was when I'm done hi-jacking the *USRPRF without ever knowing the user's password to begin with, or having to tell the user that his password is/was changed...

Because it's back to whatever it was/is. You could always just change their password, logon, do something, logoff, tell the user what his/her password is now... I thought it brought a rather sneaky capability that could be used god-forbid in a less than desirable manner or intent.

I always believe however that it's convenient to be able to logon as the user does when chasing ghosts without having to share or forcibly change their password...And with this,
you're not really forced to tell the user you used their profile...Know what I mean? :-)

[efnkay]

Maybe this conversation I had would clear it up. Assume I didn't know his password because I don't have to know it to use his profile.

"Hey Chuck, I logged on as you, did a bunch of stuff, dinked around with stuff in your library and then logged off." How? You don't know my password! And I just logged on a minute ago using my same password as yesterday. You couldn't have changed my password...right? You wouldn't know it to change it back! Er...ee-yeah, that's right Chuck. :-)

[BVining]

Thanks for the clarification. Now I see the tie in with the APIs that I missed previously

That technique will certainly work though there will be clues available to Chuck if he were to look at his *USRPRF as QSYSUPWD will have updated the password and *USRPRF last change date. In addition audit records would be available depending on how the system is set up.

A less visible approach would be to use the Profile Handle APIs and get a profile for Chuck, swap to the profile, and then swap back to your profile when done. This allows you to be Chuck without having to change his password. Though in this case your job ID would continue to be yours, it's just the current profile that changes. This would also be audited depending on your system configuration.

Both approaches come down to you having the properly documented authorities so I don't see any need for "extra security" as you mentioned in the original posting. You might be able to have fun with Chuck, but from a system point of view nothing unusual is going on.

[efnkay]

Well you know I really wasn't sure what other legitimate purpose those particular API's served other than the need to get and set or use the encrypted password possibly to be "sent" in a login request to another system for yet another reason...???

Anyway I used the API's in that way "just to see" and for a little "fun" which includes playing with Chuck's mind. :-)

Although I could use that little trick to login as somebody else if needed, sounds like the API's you described (Which I haven't used yet.) would be better for that purpose assuming they can just continue your interactive session as if you were "Chuck".

It's all good. Thanks for saying so.