O'Reilly - Practical UNIX & Internet Sec... 7015KB

[Chapter 8] 8.8 Administrative Techniques for Conventional Passwords
systems, that means generating new versions of (at least) the following programs:
/bin/login /usr/sbin/in.rexecd
/bin/su /usr/sbin/in.rlogind
/bin/passwd /usr/sbin/in.rshd
/usr/sbin/in.ftpd
1.
Some programs legitimately need to call the crypt() routine more than 10 times in a single process. For example, the server
of a multiuser game program, which uses passwords to protect user characters, would need to call crypt() if it stored the
passwords in an encrypted form (another good idea). For programs like these, you will need to provide a means for them to
run with a version of the crypt() function that allows the function to be run an unlimited number of times.
Do these techniques work? Absolutely. A few years ago, there was a computer at MIT on which guest accounts were routinely
given away to members of the local community. Every now and then, somebody would use one of those guest accounts to grab a
copy of the password file, crack it, and then trash other people's files. (This system didn't have shadow passwords either.) The day
after the above modifications were installed in the system's crypt() library, the break-ins stopped and the system's administrators
were able to figure out who was the source of the mischief. Eventually, though, the system administrators gave up on
modifications and went back to the standard crypt() function. That's because changing your crypt() has some serious drawbacks:
●
●
●
●
●
●
The passwords in your /etc/passwd file will no longer be compatible with an unaltered system,[21] and you won't be able to
trade /etc/passwd entries with other computers.
[21] This may be an advantage under certain circumstances. Being unable to trade encrypted passwords means
being unable to have "bad" passwords on a computer that were generated on another machine. This is
especially an issue if you modify your passwd program to reject bad passwords. On a recent sweep of
numerous computers at AT&T, one set of machines was found to have uncrackable passwords, except for the
passwords of two accounts that had been copied from other machines.
If your site transfers /etc/passwd entries between machines as ways of transferring accounts, then you will need to have the
same crypt() modifications on each machine.
If you use NIS or NIS+, then you must use the same crypt() algorithm on all of the UNIX machines on your network.
You'll need to install your changes every time the software is updated, and if you cease to have access to the source, all of
your users will have to set new passwords to access the system.
This method depends on attackers not knowing the exact number of rounds used in the encryption. If they discover that
you're using 26 rounds instead of 25, for example, they can modify their own password-breaking software and attack your
system as before. (However, this scenario is unlikely to happen in most environments; the cracker is more likely to try to
break into another computer - hardly a drawback at all!)
If an insider knows both his cleartext password and the encrypted version, he can also determine experimentally how the
algorithm was changed.
NOTE: While increasing the number of rounds that the encryption algorithm performs is a relatively safe operation,
don't alter the algorithm used in the actual password mechanism unless you are very, very confident that you know
what you are doing. It is very easy to make a change you think is adding complexity, only to make things much
simpler for an attacker who understands the algorithm better than you do.
8.8.8 Disabling an Account by Changing Its Password
If a user is going away for a few weeks or longer, you may wish to prevent direct logins to that user's account so the account won't
be used by someone else.
As mentioned earlier, one easy way to prevent logins is to insert an asterisk (*) before the first character of the user's password in
the /etc/passwd file or shadow password file.[22] The asterisk will prevent the user from logging in, because the user's password
will no longer encrypt to match the password stored in /etc/passwd, and the user won't know what's wrong. To re-enable the
account with the same password, simply remove the asterisk.
[22] This method of changing a user's password is not sufficient if the user has a .rhosts file or can rlogin from a
computer in your computer's /etc/hosts.equiv file. It also will not stop the execution of programs run by the cron or at
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch08_08.htm (7 of 9) [2002-04-12 10:44:29]