Bug 21603 - NIS passwords longer than 8 characters aren't accepted
NIS passwords longer than 8 characters aren't accepted
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2000-12-01 16:45 EST by ken_laird
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-12 16:31:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description ken_laird 2000-12-01 16:45:41 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
authenticate.  This
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 
Comment 1 Bill Nottingham 2000-12-01 16:47:19 EST
What are you using for an NIS server? How is it storing its passwords?
Comment 2 ken_laird 2000-12-01 16:51:50 EST
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?
Comment 3 Nalin Dahyabhai 2000-12-01 17:03:26 EST
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
Comment 4 ken_laird 2000-12-01 17:14:36 EST
getent and the python command you gave give identical encryption strings, except
that the getent passwd field includes the aging string.
Comment 5 Nalin Dahyabhai 2000-12-01 18:49:07 EST
Hmmm.  Are there any messages in /var/log/messages or /var/log/secure that
relate to the user's login attempts?
Comment 6 ken_laird 2000-12-04 10:24:17 EST
	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[19873]: authentication failure; (uid=0) ->
vmsetup for login service
Dec  4 07:21:39 crashl login[19873]: FAILED LOGIN 1 FROM vulcan FOR vmsetup,
Authentication failure

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.
Comment 7 ken_laird 2000-12-05 12:35:04 EST
	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?
Comment 8 ken_laird 2000-12-05 12:51:42 EST
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.
Comment 9 ken_laird 2001-01-12 10:47:50 EST
	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
Comment 10 Nalin Dahyabhai 2001-01-12 11:10:26 EST
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
Comment 11 ken_laird 2001-01-12 11:26:29 EST
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.
Comment 12 Nalin Dahyabhai 2001-01-12 14:30:55 EST
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.
Comment 13 ken_laird 2001-01-12 14:46:52 EST
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.
Comment 14 Nalin Dahyabhai 2001-01-12 16:14:48 EST
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.
Comment 15 ken_laird 2001-01-12 16:31:20 EST
That did it.  Thanks.
Comment 16 Nalin Dahyabhai 2001-01-12 16:33:18 EST

Note You need to log in before you can comment on or make changes to this bug.