Dual control using UAF features

[Bill Hallman]

We have an application in which users login to a single account, and identify themselves with an app based user database requiring two users to be validated. External auditors have demanded changes that must be made to keep us certified. They require 1. PWDMIX style passwords 2. Separate users for tracking and 3. encrypted passwords (the current app does not encrypt)

I would like to use HASH_PASSWORD with a salt value to query the UAF from a program for a different user, however the docs say the password must be upcaesd and have the limited special characters (i.e. not PWDMIX compliant)

So, is there an undocumemted (or documented but missed by me) way to provide that with HASH_PASSWORD? Or is there a better way to verify different users password from an unprivileged account?

I have done a fair amount of looking in this forum and found some good responses, but so far they don't apply. E.g. the Auditors have required us to turn off DECnet, so opening a file to host 0 won't work. (all net traffic is via SSH2 compliant protocols)

I am trying to find the best solution to do dual control, and I would like to use the UAF password features, but the app MUST run from a single login. I also have about 3 weeks to implement. Help would be appreciated.

[Brad McCusker]

Bill,

First, what version VMS?

Next, can you explain this a little bit more:

>identify themselves with an app based user
>database requiring two users to be
>validated.

particularly the "requiring two users to be validated part"? Are you saying that to get to the application, two users need to validate themselves? And what you want to do is modify that "two users ... validate" part so that it's using UAF instead of its own database?

Brad McCusker
Software Concepts International
www.sciinc.com

[Hoff]

The fundamental design looks to be broken.

You'll be using $acme here, presuming you're on a version of OpenVMS that has that.

$hash_password hashes passwords. It doesn't access the SYSUAF data.

Otherwise, you're re-implementing loginout in your code, including the password processing and evasion and related. You'll be using $getuai as a start. And you'll be writing a privileged image, which means your code is a target for attacks.

If you want to open some security holes, the simplest approach is to use $hash_password, use $getuai, and compare.

Here's a policy filter:

http://labs.hoffmanlabs.com/node/643

Or connect out into LDAP, if you have that.

But I'd look to go to per-user usernames; to use system security. This is what you're fundamentally bypassing with this whole shared login design. (If I'm interpreting your posting correctly.)

Three weeks and auditors underfoot? If the auditors have a clue about security, you're going to need to get help to get this done on that schedule without breaking open security. I know how to do this stuff, and that's a tight schedule.

[Bill Hallman]

Dang, you guys are quick!
Brad
VMS 8.3-H1 (brand new to us)
Currently we have a small file with usernames, passwords and app privs that the users validate with (i.e. the app prompts for user and pw and checks in the file, requiring two users per run). The file is not encrypted. I thought about just encrypting the data, but hoped I could get some of the UAF features (like DB maintence, expiration, etc.) by using hash_password, and I thought the 'salt' value retrieved with getuai would do that.
So the answer to your question is yes.

Hoff
I have already looked at your pw filter and plan on using that as a template to do our own enforcing ow policy, and many thanks for that.

I looked at $ACME, and became afraid. I am no great hand at system services, though I have used them. I see that using GETUAI will require privs, which is not likely to be approved, tho maybe installing the prgm would be. There would be no updates in the installed code, only programs could use it for nefarious purposes (me).

Without privs, it seems like my best bet would be to use hashing to encrypt the password, IF hash_password will accept mixed case/special characters, which the documentation says it will not.

My next best solution would be to use getjpi to ensure that another valid user was logged in before running. That would be a temp solution, but might get us past the auditors this time around. All advise is very welcome.

Thanks.

[Hoff]

If you're going to connect into OpenVMS security after the login... There are two ways into SYSUAF and related sensitive information: via privileges, and via subsystem identifier (and some local identifier and ACL work). Both of these require equally cautious programming. Third-party authentication against OpenVMS inherently requires access to trusted information; you're inside the security perimeter with this stuff.

If you want to do your own authentication in parallel to SYSUAF (and not tie into OpenVMS), then you'll have to decide what's required for access and such; you won't be using system services. And if you're rolling your own, there's little point in any services. You don't need hash password; you can use most any digital signature or digest for that, and I'd probably use SHA-2 or better. (Look in the OpenVMS crypto library for this stuff.) But even for this, you need a security perimeter to control access to your data; that's usually (again) based on identifiers or privileges.

As for hashing, I wouldn't hold the Purdy Polynomial that's used by OpenVMS in particularly high regard; there are newer approaches and (if you're rolling your own) you can use something newer. If your data is sufficiently sensitive, tossing a couple of GPUs worth of computes at the hashes is no problem.

http://labs.hoffmanlabs.com/node/647

And as for generic accounts:

http://labs.hoffmanlabs.com/node/607

The salt stuff is intended to avoid rainbow tables and similar. It means you can't pre-calculate hashes. But there's a dirty little secret here: if folks have your encrypted hash values, there are much better and bigger breaches available. The salt doesn't matter. You're already toast. As for tools for attacks, those are widely available:

http://labs.hoffmanlabs.com/node/229

My suggestion? Don't. Use VMS security. Use the per-user logins and such and not what seem to be generic logins. Or $acme, if you're tying into VMS. Or use Kerberos and LDAP, if you have that (Open Directory or AD or such) around and want to run parallel authentication. All of these approaches get the auditors aimed at HP or others, and less at your code. Don't roll your own security code if you can avoid it. Use what's already available, and use it as it is intended. (When I'm doing security-related work, I will specifically look for local privileged code; it tends to be a ripe source of vulnerabilities.)

And get help. Three weeks is aggressive for design and review and implementation and test and review, and I'm sure you don't want short-cuts here.

[John Gillings]

Bill,

I agree with Hoff, this seems like a broken security model. But rather than try to teach an auditors about reality (not worth the effort), perhaps there's aa quick and dirty approach...

Use the UAF to define your "separate users". Thus for your user BILL you'll have username BILL (which they login to) and another username BILL_AUTH. Setup BILL_AUTH so it's captive. If you login to BILL_AUTH interactively, the only thing you can do is change the password. If you get a network login, all it does is echos an input string, and logs out.

From your application, to authenticate, send an SSH request to the local node, username BILL_AUTH and the password the user has entered. If you see your authentication string echoed, you know the user has authenticated. Generate a random string each time. You can authenticate any username using the same mechanism.

So you've satisfied the audit request, you have a simple mechanism for users to change their secondary password, and a simple, non-privileged way to authenticate any user from inside your application. Since you're using SSH, there are no clear text passwords on the wire (however, there IS the issue of the application knowing the clear text, but you'd have that whatever you do...). Assuming it works from SSH, you also get intrusion detection and auditing for free.

[Robert Gezelter]

Bill,

I concur with Hoff, use extreme caution here. Security-related code is extremely sensitive to small flaws.

That said, home-grown security solutions tend to have a high probability of problems. Additionally, many audit checklists are concerned with the externally visible components, not the actual mechanisms. This is a severe shortcoming. I have seen many applications that "enforce" security, only to find that unencrypted (or weakly encrypted) passwords are stored in an easily accessible database.

There are a variety of ways to address this problem, but I would not want to make recommendations without a more in-depth look at the details of the actual situation.

I also agree with Hoff that a good understanding of the various mechanisms is essential. Comfort with system services is only a start.

In-depth review of what is needed and what is planned is strongly suggested. It is important to satisfy current audit requirements, but any design will need to also satisfy the future audit requirements as they evolve.

Outside experience on some basis would be a conservative suggestion [Disclaimer: We provide services in this area, as does Hoff].

- Bob Gezelter, http://www.rlgsc.com
Author, "OpenVMS Security", Handbook of Information Security (2005)

[Richard J Maher]

Hi Bill,

UAF now allows you to specify, for a given user, that you want mixed-case passwords. If this flag is set then simply don't upper-case the string before checking it. Perhaps something like: -

call "mth$jiand" using uai$m_pwdmix, uai_flags giving jiand_flags.
if jiand_flags = zeros
call "str$upcase" using by descriptor acp_password, acp_password(1:password_len) giving sys_status
if sys_status not = ss$_normal
call "lib$stop" using by value sys_status.

call "sys$hash_password"
using by descriptor acp_password(1:password_len)
by value hash_alg, hash_salt
by descriptor acp_username(1:username_len)
by reference hash_pwd
giving sys_status.
if sys_status not = ss$_normal
call "lib$stop" using by value sys_status.

if hash_pwd not = uai_pwd
move "Invalid password" to reason_text
move t3$_notvalid to scan_status
perform scan_intrusion
go to deny_access.

It's certainly not rocket science but will take time especially if you want intrusion detection right. (Something the auditors should be insisting on, but *in the short term* if they don't ask they don't get :-)

So unless I've misunderstood your question(s) that should do it?

Cheers Richard Maher

PS. Your VMS version should have uai$m_pwdmix defined, but if it doesn't it's: -

uai$m_pwdmix == ^X2000000

PPS. Debate also rages about where invalid password values are logged (or kept) audit-log +/- console. The valid password entered as a username scenario being a nuisance.

PPPS. Wonder where VMS would've been with a few mor "Can do" people?

[Steve Reece_3]

There's some confusion here for me.
You say that the auditors require separate users for tracking, but also that the application must run from a single login.

If you're rolling your own security model from this, you're likely to be on a hiding to nothing. Don't even try. Piggyback off the VMS model and have done, as others have already commented.

What you might do is check that the real user has logged in successfully to an interactive session and, if it's a specific username, connect to a second shared account which then accesses the application. The second username could also perform a check that it was coming from a terminal of a specific set of usernames and, if it wasn't, terminate the session.

Either way, I wouldn't try and roll your own security and password model. It's not worth the hassle or maintenance.

Steve

[Hoff]

Here's an example of authenticating users on OpenVMS using the ACME system services and evasion:

http://labs.hoffmanlabs.com/node/1514

The code shown earlier would better use an AND operator and not a = equality test operator for the low-bit-set condition status checks; the code shown unfortunately misses all but one of the possible successful status condition codes, and that can lead to unexpected failures at run-time.

[Bill Hallman]

Wow - take a day off and inundated with some great responses. I'm still digesting; but as of now I'm moving toward a simplified approach that gives everyone a separate username and, at specific points in the process, verifies that another valid user is logged in at the time. This combined with login timeouts should get me past the auditing reqs for now.

I have some qusetions about what I've seen here:
Richard: The hash_password procedure call you showed implies that you CAN send it a mixed case pw, despite what the manual says; is that true? And Hoff, I see what you are saying about checking for successful status return, rather just ss$_normal

Steve: the application is written to run from a single session, which is why I want code to check that another valid user is present before it runs. Eventually I will have to redesign the app to be runnable from multiple sessions.

John - I like your solution if I can easily find a way to do an SSH call from the code (or maybe with $SPAWN to a DCL proc). This is essentially the DECnet solution, without DECnet, right? I have already declared to the users that I will use the presence of two valid users logged in, but I may try to change it, especially as it would not require the users have GROUP priv to hunt through logged on users.

To all, you have convinced me not to try to maintain my own passwords. I definetly want to use UAF to maintain, expire, check, etc.

Later I will redesign the app to strenghen the whole business, and may well try to get approval for outside help at that point.

Sorry I'm so late responding, but I am in Alaska, so it's not that late here (~11:30); and I've had other issues to handle this AM.

[Richard J Maher]

Hi Bill,

[Richard: The hash_password procedure call you showed implies that you CAN send it a mixed case pw, despite what the manual says; is that true? ]

Yes.

[[The code shown earlier would better use an AND operator and not a = equality test operator for the low-bit-set condition status checks; the code shown unfortunately misses all but one of the possible successful status condition codes, and that can lead to unexpected failures at run-time.]]

[And Hoff, I see what you are saying about checking for successful status return, rather just ss$_normal]

Bill which do you think would be harder to diagnose and ultimately debug?

a) Doh! This thing keeps crashing at %FAC-F-QUALIFIED_SUCCESS
b) Everything appears to be running as normal and there's nothing in the log files but the repercussions of being non-deterministic in your error-checking have resulted in who knows: -

1) RMS Key of reference not established but read ok?
2) Rounding issues but close enough?
3) Counter overflow?
4) Output truncated?
5) Contextually Could be good - Could be bad?

Now you may not give a hill of beans as to why the "success" status was qualified but the first scenario's going to be a whole lot easier to fix eg:

"If sys_status not = x and y and new-Z"

as opposed to "Dang, why is is doing that?"

Personally I use BLBx in MACRO just out of convention but I think I'm going to change. (And there's that lovely case statement in MACRO and EVALUATE COBOL etc!)

Don't forget to check out lib$match_cond as well. I never use it but who knows?

Cheers Richard Maher

[John McL]

I'm intrigued by your comment about needing to validate that two users are logged in.

Is this only a check at login or will there be repeated checks to ensure that two valid users continue to be logged on? If it's the latter the application they run might need an AST routine to be triggered if the other user logs out.

[Hein van den Heuvel]

>> and Hoff, I see what you are saying about checking for successful status return, rather just ss$_normal

Right. KISS. Just test for succes. If Macro BLBC/BLBS, Cobol has 'status-code IS FAILURE/SUCCESS, Pascal has the EVEN/ODD test. What is the implementation language?

>> moving toward a simplified approach that gives everyone a separate username and

Great. It just makes sense in general, and is more often than not an auditing requirement as well.

>> at specific points in the process, verifies that another valid user is logged in at the time.

Like John McL I do not get this. Please elaborate. At first I though there was missing NOT in the text here, but later you seem to repeat this.

