Oracle 12c STIG Password Generator in PL/SQL

Creating or modifying an Oracle Database user password can be done by using any standard password generator you can find on the WEB. But I wanted a password to comply to “ora12c_strong_verify_function”, and this isn’t as easy to generate as you might expect. Though most generators provide options to include or exclude certain character groups, I wasn’t able to find one that will let you choose options in any detail and also let you set specific requirements.
So I took up the idea to code a PL/SQL based password generator that is as flexible as possible in the choice of included or excluded characters and can be configured to comply to Oracle requirements.
This is what the Oracle 12c documentation states in respect to the “ora12c_strong_verify_function”:

The ora12c_strong_verify_function provides a set of requirements that are recommended by the Department of Defense Database Security Technical Implementation Guide. This function checks for the following requirements when users create or modify passwords:
1. The password must contain at least two upper case characters, two lower case characters, two numeric characters, and two special characters. Specials are: ‘ ~ ! @ # $ % ^ & * ( ) _ – + = { } [ ] \ / < > , . ; ? ‘ : | (space)
2. The password must differ from the previous password by at least four characters.

The following internal checks are also applied:
3. The password contains no fewer than 9 characters and does not exceed 30 characters.
4. The password does not contain the double-quotation character (“). It can be surrounded by double-quotation marks, however.

What kind of Oracle password:
I’m familiar with the fact that Oracle passwords can be max 30 characters long, must
start with an uppercase or lowercase letter and – with numbers and letters – may contain only
3 special characters: # $ _
But what I discovered after some investigation and didn’t know yet, is that the restriction on start
and special characters is off when you encase the password in double quotes. This kind of Oracle
password now seems better practice to me because of the extra complexity, but I would still like
to avoid some tricky characters for easier command line or shell script password management:
` ‘ ^ @ ” (space)

About exclusion (or inclusion) of characters:
For easy configuration I decided to use a regular table with the first 127 ascii codes and their
respective characters. Some extra – true (1) or false (0) – colums serve as profiles for [ex|in]clusion
of specific characters.
I reckoned a random number generator, configured to produce an integer between 0 and 127, should be
able to produce – in combination with Oracle supplied function CHR – any character in the ascii table.
And If it happens to generate an excluded ascii code, well, I simply let the PL/SQL try again until
the generator hits an included ascii code.

How about password verification:
To address some specific STIG requirements like a minimum number of specific characters, as before, my
coding strategy is to apply a brute force tactic. The algorithm keeps on generating passwords until
one finally fulfills all requirements. This method of “retry until OK” could be time consuming.
Well, it isn’t… check this out:

Passwords generated with ORA_STIG01 profile may contain all characters with ascii code 32 to and including 126.
The only exclusion is the double-quoted mark with ascii code 34: ”
Default length: 14 characters

Passwords generated with ORA_STIG02 profile are like passwords generated with ORA_STIG01 profile, but with
five extra exclusions on top of the double-quoted mark: ` ‘ ^ @ (space)
Default length: 14 characters

ORA_DEF profile is meant for passwords without enclosed double quotes, and without any verification function.
Only numeric characters, uppercase and lowercase letters and 3 special characters are allowed: # $ _
In addition the password must start with an uppercase or lowercase letter.
Default length: 14 characters

Before installing the following code in some schema, connect with sys first and grant this schema owner execute on sys.ora12c_strong_verify_function… use the code at your discretion: