Operating System - OpenVMS
1748159 Members
3797 Online
108758 Solutions
New Discussion юеВ

Re: Dual control using UAF features

 
Bill Hallman
Occasional Advisor

Dual control using UAF features

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.
31 REPLIES 31
Brad McCusker
Respected Contributor

Re: Dual control using UAF features

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


Brad McCusker
Software Concepts International
Hoff
Honored Contributor

Re: Dual control using UAF features

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

Re: Dual control using UAF features

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

Re: Dual control using UAF features

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

Re: Dual control using UAF features

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.
A crucible of informative mistakes
Robert Gezelter
Honored Contributor

Re: Dual control using UAF features

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

Re: Dual control using UAF features

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

Re: Dual control using UAF features

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

Re: Dual control using UAF features

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.