IF, the requirement is to make not there is only one user in the application, THEN I would recommend a LOCK to grab before entering. That could be done in application code with a call to SYS$ENQ(W), or you could punt that effort and have RMS do the heavy lifting.

Just try to open ( DCL or in the code )a file exclusively. If you get it, then you are the only user in the cluster. If not, then report. And you can use simple tools like SHOW DEV/FILE to see who 'has' the application.

You can also use a record lock, after opening a file shared. When using a record lock you get the free option to wait for the lock to become available ( DCL: $OPEN/READ/WRITE/SHARE=WRITE + $ READ/WAIT/TIME=x. Code: RAB$V_WAT + RAB$V_TMO + RAB$B_TMO )

>> This combined with login timeouts should get me past the auditing reqs for now.


>> the application is written to run from a single session, which is why I want code to check that another valid user is present before it runs.

Again, Perhaps you mean checking that an other user is NOT present?

>> Eventually I will have to redesign the app to be runnable from multiple sessions.

Hmmm, you kinda have to go out of your way in OpenVMS to make an application NOT handle concurrency. If the lack of concurrency is due to a single resource (file?) then that's your application gateway. Use nothing additional. Just try to get it and decide according to result

Cheers,
Hein van den Heuvel

[Robert Gezelter]

Bill,

Some recent postings raised a question about how the problem is being described.

When I wrote my original answer, my understanding was that this application requires two people to concur in the operation, as is an accounting/auditing procedure similar to the rules for handling bank night drop deposits, or for that matter the "two-person" rule in various classification regimes.

Some recent posts have raised the possibility that the requirement is an exclusion (one user at a time).

My re-reading of the original post seems to reinforce my original interpretation. If this is so, then there is perhaps a way to do this, although it is a little more detailed than I would want to detail in an ITRC post. It is not simple, but it would appear to work in to implement the situation as I understand it.

If you are interested, please let me know. If my interpretation is incorrect, I do not wish to put the ITRC thread into a needless digression.

- Bob Gezelter, http://www.rlgsc.com

