Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 4979

Summary: problems with non-us ascii in passwords
Product: [Retired] Red Hat Linux Reporter: Niels Walet <Niels.Walet>
Component: passwdAssignee: David Lawrence <dkl>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: Niels.Walet
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-09-20 17:56:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Niels Walet 1999-09-08 09:36:21 UTC
It seems that when using a pound sign in the middle of a
password, the password effectively terminates over there.
One can logon with the any password containing in its
initial part the password up to and including the pound
sign, followed by any other string.
This is a high security risk! Pam password checking seems to
look at the whole password, it is just the authetication
part that doesn't seem to work right

Comment 1 Niels Walet 1999-09-08 09:41:59 UTC
Actually, usin a $ sign gives rise to the same problem!
(i.e. setting password to FFFFF$GGGGG allows su using FFFFF$ as
password!)

Comment 2 Niels Walet 1999-09-08 10:42:59 UTC
I have found the solution to my passwd problem: on upgrade to rh6.0
my /etc/pam.d/passwd file was written incorrectly. Copying one from
a fresh install solved the problem. So a warning to all of you: when
upgrading change the last line of the file to
password   required     /lib/security/pam_pwdb.so use_authtok nullok
md5 shadowon further checking this seems to be due to a problem with systems
upgraded to 6.0 only - freshly installed systems don't have trhe
problem. The length of the stored passwords in the /etc/shadow files
on the upgraded systems is much smaller than those on the freshly
installed one. It seems that the symbol issue is moot, it is just a
length issue around 8 characters of the password are used, the rest
are ignored!

Comment 3 Michael K. Johnson 1999-09-20 17:56:59 UTC
Simply running the authconfig program will allow you to
select md5 passwords on an upgraded system.  We do not change
the default on old systems in order to manage backwards compatibility
correctly.