Operating System - OpenVMS
1753676 Members
5424 Online
108799 Solutions
New Discussion юеВ

Re: Password Policy module

 
SOLVED
Go to solution
Richard W Hunt
Valued Contributor

Password Policy module

I have searched the forums but I have not seen an answer that helps. I know what I want to do but I'm having trouble with the system-provided example that would let me do it.

I am at a USA Dept. of Defense site. We are running OpenVMS/ALPHA 7.3-2, patched pretty well. ADA compiler is (at the moment) version 3.5-20 - but I could probably upgrade that if I searched the SPL hard enough. I do have issues with upgrading, though, because of system configuration management folks who hate change. OK, here's the specifics:

I am trying to implement a password filter that will require at least one each of uppercase, lowercase, digits, and punctuation, with other password issues such as minimum length, history, and dictionary matches to be handled outside of my filter.

I don't have a BLISS compiler and the only other example available is ADA. I DO have an ADA compiler. So I modified the SYS$EXAMPLES version of VMS$PASSWORD_POLICY.ADA and have a clean compile and link. I installed it according to the instructions. Didn't work. So I tossed in some TEXT_IO calls to show where it went nuts. I can see that my policy routine has been called and that it is about to reference the first input parameter.

The part that fails is that I cannot seem to pick up the external parameters. I wanted to import the USERNAME and PASSWORD parameters which are defined as "STRING" in the package definition.

excerpt:

procedure POLICY_PLAINTEXT (STATUS : out CONDITION_HANDLING.COND_VALUE_TYPE; PASSWORD : in STRING; USERNAME : in STRING ) ;

end excerpt;

There is also the pragma, which uses "STRING" as the types for the exported parameters.

OK, what happens is this: My module gets called and I see the TEXT_IO.PUT_LINE operation before it attempts this line:

TEXT_IO.PUT_LINE( USERNAME ) ;

(USERNAME is one of the input parameters.)

That line files with error message:

%SYSTEM-F-HPARITH, high performance arithmetic trap, etc. etc.
-SYSTEM-F-INTOVF, arithmetic trap, integer overflow at etc.etc.etc.

OK, so the question is: Why can't I access the input string? Has the password policy interface changed that much since the SYS$EXAMPLES copy was created?
Sr. Systems Janitor
21 REPLIES 21
Robert Gezelter
Honored Contributor

Re: Password Policy module

Richard,

I do not believe that the interface has changed in a very long time. Recently, I took a look at a variant of the DECUS Password Policy being used at an end-user site.

That FORTRAN code is available on the www, although it did take a little work to find it. I will admit that I have not compared the FORTRAN to the ADA example.

Another question would be have you put the routine inside a jacket(simulated LOGINOUT) code and invoked the DEBUGGER to see what is actually happening?

I hope that the above is helpful. If you want to speak privately, I can be reached privately.

- Bob Gezelter, http://www.rlgsc.com
Richard W Hunt
Valued Contributor

Re: Password Policy module

Actually, I don't need to jacket it that badly.

The PASSWORD_POLICY module is not involved in login, only in changing passwords. If your password does not have to be changed, it doesn't get called. So there is a way to protect yourself and still turn the feature on and off.

So what I do on my test system is recompile and relink, then go through the steps of setting the /SYSTEM/EXEC logical and putting the new .EXE in SYS$LIBRARY: and running SYSGEN to set the LOAD_PWD_POLICY flag. Then I reset the test account's password and set its PWDMIX flag.

Nobody else is on that test system, so I just get two sessions running. Do a SET HOST 0 to open a new session, login with the new password, and do a SET PASS in the shelled session. The TEXT_IO.PUT works and I can see the output (among other stuff). When I'm done, I reset the LOAD_PWD_POLICY flag to not attempt the callback.

One of the things I tried was the ADA thing to determine the size of the parameters. The constructs I have tried are

PSZ := PASSWORD'LENGTH ;
and
PSZ := PASSWORD'LAST ;

Neither one was pretty. They seemed to be humongous numbers. Such a huge number that I begin to doubt that "STRING" is the correct format. If the input is an ASCIC type of string, I could compensate. I know what that format is. But I can't even copy the routine's parameter to a local variable.

