Password's ninth characters not verifying

[Tapas Jha]

Hi,

I have a peculiar problem in hp-ux 11.00. I am using L1000,L2000 model. My all systems are trusted. I am illustrating by example: Suppose password is abcde1234. If i enter abcd1234567 then also it is logging in. I am not using NIS. I have checked /etc/nsswitch.conf file also. The entry there is hosts: dns[NOTFOUND=continue UNAVAIL=return] files [NOTFOUND=return UNAVAIL=cont
inue TRYAGAIN=return]

pwconv, authck -pv all i have checked.

One more interesting part right now have found is that if i change password as abcdefgh_1, then it is taking exactly what password is set in.

While changing the password it is taking the exact password which was setted.

My minimum password lenghth is eight char.

Any suggestion will be highly appreciable.

With thanx and rgds
Tapas

[Joseph Loo]

hi,

that is because your server is not on trusted, otherwise the default password length for a non-trusted server is 8, anything after the 8th character is not consider.

do you want to turn your server trusted?

regards.

[Cheryl Griffin]

Check that you have patch
PHCO_26089 s700_800 11.00 libpam and libpam_unix cumulative patch

Minimum password length is defined in the /etc/default/security file.
See
http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90696/B2355-90696_top.html&con=/hpux/onlinedocs/B2355-90696/00/01/111-con.html&toc=/hpux/onlinedocs/B2355-90696/00/01/111-toc.html&searchterms=security%284%29&queryid=20040427-065520

[Bharat Katkar]

If you want to enable password lenght for more than 8 char then you do it by modify the password policy of User thr' SAM.
Then it will ask for axactly what you have assigned.
SAM-Accounts for users and group-Users-Select User-go to Actions Tab-select modify-go thr' password policy TAB.

[Tapas Jha]

Hi All,
Thanx for your reply. I think i have not clearly stated the problem(rather wrongly preset the problem. Sorry for that).
Here is exactly my problem which i found after thouroughly checked.

If i set password it will throw the error since minimum password length is defined 8.
If i set exactly 8 characters password then the problem is coming. The System is ignoring any characters after 8th characters.

If i set more than 8 characters password then it is taking the same password which has been set.

Below are the answers of your questions.

1) Reply to Joseph Loo: My System is trusted. I have once again verified all Systems.
2)Reply to Cherryl Griffin: Minimum password length is defined in the /etc/default/security file is 8 chars.(MIN_PASSWORD_LENGTH=8)

Patch "PHCO_26089 s700_800 11.00 libpam and libpam_unix cumulative patch " is very much exist in all my systems.

Thru SAM i checked from "Password format policy" that Maximum password length is 12.

Hope now you understand my problem clearly. Waiting for your response.

With thanx and Regards
Tapa

[Bharat Katkar]

Tapas,
U have pointed out following

1. If i set password it will throw the error since minimum password length is defined 8.

2. If i set exactly 8 characters password then the problem is coming. The System is ignoring any characters after 8th characters.

3. If i set more than 8 characters password then it is taking the same password which has been set.

So this is the way it should behave. I don't think there is any problem.

[Tapas Jha]

Bharat,

Thanx for reply.

But my concern is password should take exactly the same which i have setted. When i am setting password as 8 characters long then it is taking any characters after 8th.
Suppose i have setted 8 characters password as bharat_1(exactly eight characters). Now system is taking bharat_1 as well as bharat_123 , bharat_1asd (Anything after 8th character).

But the above is not happenning(everything is fine) if i set password more than 8 characters long.

Don't you think this as problem?

Rgds
Tapas

[doug hosking]

Tapas, what you are seeing is one of the compromises necessary in the name of compatibility with traditional UNIX behavior.

Remember that systems can be switched into and out of trusted mode, and that, once discarded, data can't be recovered. Also understand that the format of /etc/passwd files has been standard for 30+ years. The original versions of UNIX did not provide a way of having meaningful passwords longer than 8 characters. That made sense at the time but now causes us headaches.

