3

On some Linux box (SLES 11.1) which is a NIS client I can do as root:

ypcat shadow.byname

and get output, i.e. some lines with the encrypted passwords, amongst other information.

On the same Linux box, if I run the same command as unpriviledged user, I get

No such map shadow.byname. Reason: No such map in server's domain

Now I am surprised. My good old knowlege says that shadow passwords in NIS are absurd because there is no access control or authentication in the protocol and thus every (unpriviledged) user can access the shadow map and thereby obtain the encrypted passwords.

Obviously we have a different picture here. Unfortunately I don't have access to the NIS server to figure out what is happening. My only guess is that the NIS master gives the map only to clients conection from a priviledged port (>1024), but this is only an uneducated guess.

What mechanisms are there in current NIS implementations to lead to a behavior like the above? How "secure" are they? Can the be circumvented easily? Or are shadow passwords in NIS as secure as the good old shadow files?

Mark Salzer
  • 31
  • 2

1 Answers1

2

Access to maps that are not world-readable under /var/yp/{domainname}/ on the NIS master is restricted to clients making request from privileged port (<1024). It's not as secure as local /etc/shadow but still slightly better than nothing.

For a better security Sun designed NIS+ but it never really got widely adopted.

Much better is LDAP where the password hash doesn't have to be fetched from the server to the client but instead the client sends the proposed password to the server for verification (LDAP auth-bind).

MLu
  • 23,798
  • 5
  • 54
  • 81