Informing the IBM Community

Protecting against user enumeration in IBM i


I was discussing an RFE (Request For Enhancement) with some CEAC colleagues the other day. A request has been made for IBM to formally address the ability to Enumerate User Profiles on IBM i.

Now, user enumeration is not something you hear a lot about in the IBM i world yet by default it is possible on any IBM i Server and to be blunt, it’s easier to do on IBM i than on many other platforms. The good news is it’s easy to address on virtually any version of IBM i.

What is User enumeration?

Put simply, user enumeration is when a malicious actor uses a brute-force technique to either guess or confirm valid users in a system.  Once you know these, you can start to work on working out what the passwords might be.

I’m going to spend the next few paragraphs showing some examples of the issue, if you just want to get to the solution, you will be forgiven to skipping down to the section titled “How do you prevent this sort of user enumeration?”

How do can you enumerate users?

The easiest way to demonstrate User Enumeration is at the IBM i Sign On Screen. 

If you type in a user name that you know exists and get the password wrong you get a message at the bottom of the screen:

CPF1107 – Password not correct for user profile

If you type in a user name that does not exist, you get a message at the bottom of the screen:

CPF1120 – User DUFF_USER does not exist.

So, if you repeat this process given enough time you can put together a list of valid users, this is User Enumeration.  As mentioned earlier, once you know a user, you can then start working on hacking the password.

Does limiting signon attempts help?

Now, at this point many of you will say “Hang on a minute” I disable user profiles that have too many invalid login attempts and disable user profiles if someone does this. 

Sorry, that doesn’t help that much as if you try to signon with a user that has been disabled you still get a message like:

CPF1394 User profile ROWTON cannot sign on.

So, yes disabling user profiles does slow these attacks, especially if you have to keep reconnecting sessions but it does not stop it.

Other ways to enumerate

The problem is not limited to the 5250 Sign On screen, another common example is the Initial ACS Signon to IBM i, where you get a message like CPIAD06 – Invalid sign on attempt made.

How do you prevent this sort of user enumeration?

The answer is as simple as changing the messages you get when you fail to sign on. Fortunately, that is as simple as issuing a CHGMSGD change message description command for each message that could be used to enumerate.

You can make these changes whilst the system is in use, no need for downtime or asking anyone to sign out and you can reverse them in the exact same way.

So in my first example, we had message CPF1107 – Password not correct for user profile, using command:

CHGMSGD MSGID(CPF1107) MSGF(QCPFMSG) MSG(‘Invalid sign on attempt’)  

We remove the key piece of information that the user was correct and that just the password was wrong.

I would suggest you use exact same “Invalid sign on attempt” message text for the following messages:        

  • CPF1108 USRPRF &1 not found for JOBD &2 in &3.CPF1109 Not authorized to subsystem. 
  • CPF1109 Not authorized to subsystem.        
  • CPF1110 Not authorized to work station.
  • CPF1116 Next not valid sign-on attempt varies off
  • CPF1117 User &1 not accessible.                 
  • CPF1118 No password associated with user &1
  • CPF1120 – User &1 does not exist.
  • CPF1392 Next not valid sign-on disables user profile
  • CPF1393 User profile &2 has been disabled.               
  • CPF1394 User profile &1 cannot sign on.         
  • CPIAD06 – Invalid sign on attempt made.   

You can use the same CHGMSGD command for each, just changing the Message ID as appropriate.

ProTip: Technically, these changes could be reversed by a PTF install and will definitely be reserved when you upgrade the operating system.  So, keep an eye on them from time to time.

I’ve not performed an exhaustive search of all the messages that could appear so feel free to add a comment below with any you find.

A little good news

I took a quick look at the authentication behaviour in Navigator for i (Nav4i), FTP and SSH on IBM i and their default behaviour does not allow you to infer the users existence and so cannot be used to enumerate.

Have your say on this RFE

If you would like to have your say on this RFE, click the link below and add a comment.  Whilst you are there, add an RFE of your own!

With your help we can make IBM i better, more secure and thrive.  After all, a hundred small improvements would seem just as valuable as one big shiny new thing to this SysAdmin.

i-UG Goes Virtual

We have a major new first for the i-UG, because of Covid-19, we decided to go virtual and you guys did not disappoint, we had nearly 500 registrations from 15 countries and we raised nearly £15,000 for the key workers here in the UK via NHS together charity.

There is still time for you to donate at the following link:

Our next User Group Meeting will be in November for more details check out

Hope to see you there.

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.


3 responses to “Protecting against user enumeration in IBM i”

  1. Mike Ryan avatar
    Mike Ryan

    Scary how easily we can overlook something as important as this.

    I’ll be on to Developerworks right now…



  2. Justin Myers avatar
    Justin Myers

    Hi Steve. Thank you for this list. It us much more comprehensive than what we were using previously. In the “Other ways to enumerate” section you have a screenshot of two messages. Is there a way to change that MSGSY1007 message or is that built into the ACS software? Thanks!

  3. Glenn Gundermann avatar
    Glenn Gundermann

    Someone has created a duplicate RFE for this. I’m assuming then that IBM has not taken any action.

Leave a Reply

Your email address will not be published. Required fields are marked *