Password Policy module

[Richard W Hunt]

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?

[Robert Gezelter]

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]

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.

[Robert Gezelter]

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]

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 ?

[Robert Gezelter]

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]

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.

[Jon Pinkley]

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

[John Gillings]

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

[John Gillings]

Sorry, formatting all messed up. Here's the same file as a .TXT attachment

[Richard W Hunt]

First, having a freeware BLISS compiler helps not at all. I cannot "legally" install anything I haven't declared for my machine. I can't upgrade versions of anything without permission. DoD is kind of paranoid right now.

I literally need permission to patch the system when patches are available. (OK, I get THAT permission easily, but there IS a chain of command even for a security patch.) I got gigged for failing to note that we had a legal copy of "PKZIP for OpenVMS/Alpha" on one of our machines. So suggestions to install BLISS32 won't help. But maybe I'll look at the code.

Second, thanks for the MACRO code. I'll look at it, but won't be able to use it outright. I'm doing two other tests - a minimum password age and a specific type of sanity check that our security types said I should implement. NONE of the tests are worth a darn if I can't even make a local copy of the password and username.

I'm using the login flag UAI$M_PWDMIX to signal whether this rule applies. Only folks who have the ability to set their own passwords will need this facility. (We have some who are so bound up tightly in shells that they cannot set their own passwords.)

Of course, the problem is that if I can't see the username, I'll never be able to do the implied GETUAI call. So I guess I'm just wondering whether the parameters are DESCRIPTOR, ASCIC, ASCIZ, or something else. Because as it goes right now, I'm not seeing the input parameters.

[Richard W Hunt]

As to the FORTRAN version, I believe it was the Freeware 40 disk, so that link might have been correct. I looked at the file and later downloaded a new FORTRAN manual so I could check the implied syntax of CHAR *(*) as a passage mechanism. Haven't gotten around to that yet because of other excrement impacting the rotating atmospheric destratification appliance. (Egad, I've been working with the government too long when I start using THAT kind of language...)

I think my next test is to restore the version from SYS$EXAMPLES and complile and link it according to stated procedures (as noted in the file itself). Then try to run it. Odds are it won't work because the things I'm doing early in the module exactly track the contents of the SYS$EXAMPLES version - like doing TEXT_IO.PUT( "Password = " ); followed by TEXT_IO.PUT_LINE( PASSWORD );

I see "Password = " but then it crashes the task. Literally, i.e. stack and register dump. Ugly.

[Volker Halle]

Richard,

when you get a stack dump (improperly handled condition), then it's easy:

$ SET PROC/DUMP

run the failing image

$ ANAL/PROC imagename.DMP

Then you're in the debugger and you can look - statically - at all the variables and memory contents. Should be easy to figure out, WHY the image crashed.

DBG> EXA/INS @PC

Volker.

[John Gillings]

>So I guess I'm just wondering whether the
>parameters are DESCRIPTOR, ASCIC, ASCIZ,
>or something else

Richard, the username and plain text password are passed by descriptor. You can expect them to be CLASS S, DTYPE T with a word length field.

Since you can't DEBUG your routine in situ (privileged image), you should make sure it works in a test harness. Call your routine from a program which just passes 2 stings by descriptor, run under DEBUG and check you can see pointers to the descriptors in R16 and R17 once inside your routine. You should see something like the following. Look for the "010E" descriptor class and type, then check the text with examine/ASCII (note: radix is set to hex).

DBG> ex/hex/quad @r16,@r17
0000000000020050: 00020058010E0009
0000000000020040: 00020048010E0008

DBG> ex/ascii:9 00020058
0000000000020058: 'PLAINTEXT'
DBG> ex/ascii:8 00020048
0000000000020048: 'TESTUSER'

Given that your error is HPARITH, I suspect it's something other than a problem with the arguments. If it were the arguments, I'd be expecting an ACCVIO of some sort.