[Bill Hallman]

This is a dual control app; there needs to be two users present to continue, so yes Robert you answered the right question. I want to have a solution that is a callable routine that can be inserted in the app at whatever point(s) the users/auditors require to ensure dual control.

The app now runs from a single executable, and thus cannot be run from multiple sessions, which is what I meant when I said I may later redesign to run from multiple sessions.

I am narrowed down to two options. I have written a DCL routine that can be called with $SPAWN to run F$PID to look at current processes (it will need GROUP priv) to ensure another valid user is logged on. One weakness of this is that being logged on does not necessarily mean presence, but since the operating environment (dual control to the room, etc.) helps ensure duality it shoud be OK.

Another option is to do an SSH connect to the local node using a username and password entered into the program. This ensures presence (the user has to be at the keyboard at the time) but is also requires the VMS password be entered into the program, which auditing may grump about. Also, I'm not sure how to do an in-program SSH call, at least quickly. If we decide to go that way, I could put it into $SPAWNed DCL instead of the PID search.

I expect some flak from this group about using DCL, but it at least it is quick and better than what we've got now, and hopefully even if the auditors write it up, theu won't decertify us, which they threaten to do with our current setup. All of this has to be implemented quickly, along with PWDMIX enforcement and all the other stuff I have to do. Anyone else have the problem of additional auding requirements (at least in my industry, credit card processing) and additional burden w/o additional resources?

[Hoff]

Flip this around and see if y'all want to be holding the bag when your servers are attacked. VMS hasn't been very well tested against attacks, and I'm cautious around its security given DEFCON and related.

As for DCL, the implementation language is immaterial. It's the implementation and the security that matters; focus on the goals.

I would look to use the lock manager to cause just a single copy of the application to be running at any one time, and would likely use the ACME call and likely a two-password user login for the requisite security.

As for mandates and such, that's the modern era. And given what I've seen of recent targeted attacks (and having gotten caught up in two separate and successful credit card breaches), these auditors are uncharacteristically mellow about this stuff.

[Robert Gezelter]

Bill,

I would rather take a discussion of the particulars of this issue offline.

Eliminating DECnet off-node traffic in this environment is understandable. Within a node, SSH2 is not encrypted either (it is encrypted when it is within TCP; not before). This may be a case of "Checklist" compliance enforcement. However, that is another question.

The problem is the enforcement of the proverbial "two-person" rule for certain actions. This is the cash counting rule, and in a more dramatic context, the well-used "two man launch authorization rule". Checking that a second process is logged in might pass audit this time, but I would not want to place bets on it.

As I said, I see a way that you could go in this direction, and be fully supported, but it requires more than a discussion on ITRC.

I will be happy to speak with you offline.

- Bob Gezelter, http://www.rlgsc.com

[Richard J Maher]

Hey, hold on a minute there Tom Cruise! Stop trying to cut Bill out from the bait-ball and isolate hime from his traditional support networks. I know the phrase "credit card company" must be flashing *deep-pockets* up on everyone's screen and times are tough, but if we can all mange to conduct ourselves with a modicum of decorum then I'm sure ITRC will be a much nicer place.

Wow, this must be what Bootcamp is like? "He'll never make the coffee urn!" "I got the toilets covered" :-)

Dang, I don't have anything useful to say, again :-) Hold-on here it is, I believe LMF uses user-mode locks for concurrent-use license checks; that could be a good start for your "How many users" check?

Cheers Richard Maher

PS. Hey Hein, how 'bout that ludicrous piece of over-engineering that is the VMS Message Facility eh? I mean why Microsoft copied it almost verbatim is beyond me. If only they had've talked to you and others here and we could have done away with that whole facility, number ,severity, and flags bizzo. Just a simple UNIX 1 or 0 eh waddayareakon? Everything else redundant? I mean it's not as if anyones gonna check it.

[Hein van den Heuvel]

Bill,