In standard UNIX, if you use the traditional crypt() interfaces to set a password, ANYTHING YOU TYPE AFTER 8 CHARACTERS IS SILENTLY THROWN AWAY. If you set your password to abcde1234, the '4' is discarded before any encryption is done. In standard UNIX you can login with abcde123, abcde1234 or abcde12345. Only (up to) the first 8 characters are checked when testing for a password match in traditional UNIX.

Suppose you now convert to trusted mode. There is no longer an 8 character limit, but the password has already been truncated, and the 'lost' data can't be recovered, so true longer passwords aren't possible for a given user until the first password change AFTER the conversion to trusted mode. The whole string is then used in the encryption. So when a user logs in with password 'abcde1234' it doesn't match 'abcde123' (what was stored) and the login fails.

This causes a lot of trouble (and support calls) for users who don't understand that the '4' was thrown away.

As a compromise in trusted mode, if the system can tell that your original password was not more than 8 characters long, it accepts any string that matches in the first 8 characters (or fewer if the real password was shorter than 8 bytes).

8 is effectively a magic boundary. If you pick a password longer than 8 characters in trusted mode, all of the characters are used,
unless/until you convert back to standard mode, in which case there is again no longer a place to store more than the first 8 bytes, and the password is potentially truncated.

This isn't the ideal situation, but there is simply no place to store longer passwords in a compatible way in standard mode, and it's not acceptable to lock legitimate users out of their systems, so we have to make some tradeoffs. If we didn't have to conform to standards, we'd very happily remove this strange behavior.

[doug hosking]

It's late, and I'm tired.
Let me try to clarify that.

As a compromise in trusted mode, if the system can tell that your original password
-- as stored AFTER possible earlier truncation due to space limits -- was not more than 8 characters long, it accepts any string that matches in the first 8 characters (or fewer if the real password was shorter than 8 bytes).

[Fred Ruffet]

Doug,

It's exactly that. I encountered the problem on 2 L1000 running 11.00 32 bits a time ago. It wasn't a problem for me, as long as there were a minimum length to passwords of 6 cars and that users weren't using more than 8 (or at least they never noticed they could do that)

If you have this password :
1234567890
You can log with :
12345678ab
12345678fh
12345678
But not with :
87654321 (hopefully :)

It doesn't seem to be a 11.00 issue as long as I can do it with a 11i 64bits I'm actually working on. It doesn't have shadowing or anything else (i.e. standard password mamagement).

Regards,

Fred

[Tapas Jha]

Dough,Fred,Bharat and all, Thanx for your valuable and elaborate reply.

The problem seems exactly same as Fred faced. Earlier we have had
minimum password length of 6 chars, converted to trusted system and minimum
password length have been set as 8 chars. We also didn't notice until yesterday.
It was working with nobody's notice.

Dough, as far as your example is concerned, let me clarify one thing. In your example
you have said that if you set password as abcde1234(Which is nine chars), you can login
as abcde123,abcde1234,abcde12345.

But for my case if i set password as nine or ten chars long then i will be able to login
only if i put the exact password which i setted and which is stored in database.

Rgds
Tapas

[doug hosking]

The question is when the password was set.
If it was set before the conversion to trusted mode, any characters after the 8th are not considered when determining a match.

If it was set after the conversion to trusted mode, then the password is stored in a different location, free of the space constraints that would otherwise limit its length to 8 meaningful characters.

[Fred Ruffet]

I tried a turn on trusted system with my 11i 64 bits : it solves the problem (whereas it doesn't on 11.00)

[Tapas Jha]

Doug,Fred,
My system is 11.00. Password has been changed several times. Our systyems are trusted long before(more than 2 years). Only minimun pasword length from 6 chars to 8 chrs have been changed eight months back.

So, i think before or after the trusted system password set is not the relevant here.

Rgds
Tapas

[Fred Ruffet]

It seems to me that we have a kind of normal behavior for a non-trusted system, that might be corrected by trusted system. Trusted system works fine on 11i, but does not correct this point on 11.00.

Your only solution may be to find a patch. Have a look at recent Quality packs. As long as it had been corrected on 11i, there might be a patch for 11.00... we can hope :)

Fred