I still get mildly shocked, in a mild English “I need a strong cup of tea” kind of way, by how many IBM i shops I walk into (or remote into) where the security officer password is still the factory default.
Yes. QSECOFR / QSECOFR.
On production systems. In 2026.
And that’s before we even get to the service accounts with *ALLOBJ that are happily sitting behind web-facing interfaces. But we’ll come back to that particular horror show in a minute.
The Default That Refuses to Die
IBM ships every single system with the same password for the QSECOFR user profile:
text
Password = QSECOFRIt’s set to expired, so the very first time you sign on you’re forced to change it. That’s the theory.
In practice? Plenty of sites change it once during the original install… and then never again. Or they reset it during some recovery drama and “forget” to put a proper one back. Or the only person who knew the real password left three years ago and the current team just reset it to the default because that’s what the IBM documentation shows.
Same story with the Service Tools (DST/SST) version of QSECOFR. Completely separate entity, but same default password and it has to be entered in uppercase. Related classics that still turn up:
- QSRV / QSRV
- 11111111 / 11111111 (gone in 7.5, thank goodness)
- 22222222 / 22222222 (also gone in 7.5)
IBM themselves describe these published defaults as “the first choice of anyone who is trying to break into your system.” They’re not wrong.
Real-World Settings That Make Me Wince
Here’s the sort of thing I still see far too often:
System values that scream “please attack me”:
- QPWDLVL still sitting at 0 or 1 (max 10 characters, limited character set)
- QPWDMINLEN = 6
- QPWDEXPITV = NOMAX (or 999)
- QPWDRQDDIF = 0 (you can reuse the same password forever)
- QSECURITY still on 30 or lower on systems that have never been properly locked down
User profile habits that make security people cry:
- QSECOFR enabled and used for day-to-day work
- Multiple people knowing the QSECOFR password
- Service accounts (web services, EDI, file transfer, monitoring tools, etc.) created with *ALLOBJ special authority “just to make it work”
- Those same *ALLOBJ service accounts left with passwords that never expire and are shared in spreadsheet or sticky note form
I once saw a web-facing service account with *ALLOBJ, password equal to the profile name, and the profile name was something charmingly descriptive like WEBSERVICE. The application was internet-accessible. I needed a lie-down.
What You Should Actually Be Doing
- Change both QSECOFR passwords (operating system profile and the Service Tools ID) to something proper. Store them somewhere secure that at least two trusted people can get to in an emergency.
- Stop using QSECOFR for normal work. Create named profiles with the special authorities you actually need. Keep QSECOFR for the rare occasions you genuinely need it (and consider leaving it DISABLED most of the time).
- Run this regularly:text
ANZDFTPWD ACTION(*REPORT)Then actually fix what it finds. - Raise the password bar:
- Set QPWDLVL to 2 or 3: This allows for passwords up to 128 characters long and full character support, including special characters. Level 3 adds case sensitivity and Unicode support.
- Require a minimum password length: Set QPWDMINLEN to a value greater than 10 to ensure passwords are at least 10 characters long.
- Enforce password rules: Use QPWDRULES to require digits, letters, and special characters in passwords.
- Add extra security: Consider using QPWDRQDDIF to require new passwords to differ from the last three characters, and QPWDPOSDIF to require a change in at least four positions.
- These settings help ensure that passwords are complex and secure, reducing the risk of unauthorized access. It is important to test the changes to ensure they are working correctly before applying them system-wide.
- Force regular changes on high-privilege profiles.
- Service accounts are not special. If an account needs to talk to the outside world (or even just to another system), it almost never needs *ALLOBJ. Give it the minimum authority required and put a proper password on it. If the vendor says “it needs *ALLOBJ”, push back. Most of the time they’re just being lazy. Correction – All of the time they’re just being lazy!
Final Thought
I’ve lost count of the number of sites where the most powerful profile on the system is still protected by the same password that was published in the installation guide twenty-odd years ago… while service accounts with *ALLOBJ sit there web-facing with passwords that haven’t changed since the last major upgrade.
It’s not clever. It’s not “we’re too busy”. It’s just poor hygiene.
Change the bloody password. Then go and check those *ALLOBJ service accounts.
You’ll sleep better.
