psswd&shadow 2 passwd together?!!

hi, all
I just started on new box where I have to diff passwd working perfectly on the very same account/user. I see that shadow was added recently (I'm not a root in there), I see 'x' in passwd. Not sure how it should work, should I change old passwd for one defined in shadow? Or it's fine to have 2 of them, or it's a bug?

It's RHat 5 Ent Linux.

Tx
T

you don't need to edit /etc/shadow directly. The passwords are stored here for security reasons as /etc/passwd needs to be world readable.

/etc/passwd used to contain actual hashed passwords -- readable by any user on the system! At the time, crypt() was (intentionally) too slow for a brute-force search(feeding every dictionary word times every possible salt into crypt() until you get the same hash) to be practical, and this worked for a while, but eventually CPU's got fast enough that brute-forcing a hash became possible.

So they moved the password hashes into /etc/shadow, which nobody but the login system can read. They kept the rest of the data in /etc/passwd.

Modern systems also often use better hashing algorithms than crypt().

Thansk,
but do we have to have 2 diff password for system ? Now I can login using both of them.

Tx
T

No. Password hashes aren't stored in /etc/passwd at all anymore, just an 'x' meaning 'this user has a password in /etc/shadow', or perhaps some other string meaning 'this user is disabled'. Nothing else is valid.

YEs, so it's some kind of bug. Now I can use 2 passwords for the same account.

T

How long are the passwords? Many systems ignore everything after the first eight letters(another legacy of UNIX crypt).

One is 7 char, second is 12 char long. They both work for the same account.

T

anything after first 8 is ignored for systems using DES.

Thanks, Frank, thanks all
Still I don't understand why those 2 different passwords work for me, they have different chars/order . Can anybody can explain this for me or send to any info.
I just checked they have diff md5 value, even for first 7 and 8 chars. Those are completely diff combinations.

Gracias
T

I have never used RHEL and seldom use Linux, but my first guess would be that your system is using PAM and that it's configured to allow multiple forms of authentication. Perhaps the contents of /etc/pam.d/login (if it exists on your system) might shed some light.

Regards,
Alister

what is the output after execute the below command?

$ cat /etc/pam.d/system-auth /etc/nsswitch.conf

Just a suggestion:

The hashing algorithm (at least the original one mentioned by Corona and some others used - don't know which exactly you are employing here) was a surjective function. This means that every password has one and only one hash value, but not every hash value has exactly one password. Several passwords can have the same hash value.

This might be the case here.

I hope this helps.

bakunin

Moderator comments were removed during original forum migration.

Naturally password hashes have to be surjective, if information wasn't lost you could make an algorithm to convert hashes back to plaintext.

One hash fits more than one password, in theory, but the odds of finding the a second one are very remote. The odds of the second being anything sensible are also remote -- more likely it'd be untypable garbage.

Tx, guys

I see that hash value (md5) is defenitly different for those password (I replaced actual string for demonstration. So still have same questions why those 2 different length passwords works ?:wall:

-bash-3.00$ echo -n "passw1" | md5sum
1243543e62447b14aee90ca047e2e330  -
-bash-3.00$ echo -n "password2" | md5sum
45eb34739884655cc54b0c36bd09d50d  -

And here is output from requested files, sorry it took me while to migrate to another system for security reasons.

bash-3.00$ cat /etc/pam.d/system-auth /etc/nsswitch.conf
# =====================================================================
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient      /lib/security/pam_lsass.so      try_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/pam_lsass.so      unknown_ok
account     sufficient      /lib/security/pam_lsass.so
account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     required      /lib/security/$ISA/pam_permit.so

password    sufficient     /lib/security/pam_lsass.so
password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
#

# =====================================================================
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
#       nis or yp               Use NIS (NIS version 2), also called YP
#       dns                     Use DNS (Domain Name Service)
#       files                   Use the local files
#       db                      Use the local database (.db) files
#       compat                  Use NIS on compat mode
#       hesiod                  Use Hesiod for user lookups
#       ldap                    Use LDAP (only if nss_ldap is installed)
#       nisplus or nis+         Use NIS+ (NIS version 3), unsupported
#       [NOTFOUND=return]       Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files ldap nis
#shadow:    db files ldap nis
#group:     db files ldap nis

passwd:     files lsass
shadow:     files
group:      files lsass

#hosts:     db files ldap nis dns
hosts:      files dns

# Example - obey only what ldap tells us...
#services:  ldap [NOTFOUND=return] files
#networks:  ldap [NOTFOUND=return] files
#protocols: ldap [NOTFOUND=return] files
#rpc:       ldap [NOTFOUND=return] files
#ethers:    ldap [NOTFOUND=return] files

bootparams: files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files
netgroup:   files
publickey:  files
automount:  files
aliases:    files

Try giving md5 only the first eight characters of each :wall:

The hashes in the shadow file aren't direct md5's of passwords, I'm pretty sure. It depends on implementation but usually it's a hash of the password plus a small 'salt' string, to prevent two users with the same password from having identical hashes(and prevent people from just comparing hash keys to big lists of known hashes.)

If your passwords use md5, be aware that md5 has been cracked, and is now considered a poor algorithm. There's software which can generate strings to match a given md5 on command. This doesn't matter unless an attacker has root access to your shadow file though -- in which case you're screwed anyway.

Thanks, Corona !
It's still different:
my <passwd1> is 7 char long, and <password002> is 11 char.
I tried to md5 all combinations, including <passwd1_> (with space to get 8) they are different. Which is perfectly expected if you feed 7 and 8 chars to md5.

I don't think we have md5 for hashing, I just try to understand how it works.

Tx

Are the first 7 characters the same, then? Do the passwords have any resemblance to each other at all?

This system's authentication setup appears to be configured to first try the local passwd file followed by, in case of failure, an active directory domain.

I doubt a hash collision is the problem. More likely, one password is set on the local *nix system and a different one on the domain controller. If local auth fails (pam_unix.so), the password is reused (try_first_pass) by pam_lsass.so.

Regards,
Alister