× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




On 23/04/2008, at 11:53 PM, Ed Fishel wrote:


Perhaps you were looking for documentation in the wrong place. For example
one of the notes for the description of QPWDLMTCHR in the V6R1 information
center and Chapter 3 of the V6R1 Security Reference manual is this: "If the
QPWDRULES system value specifies any value other than *PWDSYSVAL, this
system value cannot be changed and its value will be ignored when new
passwords are checked to see if they are formed correctly".

I was looking in the Information Centre reference for QPWDRULES. I did not see any new option that mapped to the facility provided by QPWDLMTCHR. The QPWDRULES documentation listed the QPWD* system values that will be ignored so I saw no reason to to read the QPWDLMTCHR documentation (although I should have done).


You are probably already aware that QPWDLMTCHR is only enforced when
QPWDLVL is set to 0 or 1. The most popular use of QPWDLMTCHR is probably to
prevent the use of vowels in a password. It can also be used to prevent the
use of the letter Q (so users can't have passwords like Q123456 and then
just use 123456 as their password). QPWDLMTCHR can also be used to prevent
the use of the ten digits.

Actually I wasn't aware of that--at least if someone had asked me does QPWDLMTCHR take effect at password levels 2 or 3 I would have said "Don't see why not".

However, if I want to continue using password level 0 or 1 AND change to QPWDRULES it seems I cannot retain the behaviour of QPWDLMTCHR and that is not at all clear from the documentation.


I can say that our decision to not include the QPWDLMTCHR function in the
new QPWDLMTCHR system value was not an oversight. You are free to use the
old rules if you wish, so in that sense the old function was not removed.
If you use the new QPWDRULES system value then by specifying the minimum
number of digits, letters, and special characters you should be able to
prevent a dictionary attack. The *LTRLMTAJC value can also be used to
prevent a dictionary attack by not allowing any two letters to be next to
each other.

Ok, but if I want to use the new rules because it is simply easier to keep them in one place and I choose to remain with password level 0 or 1 you've just broken my password rules.

My point is that changing to use QPWDRULES is an administrator decision that does not require any approval because it (mostly) does not affect end-user behaviour--especially if the new rules simply implement the old ones just in a single place for the administrator's convenience.

Changing QPWDLVL is not an administrator decision because it has a significant effect on how users sign-on--not least of which is the case-sensitivity issue.

Now however, if I need to retain QPWDLMTCHR you have FORCED me to continue with the individual system values or write an exit program to support this behaviour.


It is my hope that most people that use QPWDRULES will be able to stop
using a password validation program. These programs are risky because they
are passed both the old and new password of the user. The risk is that
someone could change the program to save the passwords in a file or some
other object.

I gathered that from the sort of things that have been added to QPWDRULES. It mostly makes my own, 13 year-old, exit program unnecessary.


Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.