Dumb question... does TEXT_IO.PUT_LINE handle descriptors correctly? (I thought that Ada wouldn't compile if it wasn't correct, but I'm not certain).

Here's a very simple test harness. It would be better to have one that prompted for username and password in a loop so once you get over this initial problem, you can debug the policy part easily without changing any real passwords!

.title test_password_policy
.psect data,rd,wrt,noexe
user: .ASCID /TESTUSER/
pass: .ASCID /PLAINTEXT/
.psect code,rd,nowrt,exe
.entry start,^M<>
PUSHAB user
PUSHAB pass
CALLS #2,G^POLICY_PLAINTEXT
RET
.END start

[Richard W Hunt]

OK, did the SET PROC/DUMP, ran a password change, examined /INST @PC

It is telling me it died on MACRO instruction

LDQ R24, #X0098(FP)

which it reports as being part of program line 221. Program line 221 is

TEXT_IO.PUT_LINE( USERNAME ) ;

in the sequence at the start of the code...

begin

RESTS := STARLET.SS_NORMAL
TEXT_IO.PUT_LINE( "PASSWORD POLICY" ) ;
TEXT_IO.PUT_LINE ("Called with:" ) ;
TEXT_IO.PUT( "USERNAME = " ) ;
TEXT_IO.PUT_LINE( USERNAME ) ;
TEXT_IO.PUT( "PASSWORD = " ) ;
TEXT_IO.PUT_LINE( PASSWORD ) ;
...
The rest of the filter starts actually picking apart the username and passwordd, but the above is very close to the sample code in SYS$EXAMPLES.

When I do a SHOW SYMBOL/FULL USERNAME, it tells me (for this particular entry point),

data PASSWORD_POLICY.PASSWORD_PLAINTEXT.USERNAME
Address: .(.%FP+152)
array descriptor type, 1 dimension, bounds: [136308:136308]
cell type: atomic type, character-coded text, size: 1 byte.

If I look at PASSWORD, it has a different address (%FP+160), different bounds, but the same description including size 1 byte.

The password I entered for the situation that got dumped was 12 bytes long. I have not yet tried other cases but it is interesting that if I examine PASSWORD, it is hex 0C, which is correct if that is an ASCIC string.

[John Gillings]

(aside... for after you've got this working)
I just checked the SYS$EXAMPLES source and found this comment:

--
-- Please consult the "VMS System Generation Utility Manual" for further
-- information on using the SYSGEN utility. You might also want to add the
-- following line to SYS$SYSTEM:MODPARAMS.DAT:
--
-- LOAD_PWD_POLICY = 1 ! enable site-specific password filters
--

I strongly recommend you do NOT set LOAD_PWD_POLICY as a CURRENT SYSGEN parameter. If it's set and your startup fails to install the password policy module for any reason, you can't set passwords at all! I always recommend you leave LOAD_PWD_POLICY to 0 in MODPARAMS, and put the SYSGEN commands to set it in line with the code that installs the module, only to be executed if the INSTALL is successful.

(Similar advice for LGI_CALLOUTS, but if that module fails to load with the parameter set, your system is unbootable with no obvious cause!)

[Richard W Hunt]

John, I have a couple of tiny scripts that do the steps on the fly to set or clear the LOAD_PWD_POLICY flag, define or deassign the system logical name, and INSTALL ADD or INSTALL REMOVE the image in question.

I keep one session open on my test system, do the install, switch sessions, do the test, switch back, remove the code, and tear my hair out. I'm pretty careful about not leaving the system with that little booger active when I'm not around.

[John Gillings]

Richard,

Looks like we clashed with my prior posting about debugging, which you may have missed.

Don't debug/test it with the image installed, use a test harness. There's nothing magic about the routine, it's just an ordinary piece of code that accepts two strings, does some processing and returns a result. You can (and IMHO *should*) do debugging and testing isolated from the real system.

Once you're convinced it's working, THEN install it and check it out for real.

This will be MUCH easier and safer to do all debugging and testing from a test harness.

[Richard W Hunt]

Built the shell (in BASIC), called the policy plaintext module from it with a valid username and a password that would have failed the complexity test. The username is one for whom the PWDMIX login flag is set. (That's my marker for eligibility.)

When I attempt to pick up the username I get a CONSTRAINT ERROR.

When I examine the registers for R16, R17, etc. I see

%R16: 000000001031B54A
%R17: 000000007AE38160
%R18: 000000001031B54A
%R19: 000000000000000C

I do not see the expected descriptor headers in the registers, because either the address part is zero or this is a descriptor type I've not seen before.

In the BASIC shell, my setup for the call to the ADA module looks like:

EXTERNAL SUB POLICY_PLAINTEXT(
LONG BY VALUE,
STRING BY DESC,
STRING BY DESC )

In ADA, my setup for the external linkage looks like:

pragma EXPORT_VALUED_PROCEDURE(
INTERNAL => POLICY_PLAINTEXT,
EXTERNAL => POLICY_PLAINTEXT,
PARAMETER_TYPES -> (
CONDITION_HANDLING.COND_VALUE_TYPE,
STRING,STRING),
MECHANISM => (VALUE, DESCRIPTOR(S),DESCRIPTOR(S) ) ) ;

When I examine the stack, I never see anything that looks like the type-S descriptor I would have expected to see.

I'm confused. I'm also about to try to write this puppy in BASIC just to break the logjam. NAHC. (Not A Happy Camper.)

Anyone have any ideas?

[Richard W Hunt]

Throwing in another tidbit:

Adding a line:

K := PASSWORD'LAST ;
or
K := PASSWORD'LENGTH ;

both now fail with %BAS-F-MEMMANVIO, which is followed by SYSTEM-F-ACCVIO point to reason mask 00 and VA = lotsa zeroes.

It points to the K := PASSWORD'LAST ;

When I trace back the stack it looks like the run-time library code has passed through SHARE$ADARTL (which is the module called out in the debugger break message),
SHARE$LIBOTS_CODE0,
something with a VERY long address but no name,
SHARE$LIBRTL_CODE0, SHARE$DEC$BASRTL,
another lengthy address with no name,
and finally at frame 6, my POLICY_PLAINTEXT routine.

The total number of invocation blocks is 22, including several null frames.

So my interpretation is that the two modules (shell and policy module) are trying to ask each other about something but miscommunicating. I don't understand quite HOW they are doing so, but they are.

If I do SHOW SYMBOL/FULL on USERNAME in the plaintext module, it now says it is a dynamic string descriptor type, which I might have expected. When I attempt to examine the contents of USERNAME in the context of the module, it says 'invalid array descriptor'

Have I reached the level of calling HP for software support yet?

[John Gillings · Accepted solution]

Richard,
A few more hints...

>When I examine the registers for R16, R17, etc. I see
>
>%R16: 000000001031B54A
>%R17: 000000007AE38160
>%R18: 000000001031B54A
>%R19: 000000000000000C

You should be looking at @R16 and @R17. The register contains the address of the descriptor.

The interface for the routine should be two strings passed by descriptor. The condition value is returned as a function value. So, in BASIC it should be declared as an external (INTEGER) function with two string arguments. I think ADA defines the function return value as an initial argument. Maybe that's the source of confusion here?

Try calling my MACRO32 version from your test harness.

(get the routine interfaces defined correctly and most other problems will sort themselves out! make sure the arguments agree in number, position, type and mechanism).

[Richard W Hunt]

The problem was resolved by rewriting this thing in BASIC. I still don't know why the ADA version barfed, but the BASIC version worked first try. Has to be the argument passing mechanism in or out of the exported valued routine.

My thanks to all who tried to assist me on this nasty little problem. Before I close the thread, I will see if it is possible to post the code that finally worked. However, since this is a government site, posting code is sometimes frowned upon.