Red Hat Bugzilla – Bug 21603
NIS passwords longer than 8 characters aren't accepted
Last modified: 2005-10-31 17:00:50 EST
I have installed the revised pam module, pam-0.72-34, which was modified
to tolerate an aging string from an NIS password file. That works fine.
However, I have discovered another NIS password related problem.
If the user's password is longer than 8 characters, it will not
problem only occurs if the password entry is retrieve via NIS. If you
create a local account
for the same user with the same encrypted password string, it authenticates
What are you using for an NIS server? How is it storing its passwords?
We are using an HP-UX NIS server. It uses the stock DES encryption routine and
the encrypted passwords are stored in the password field, followed by a
comma and a 4 character aging string. Is that what you needed to know?
The standard DES-based crypt() discards characters after the eighth in a
password, so if anything you should be seeing odd successes with any password
which shares the same first eight characters.
When you run "getent passwd username" for the user, do you see the hashed
password in the second colon-separated field? Does it match the result of
python -c 'import crypt;print crypt.crypt("password","salt")'
("salt" should be the first two characters of the hashed version of the
getent and the python command you gave give identical encryption strings, except
that the getent passwd field includes the aging string.
Hmmm. Are there any messages in /var/log/messages or /var/log/secure that
relate to the user's login attempts?
There are no messages in /var/log/secure, but the following appears in
/var/log/messages after a failed attempt with long password:
Dec 4 07:21:37 crashl PAM_unix: authentication failure; (uid=0) ->
vmsetup for login service
Dec 4 07:21:39 crashl login: FAILED LOGIN 1 FROM vulcan FOR vmsetup,
vmsetup is the user name I am using to trouble shoot this problem, as you can
see. One other thing. There is a noticeable delay of 2-3 seconds during the
before it is rejected. That may not indicate anything, because it takes just as
long to reject a deliberately mistyped password.
For what it is worth, vmsetup, with this same 9 character password, can login
to a Redhat 6.2 box without a problem.
I appreciate your prompt responses! Thanks.
OK, I have done some sleuthing in the pam source code.
In the function _unix_verify_password in ../pam-0.72/modules/pam_unix/support.c,
the problem arises at line 642 where the code calls bigcrypt to set pp.
I have been using a test user "vmsetup" with the password "iluv2ski2".
bigcrypt generates a 24 character string "/NGilKAa2YNnodPe3kn5qaaY" and passlen
gets set to 24. However, the password utilities on HP-UX generated the
following "/NGilKAa2YNno,o6BN", which, as you can see, matches what came from
bigcrypt up to 13 characters. After that, the NIS/HP-UX password contains the
comma and aging string. Since passlen was set to 24, it tries to compare
apples and oranges.
For another user, with a 7 character password, the NIS password and the
bigcrypt password were both 13 characters long. After that, in the NIS
password, comes the aging string. But since bigcrypt generated only 13
characters in that case, the strncmp matches.
I haven't located bigcrypt in the source code yet. I am not sure if it is
doing the wrong thing, or if the logic for setting passlen should be altered to
set it based on the password retrieved from the password file by getpwnam.
What do you think?
OK, here is some more data. I took the aging string off on the NIS password for
vmsetup. Now bigcrypt generates the exact same 13 character encryption as
in the password file. So, somehow the logic in bigcrypt is being thrown off by
the aging string in the "salt" passed to it.
Is there some reason this bug has been ignored since December 5th?
I have a suggested change to bigcrypt.c that I can send you if anyone is
I've done some research and determined that the function it's modeled after
(Tru64's crypt16() function, which I assume is DEC's C2 algorithm) returns a
longer crypted string. So both systems are doing what they're supposed to do,
but bigcrypt() is just the wrong algorithm to use when checking passwords with
But it seems to me that the PAM module has no idea where the password entry it
is looking at came from, NIS or local file. Assuming that a comma is only ever
used to delimiit an aging string, I would think that that is the only clue the
PAM module would get that might suggest a different algorithm needs to be used.
What is happening now is that the comma makes the salt long enough that bigcrypt
thinks it needs to do another "chunk". Checking for the comma and replacing it
with a null prevents that confusion.
The salt length is used to determine whether or not to truncate the password
before passing it to crypt(). If it's 13, the password is terminated at 8
characters, and bigcrypt() returns the same result as crypt(). If it's not 13
the password is not terminated, and because you have a 9-character password,
bigcrypt() returns more data than you want.
The standard crypt() and md5crypt() mechanisms are not supposed to allow commas
in salts, and they don't generate commas on output, so terminating the crypted
string at the first comma (after the 13th character, in case some broken scheme
or salt is being used) would probably work here.
I've put a pam-0.73-2 out in http://people.redhat.com/nalin/test/ which
implements this change. Please see if it solves the problem.
Sorry, no. It fails if the user with the 9 character password types all 9
characters. It you just type 8 characters of the password, you can login.
Ah, found an error in my attempt to fix it (was comparing the first character of
the salt, not the one where the comma would be if there is one). I'm almost
certain that the version of 0.73-2 that's now in the test/ directory (I didn't
bump the release number this time around) will fix this.
That did it. Thanks.