If all you are going to do is to poll for an other username/pid to be there, then perhaps consider the simple record lock approach. No privs needed.

First-user:
Get record with some 'key-1' with short time-out + wait
If you can get it, fine. Keep it.
If you can not get it, someone else is using it. Report and bail.

Now (try to) get record with 'key-2'.
If you can get it then the other user is not or no longer, there. Report and wait.
If you can NOT get it, then the second user must be there. Proceed.

Second user:
Get record with some 'key-2'.
If you can get it, fine. Keep it.
If you can not get it, someone else is using it. Report and bail.

Now TRY to get record with 'key-1'.
If you can get it, release it. Report that user-1 is not active yet and wait.
If you can NOT get it, the report user-1 as present and proceed.

General:
Use ACL's on the file with the two records to control who can play. You could use en entire file as a lock, or records within the file. (RMS) record lock come with nice time-out and wait option even through DCL.

If you use a private lock in the program then you can have both users queue up an async lock for the other key, and thus can be immediately notified when the user/process goes away. Of course that will look like a deadly embrace to the OS, so be sure to specify LCK$M_NODLCKWT on the SYS$ENQ call.

Richard>> Hey, hold on a minute there Tom Cruise! Stop trying to cut Bill out from the bait-ball and isolate hime from his traditional support networks.

Agreed.

Richard>> PS. Hey Hein, how 'bout that ludicrous piece of over-engineering that is the VMS Message Facility eh?

Yeah yeah Richard. You are so funny, it is almost sarcastic! Wait, the other way around!
I know that you know that I know when and where to test for flavors of success/failure.

My favorite usage example for this the RMS$_CREATED return when using FAB$V_CIF with SYS$CREATE, and similarly SS$_CREATED on SYS$CRMPSC. Both alternate success statuses often indicate to a calling program to do alternate things.
On the flip side, the try for locked record described above requires a test for a specific anticipated failure versus a generic failure.

Anyway, I maintain that most tests for an explicit SS$_NORMAL are in fact incorrect, and born out of ignorance rather than from skill.

Cheers,
Hein

[Steve Reece_3]

Hey Bill,

If you want to make sure that two users are present, the best way that's easy to implement would be to have a primary and secondary password on the VMS account. That would mean that the two users could use different passwords, but would, of course, rely on users not sharing those passwords with each other.

Otherwise, as someone has already commented, get the second user to take a specific named lock out and only allow access to the application when that lock has been taken. That should be usable when you redesign the application to be runnable from multiple sessions too.

Steve

[Hoff]

As for whatever solution you pick (DCL, ssh, $acmw dual-password, etc) solution, clear that with your management and with the auditors. As much a hassle as auditors can be, ending up holding the bag for a data breach is a far bigger hassle for all involved. Handling the design-affirmation decision to the auditors and the management is generally goodness. Avoiding the aftermath of a data breach is definitely goodness. (pun intended.)

As for that $enq locking stuff I mentioned earlier, here's an intro into locking on OpenVMS:

http://labs.hoffmanlabs.com/node/492

Your application would acquire an exclusive lock on an application-specific and locally-chosen lock resource name, and that will block other parallel access to that resource among all cooperating application invocations locally and (transparently) within the cluster.

Scanning for processes matching a target usually works, but (having seen enough of these weird cases over the years) tends to be as much or more work and more code as using the lock manager, and the process scan tends to have the occasional timing window or degenerate case.

The more that you can use system services and VMS RTL calls here (rather than rolling your own resource and security-related code), the easier it'll be to get your code past the auditors, too.

[Robert Gezelter]

Richard,

Your comment about "Stop trying to cut Bill out from the bait-ball and isolate hime [sic] from his traditional support networks. ..." is uncalled for.

Things may be far different in the "land down under", but here in the USA, compliance is a serious legal responsibility issue [emphasis on "legal"]. Everything on ITRC is cross-referenced by various search engines. Today's New York Times providentially had a front page article entitled "How Privacy Vanishes Online" by Steve Lohr noting how statistical correlations of mined data can strip anonymity (see http://www.nytimes.com/2010/03/17/technology/17privacy.html ).

