HP-UX password strengthening

[Kurt Renner]

I am looking for a way to intercept a user's password to verify that it conforms to certain criteria that our IT security department has set forth as the "ideal" password format. I have considered using Expect to do this, but also read that it is possible to do Expect-like things with Perl. I have basically no knowledge of how to use Expect, but I do have some experience with Perl, and would like to use Perl to verify that the user's password conforms to the rules prior to actually changing the user's password. If anyone has any pointers on how this might be accomplished with Perl, please send them my way. We already have Perl installed on all our machines. I believe we would have to install Expect/Tcl on all machines if we go the Expect route.

I am not opposed to other methods. If you have other ideas on how I can accomplish my goal I would love to hear them. Perl and Expect are just two of the possibilities I have come up with.

[Pete Randall]

Kurt,

You can implement some of these checks using the /etc/default/security file (see "man security"). The security file allows you to implement a minimum password length and a password history depth. You can also convert to a trusted system which will add additional capabilities.


Pete

[Steven E. Protter]

It is far easier to make your system a trusted system.

At that point with sam you can enforce password standards and know they can not be violated.

You can set minimum length and even restrict dictionary words.

Another alternative is to run a password cracker against /etc/passwd

cp /etc/passwd to a directory owned and only viewable bhy root. Use crack to attack the file. It will display a report of passwords that it has guessed.

SEP

[Kurt Renner]

Thanks for the quick response.

We have already taken advantage of the features available via the /etc/default/security file, and trusted systems.

Some examples of what we want are:
- Must start with a character
- Must have no more than 2 pairs of repeating letters
- No leading or trailing numbers

...among others that are not possible to control (that I am aware of anyway) through native HP-UX controls (trusted or untrusted).

[Darren Prior]

Hi Kurt,

If you were to go to a trusted system you could set "Use Restriction Rules" which includes a dictionary check. Whilst the standard dictionary doesn't contain any words with numbers in them, you could generate a list of "unwanted" passwords and add them to the dictionary. These passwords would then not be allowed.

This won't stop people using certain passwords eg; starting with a numeric - unless you can create a list of all possible passwords that start with a numeric, then add them to the list.

regards,

Darren.

[Alan Turner]

