Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

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