I.e.

LOCALPASSWORD := PASSWORD;

doesn't work either. If that fails, I'll never be able to do the operation. I'll see if I can find something on the web about a FORTRAN version. I used to do FORTRAN about 30 years ago.
Sr. Systems Janitor
Robert Gezelter
Honored Contributor

Re: Password Policy module

Richard,

My recollection (which I can refresh later today, the machine with the code is not where I am at the moment) is that it was most likely passed by Descriptor.

- Bob Gezelter, http://www.rlgsc.com
Richard W Hunt
Valued Contributor

Re: Password Policy module

I guess I can try to figure out how to force Ada to treat it as a descriptor passage, and that would make sense given what I've seen.

Of course, ADA tries to hide things, but I guess I'm just concerned that the documented module in SYS$EXAMPLES wouldn't work if you ran it.

BTW, I found a FREEWARE site that showed the FORTRAN version of the password policy module, but it didn't help. It just called the parameter data type "CHAR *" - which, if I recall correctly, is an ambiguous length string. Or does that imply a particular passage mechanism that I've forgotten? Like ASCIZ or ASCIC ?
Sr. Systems Janitor
Robert Gezelter
Honored Contributor

Re: Password Policy module

Richard,

I would check the FORTRAN manuals (available via the documentation section at http://www.hp.com/go/openvms ). My recollection is that CHARACTER*(*) is a dynamic string, and the LEN function is used to get the actual length (see the FORTRAN Language Reference Manual).

- Bob Gezelter, http://www.rlgsc.com
Jon Pinkley
Honored Contributor

Re: Password Policy module

RE: "I don't have a BLISS compiler". BLISS is available on the freeware disk or as a download from HP http://h71000.www7.hp.com/freeware/freeware80/bliss/.

However, "I do have issues with upgrading, though, because of system configuration management folks who hate change." may affect your ability to install that.

The lack of a BLISS compiler shouldn't keep you from using BLISS if that would be your choice of language. BLISS is a good language once you get accustomed to the way variables are referenced, but if you are unfamiliar with it, you may be better off using either ADA or FORTRAN.
it depends
Jon Pinkley
Honored Contributor

Re: Password Policy module

Richard,

Are you saying that the unmodified version of VMS$PASSWORD_POLICY.ADA does not work? I don't have an ADA compiler so I can't test.

Was this the FORTRAM version you referred to?

http://h71000.www7.hp.com/freeware/freeware40/password_policy/vms$password_policy.for
it depends
John Gillings
Honored Contributor

Re: Password Policy module

Richard,

You also have a MACRO32 compiler! Here's an example module that counts different character types in the proposed password, making it easy to modify it to suit your particular policy:

.TITLE VMS$PASSWORD_POLICY
;
; Sample site password policy module
;
; Analyzes plaintext password, counting character types.
; Resultant variables:
;
; CountSpecial, CountUpper, CountLower, CountNumeric
;
; countain counts of each type of character.
;
; PresSpecial, PresUpper, CountPres, CountPres
;
; are presence flags, 0 if there are none of that type
; of character in the string, 1 if there are.
;
; There are also counts and flags for Control characters and
; Invalid characters. These should not occur as the normal
; OpenVMS filtering should reject them before this module
; is invoked.
;
; Results can be used to test password against a complexity
; policy. In this example, there is commented code which
; checks that one of each type of character is presence. The
; working path checks that at least 3 of the 4 possible types
; are present.
;
; Author: John Gillings
;
; Usage:
;
; $ MACRO VMS$PASSWORD_POLICY
; $ LINK/SHAREABLE/SYSEXE VMS$PASSWORD_POLICY+SYS$INPUT:/OPTIONS
;SYMBOL_VECTOR = ( -
;POLICY_PLAINTEXT=PROCEDURE,-
;POLICY_HASH=PROCEDURE)
;
; $ COPY VMS$PASSWORD_POLICY.EXE SYS$COMMON:[SYSLIB]/PROT=(W:RE)
; $ INSTALL ADD SYS$LIBRARY:VMS$PASSWORD_POLICY/OPEN/HEAD/SHARE
; $ MCR SYSGEN
;SYSGEN> USE ACTIVE
;SYSGEN> SET LOAD_PWD_POLICY 1
;SYSGEN> WRITE ACTIVE
;
; Note - it's recommended that the CURRENT parameter for LOAD_PWD_POLICY
; be 0. The USE ACTIVE, SET, WRITE ACTIVE sequence should be included in
; the startup procedure after INSTALL ADD is confirmed to have worked.
; Leaving it all to happen automatically may disable changing passwords
; altogether.
;

$SSDEF

.PSECT $RWDATA,RD,WRT,NOEXE
CountTab:.LONG ; Counter table, will get counts of each character type
CountControl: .LONG
CountSpecial: .LONG
CountNumeric: .LONG
CountUpper: .LONG
CountLower: .LONG
CountInvalid: .LONG
PresTab:.LONG ; presence table, will get flags set to 1 if present
PresControl: .LONG
PresSpecial: .LONG
PresNumeric: .LONG
PresUpper: .LONG
PresLower: .LONG
PresInvalid: .LONG

.PSECT $RODATA,RD,NOWRT,NOEXE
CharTab: ; ASCII table, defines character types
; I'm fairly sure this is correct, but please
; check before deployment.
; 1 = Control
; 2 = Special
; 3 = Numeric
; 4 = Uppercase
; 5 = Lowercase
; 6 = Invalid
.BYTE 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 ; 1-15
.BYTE 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 ; 16-31
.BYTE 1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 ; 32-47
.BYTE 3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2 ; 42-63
.BYTE 2,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4 ; 64-79
.BYTE 4,4,4,4,4,4,4,4,4,4,4,3,3,3,3,3 ; 80-95
.BYTE 3,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5 ; 96-111
.BYTE 5,5,5,5,5,5,5,5,5,5,5,3,3,3,3,6 ; 112-127
.BYTE 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6 ; 128-255 invalid
.BYTE 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
.BYTE 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
.BYTE 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
.BYTE 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
.BYTE 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
.BYTE 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
.BYTE 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6

; Message to output if password string fails policy check
badpwd: .ASCID -
/%SYSTEM-F-PWDPOLICY, Password does not conform to security policy/

.PSECT $CODE,RD,EXE,NOWRT

.ENTRY POLICY_HASH,^M<> ; no need to mess with the hash value
MOVL #SS$_NORMAL,R0 ; always success
RET

.ENTRY POLICY_PLAINTEXT,^M
MOVAQ @4(AP),R3 ; Get address of descriptor for plaintext password
MOVZWL (R3),R7 ; Get password length
MOVL 4(R3),R8 ; Get pointer to start of string

;
; Clear character type counters and presence flags
CLRL CountControl
CLRL CountSpecial
CLRL CountNumeric
CLRL CountUpper
CLRL CountLower
CLRL CountInvalid

CLRL PresControl
CLRL PresSpecial
CLRL PresNumeric
CLRL PresUpper
CLRL PresLower
CLRL PresInvalid

; Now step through the password counting character types

nloop: MOVZBL (R8)+,R4 ; Get next character
MOVB CharTab[R4],R4 ; Get character type
INCL CountTab[R4] ; Increment type counter
MOVL #1,PresTab[R4] ; Set presence flag
SOBGTR R7,nloop ; countdown loop

; TSTL CountSpecial
; BEQL bad
; TSTL CountNumeric
; BEQL bad
; TSTL CountUpper
; BEQL bad
; TSTL CountLower
; BEQL bad

MOVL PresSpecial,R4 ; take sum of presence flags
ADDL PresNumeric,R4
ADDL PresUpper,R4
ADDL PresLower,R4
CMPL R4,#3 ; Require at least 3 different types
BLSS bad

ok: MOVL #SS$_NORMAL,R0 ; return OK
RET

bad: PUSHAB badpwd ; issue message
CALLS #1,G^LIB$PUT_OUTPUT
MOVL #SS$_PWDWEAK,R0 ; return "password weak"
RET

.END
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: Password Policy module

Sorry, formatting all messed up. Here's the same file as a .TXT attachment
A crucible of informative mistakes