Larry Wall's "Programming Perl" book (O'Reilly) has a password validation example in it - I believe he puts his password script in place of the passwd program (sorry, I don't have the book to hand at present).

[Steven Sim Kok Leong]

Hi,

Don't forget audits. I personally prefer an audit scheme with password cracking tools such as john the ripper, to complement TCB restrictions, so as not to slowdown the password change process.

TCB, as the rest has mentioned, already provides a specific criteria for limiting to strong passwords which you can finetune.

For more details on john the ripper,
http://www.openwall.com/john/

Hope this helps. Regards.

Steven Sim Kok Leong

[Sridhar Bhaskarla]

Hi,

//a way to intercept a user's password to verify that it conforms to certain criteria //

You can use /etc/default/security and the features offered by trusted system to impose the restrictions as already said. Look at docs.hp.com for the information on modprdef and modprpw commands.

After doing so, you need to regularly verify the comformity of your restrictions by "cracking" the user passwords. "crack" can help you doing so. A good security system would include a highly secured system running crack all the time. It receives password files (you will need to write a script to get the password entries from the tcb structure on a trusted system) regularly, cracks them and reports the system administrator on the weak password. You can implement strong dictionaries so that the cracking can be effective. Look at the following site to get this program.

http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/crack-5.0/

-Sri

[Kurt Renner]

Thanks for all the suggestions. I appreciate them all.

Darren Prior: Interesting suggestion. I think I have exhausted the capabilies of what trusted systems can do for me to reach my goals for certain password restrictions. Adding to the dictionary to eliminate the common words starting or ending with numeral(s) would be difficult to accomplish. I would need each word in the dictionary with a leading and trailing digit, and it gets worse if you consider using multiple digits before and after. I thank you for the suggestion, but I don't think it will get me where I want to be.

Alan Turner: I had stumbled across an example using the Expect Perl module as well, but it is not listed in my Oreilly "Programming Perl" book. There ARE 2 examples in the "Perl for System Administration" however. One suggests using the Cracklib C library, and the other just illustrates how to use the Expect module to automate changing passwords. I think I will go the Perl route with my own routines to verify the passed password complies with our own internal rules before submitting the password to the built-in passwd command. Thanks for the pointer!

Steven Sim Kok Leong: Auditing is another phase I will be working on in the near future. We plan on investigating IDS9000's capabilities for this task.
I have considered using John the Ripper and/or Crack to verify my users are using strong passwords, but there are political issues that go along with that that I'd prefer to avoid. If I can verify it is a strong password before it is used by a user, that should negate any need for regular password cracking IMHO. Thanks for taking the time to answer my question.

Sridhar Bhaskarla: Thank you also for the suggestion. My response is much the same to your suggestion as Steven's above. Thanks for taking the time to help.

In summary, We have converted all our systems to trusted systems, and enjoy the security-related benefits that result from that process. We have another tool (not on HP-UX) with more stringent password rules than we can achieve with TCB. The goal is to match the rules available with the other tool. At this time, I believe the quickest and most flexible solution is to take the example Perl scripts I have been able to find and fine tune them to match our requirements. Once that is accomplished, I will rename the system passwd commands, change the permissions on the command so an end-user cannot execute it directly and name this perl script "passwd" which then calls the renamed system passwd command after the password has been verified to be a strong password.

Thanks to all for your valuable input!

Kurt Renner

[Keith Buck]

Kurt,

One other thing to watch out for with that method is that patches don't overwrite your Perl-based passwd program. If you put it in the same place, a patch will simply overwrite it with the new binary (and update the permissions accordingly to allow all users to use it again...)

Should be easily worked around if you know that can happen...

-Keith

[BSSG]

Our group also has similar requirements for password strength checking. Patch PHCO_24606 was an excellent start in this direction, but I could see where it could be made even stronger.

We also have a need for the type of strength checking that is performed via the Linux pam_cracklib module, including dictionary checks. I believe the source for pam_cracklib is available, as is the libcrack system library.

I think the problem with a roll-your-own Perl check utility is that it may be more vulnerable to attack than a more widely-tested PAM module. Plus you have the issue of passwd being overwritten every time a new passwd patch is installed. So my preference would be to use well-tested PAMs.

Good topic, thanks.

--
Bob

[Kurt Renner]

Keith and BSSG.

I agree with everything you mentioned. I had considered the problem with a patch for the passwd program overlaying my Perl script. Like you said, easy to work around, you just have to be aware that this can/will happen.

As for the patch. I had discovered this as well, and while this makes for better passwords, and more rule flexibility, it still doesn't address the 3 criteria which I spelled out earlier which have been given to me as 'requirements'... among others.

> "I think the problem with a roll-your-own Perl check utility is that it may be more vulnerable to attack than a more widely-tested PAM module."
I agree. The final authority on acceptance or rejection of the password is the passwd program however. The only information that I can think of that would be helpful to an attacker is knowledge of the rules required for a password on our systems. Knowing the rules is somewhat helpful I suppose, but it still leaves a myriad of possible character/number combinations for a password that hopefully cannot be cracked easily.

I would definitely prefer a HP-supplied PAM module as well that has been fully tested and supported, but unfortunately I don't have that luxury at this time. Oh how I wish I did!

Keep the opinions coming. I want to make sure whatever the solution may be is a well thought-out solution. At this point, the Perl script still appears to me the only viable (hopefully short-term solution).

I am going to open a call on the ITRC asking what it would take to get more password rules/options built in.

Thanks,
Kurt Renner

[Darren Prior]

Hi Kurt,

Thanks for providing feedback on people's comments - it's great to know that it's been some help. And yes, I was aware that it would be a nightmare job to populate the dictionary with all those extra words - there are people out there who have taken those steps!

You asked "what it would take to get more password rules/options built in." The easy answer to that is you could log a call with your local Response Centre and ask them to raise an Enhancement Request; with you supplying details of what extra things you'd want added. However, you'd need to supply a good justification of why these changes are required. Also bear in mind that it takes time for changes to be written and tested; and there needs to be enough interest from others too.

regards,

Darren.

[Kurt Renner]

I logged a call with HP's ITRC providing the password configuration rules I would like to see. An enhancement request JAGae91129 has been submitted to HP Labs.

Thanks,
Kurt Renner

[Anthony_107]

One other option is to use a product that can be installed on a web server to control system passwords. We are looking at using a product called PasswordStation from a company named Avatier (www.avatier.com).

I allows you to enforce all the rules you mentioned across multiple platforms such as NT, Novell, Windows, Unix. It gives the users a single point interface to control their passwords.

[Kurt Renner]

Thanks for the response Tony. We have discovered that a web tool we have deployed a couple of years ago called P-Synch from M-Tech (www.psynch.com) has a feature called "Transparent synchronization" (http://www.psynch.com/about/trans-synch.html) that basically intercepts the user's password as they change it on the HP-UX machine, verifies that it conforms to rules defined on the P-Synch server, and then propagates the changed password to other machines/environments defined to the P-Synch server. P-Synch is capable of changing passwords on:
-Windows NT servers and domains.
-Windows 2000 servers and active directory.
-Unix servers.
-MVS or OS390 mainframes.
-LDAP directories.
in this manner.

I was unaware this feature was available to us when I originally posted this question. We have it functioning in a test environment at the moment. Thanks for all the responses. There were some good suggestions. My hope is that others may benefit from this discussion.

Kurt Renner
Kimball International.

[Fabrizio Tedone]

Hello all,
I've been reading all your suggestions on this topic and I have a question : where can I find more information about /etc/default/security ? if I do 'man security' on my system, I get no manual entry for security.
thanks !

[Fabio Ettore]

Ciao Fabrizio,

it always is better to submit a new question in ITRC forum than take an old thread.

If you submit again your question as a new message (please write too what is exactly your O.S. and version) then sure you will have more luck.

Best regards,
Ettore