Dual control using UAF features

[Hoff]

With that three-week schedule cited earlier, you're getting a little short on time to get this stuff designed and reviewed and developed and debugged and deployed.

You could use the referenced $acmw code to implement two one-person logins using two calls into the posted code, or could implement a two-password login using a variation of that $acmw code; the two-password login mentioned earlier. This latter case if you need have neither user individually with the extra access that username grants. These two could each comprise your option one. And they get your code (mostly) out of the loop; you're using OpenVMS authentication and rather less of your code.

Either of these solutions (depending on how it is implemented) might not be completely secure, but less code and simpler code is generally better code when security is involved.

Certainly get the auditors and your management looking at and approving the design, whatever you choose to implement here.

I personally won't try to get an approach based on DCL and SPAWN and such past the auditors. Not with credit card data.

[John McL]

Bill, just a thought ...

If you, or more importantly the auditors, are satisfied with the security of individual user logins then maybe you can devise an app password system that can be transmitted in an SSH command in plaintext.

You could use single-use passwords where seeing one or even a few of them provides no useful information to break into the system. The sender and receiver just have to agree on what's in the transmission. Typically you'll have a long sequence of agreed passwords and when one password is used, both step to the next one password in the sequence. Naturally the sending of a password will be outside manual control.

Maybe have an encryption key at both ends that gets XOR'ed with the one-time password and make sure you regularly change that XOR key. You could even get right into how ATM machines make connections to their hosts (which I vaguely recall is 128 bit use of the system prior to DES).

I see an issue if you are using SYSUAF to verify the password at the receiving end but maybe for this particular application you either have no VMS passord and handle it yourself or you introduce a new VMS password algorithm on your system that for the application account does its own handling but passes all other usernames to the normal password algorithm.

As I said, just a thought ... better to have too many options than not enough.