topic Re: Dual control using UAF features in Operating System - OpenVMS

Dual control using UAF features

Bill Hallman — Fri, 12 Mar 2010 00:25:20 GMT

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.

Re: Dual control using UAF features

Brad McCusker — Fri, 12 Mar 2010 00:38:57 GMT

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

Re: Dual control using UAF features

Hoff — Fri, 12 Mar 2010 00:47:01 GMT

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.

Re: Dual control using UAF features

Bill Hallman — Fri, 12 Mar 2010 01:43:13 GMT

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.

Re: Dual control using UAF features

Hoff — Fri, 12 Mar 2010 02:13:10 GMT

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.

Re: Dual control using UAF features

John Gillings — Fri, 12 Mar 2010 02:56:49 GMT

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.

Re: Dual control using UAF features

Robert Gezelter — Fri, 12 Mar 2010 03:13:06 GMT

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)

Re: Dual control using UAF features

Richard J Maher — Sat, 13 Mar 2010 22:59:14 GMT

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?

Re: Dual control using UAF features

Steve Reece_3 — Sun, 14 Mar 2010 02:49:14 GMT

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

Re: Dual control using UAF features

Hoff — Mon, 15 Mar 2010 13:59:28 GMT

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.

Re: Dual control using UAF features

Bill Hallman — Mon, 15 Mar 2010 18:43:54 GMT

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.

Re: Dual control using UAF features

Richard J Maher — Mon, 15 Mar 2010 21:48:55 GMT

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

Re: Dual control using UAF features

John McL — Mon, 15 Mar 2010 22:31:24 GMT

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.

Re: Dual control using UAF features

Hein van den Heuvel — Tue, 16 Mar 2010 02:35:52 GMT

>> 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

Re: Dual control using UAF features

Robert Gezelter — Tue, 16 Mar 2010 03:07:02 GMT

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

Re: Dual control using UAF features

Bill Hallman — Tue, 16 Mar 2010 21:01:52 GMT

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?

Re: Dual control using UAF features

Hoff — Tue, 16 Mar 2010 22:07:08 GMT

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.

Re: Dual control using UAF features

Robert Gezelter — Wed, 17 Mar 2010 04:39:06 GMT

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

Re: Dual control using UAF features

Richard J Maher — Wed, 17 Mar 2010 10:43:21 GMT

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.

Re: Dual control using UAF features

Hein van den Heuvel — Wed, 17 Mar 2010 12:59:17 GMT

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