If there is a future breach of security, this conversation could quite possibly be used against the poster. I have seen it happen to people. It can be extremely embarrassing for all concerned.

When I sense the presence of an issue that is best not left in a public forum, I routinely speak to people off-line and offer some guidance, as a contribution to the community, pro bono.

I would not want Bill to have to be confronted with that contingency. I would rather he have a solid understanding of the issues and limitations without the dialogue being public.

Several years ago, we had an episode in the US involving a self-help group. The end result was a ruling that anything said in a self-help group was fair game in a legal context. If it had been said to a health care provider, attorney, or cleric, it would have been protected.

While IT professionals can sometimes operate without worrying about non-technical issues, compliance is a mix of both, which makes it a potential mine field.

All of that said, I disagree with most of the solutions proffered. The requirement, as I understand it (some background with the PCI specification outside of this thread) is an implementation of the two-man rule (sexism unintended, that is the terminology, it is really the "two-person" rule).

This means:

- NO SHARED PASSWORDS
- INDIVIDUAL AUTHORITY/ACCESS REVOCABLE AT ANY TIME

How does one accomplish this? Not by checking whether another user is logged in. This can be hacked in any number of ways.

One can do this in a variety of ways, but they all involve some degree of subtlety. One way to do it is leveraging time limited certificates issued by a CA, ala Kerberos. Then each user can separately approve the action without creating the potential for Trojan Horse attacks. Each user would log into their normal OpenVMS account or menu. Requests would only be valid if they were digitally signed by at least two authorized requestors (and the data could include the PIDs to ensure that the PIDs were both in the machine room).

The preceding is only a rough approximation of what is needed.

Applications level security outside of the OpenVMS model is always limited to the trustworthiness of the application (which may be spoofed). Additionally, such home-brew security does not leverage the audit and other features of OpenVMS.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

Certificates would certainly work; that has some advantages here. Like deferring the authentication processing over to VMS, deferring the authentication and authorization over to Open Directory or AD or other such is (also) goodness.

As an application programmer, get out of this authentication business and this processing where you can. And whenever you write this or related stuff, get it reviewed and cleared.

Regardless of the authentication mechanisms, I don't see a way to keep this particular hunk of code outside of the trusted base. This code is still making a "go no-go" decision.

And how the application would prompt the folks to authorize this in parallel (without using something "easy", like the dual-password login and two local users gaining access for an application-defined "special" username created within OpenVMS) is also specific to the UI you'll be using to garner the authentication.

As I mentioned earlier, this area is fairly hairy for a (now rather less than) three week deployment schedule.

ps:

On re-reading my text:

>Handling the design-affirmation decision

that was intended to be this:

Handing the design-affirmation...

[John Gillings]

Bill,

I'm not sure I understand the process flow here. If it's something like "we need two people standing at the same screen to start running this application"? If so, I think Steve Reece is on the right path.

Protect the application so it can only be run from a specific username. Make that username captive so all it can do is run the specific application. Make the captive login check for other instances of itself and limit to whatever number you like. Give it two passwords, one for each user. Problem solved? You may go even further and require the username to be entered from a specific login source (like one of the authorising users).

For event deeper security protect your data files with subsystem ACEs so they can only be accessed via the application(s).

Since you're in control of the application you can include a short command prompt timeout so the application automatically closes itself. Ensuring the continuing physical presence of both users is more difficult.

With modern hardware, process creation and login is no longer as slow as they once were. The need for complex procedures which essentially do nothing more than avoid an extra login are no longer necessary. Use the login to give you free auditing, accounting and, in this case, dual password protection.

Hein's two record algorithm will probably work, but make sure you analyse all the timing windows for potential deadlocks. Two locks being acquired in opposite orders always rings alarm bells (though the second action succeeding through failing to acquire the lock means it's more likely that timing flaws will result in false negatives than deadlocks).