SUMMARY: Bad password policy

From: Lenny Turetsky (
Date: Wed Feb 01 1995 - 08:56:01 CST

  This message is in MIME format. The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to for more info.

Content-Type: TEXT/PLAIN; charset=US-ASCII

Well, as usual, I must apologize for the delay.

My thanks go out to the following folks:

"Charles H. Buchholtz" <>
Alexander Haiut <>
Dave Fetrow <>
Gene Rackow <>
George Pallas <>
Jesse Adam <jaa@pollux.GEOG.UCSB.EDU>
Kai Grossjohann <>
Michael Myers <>
Rich Chung <> (Jochen Bern) (Brett K. Lynch) (Dotty Pon) (Leon Koll) (Perry Hutchison) (Phil Hubbard x6177)
scott hollatz <> (S. D. Raffensberger 52882 (RD))

Basically, I've decided to go with my original policy (change the
cracked passwd's user's shell to a phoney that prints out a message
and notifies me of the attempt) with one addition: I'm now running
yppasswdd with the '-noshell' option so that shells can't be changed
remotely (since that daemon is *stupid* enough not to check whether
the *original* shell is in /etc/shells!).

Here's what folks told me:

From: (Dotty Pon)
> You can expire the user's password so that the next time they
> login, they must change their password before they can get
> onto the system. Is this an acceptable solution?

This is not an acceptable solution. What if the next person who tries
to login as that user is a cracker? S/He just changes the passwd to a
new one, and then the *real* user can't use it, but the cracker still

Not a wise move, IMO.

From: Alexander Haiut <>
> Yes. If there are xterminals running xdm connected to your machine,
> and these people have access to them, then ~/.xsession file may be
> used to log into the system.

Not a concern here (no xdm), but the rest of you may want to take note...

From: (Jochen Bern)
> Better implement a "proactive passwd" which won't accept weak Passwords
> in the first Place.

I'm doing this (we already run npasswd, but it's dictionaries are
considerably smaller than crack's -- I'm going to arrange for both
programs to use the same dictionaries).

> PCNFS has the (faulty) Method of allowing Access iff the Shell's Filename
> ends in 'sh'.

I'd heard of this. My phoney shell's name doesn't end in 'sh$' so I'm OK.

> ... as a Sidenote: To disable an Account *completely*, remember to
> take Care of WWW Pages, Mail Aliases, Crontabs, ...

Good point, but (in this case) I don't want to remove the account,
just disable it until a better password is given.

From: (Leon Koll)
> Could you send me this shell script ?

see attached.

From: "Charles H. Buchholtz" <>

> I also chmod 0 their home directory, because I have many people who
> don't use their account on my machine, but log in to other machines
> which NFS mount their home directory. Since the remote machine uses a
> different password, you might say that there's no problem with this,
> but I use the same "account locking" procedure for every type of
> situation, and I got into trouble when people were actively using
> their account and had no idea that it was locked. For example, the
> lock where I say, "your account has been deleted. If you still need
> this account contact me immediately!".

I control all of the machines that can access my users' home dirs, so
this doesn't apply here, but it's an important point to bear in mind
for the future.

> [another vote for pro-active passwd changing program]

From: Rich Chung <>
> [recommends getting a larger crak dictionary]
I've got 8M worth of foreign dictionaries here -- if anyone wants,
they're ftp'able:

From: (S. D. Raffensberger 52882 (RD))
> I believe users who have .rhosts files can still log in
> no matter how you mess with the passwd file. They can
> simply use "rsh machine /bin/sh" and it will probably
> let them in.

Not so. Any commands that a user attempts to rsh will be passed to his
shell -- if his shell doesn't interpret commands, those commands go to
the bit-bucket.

From: Michael Myers <>
>[re-iterates the above point about NFS]

From: Gene Rackow <>
> Truth is, it will depend on what kind of machines you have on the net, and how
> they are configured. For example if you support machines running NeXT-Step,
> then you need to * out the passwd as well or someone can sit down
> and login at the NeXT console. It ignores the shell field of the passwd file
> when it starts the window system. You can do alot by clicking on stuff.

Sounds like another version of the xdm point above. Doesn't apply
here, but I'll bear it in mind for the future.

> Are you running YP/NIS on your net? If so, then you also want to * it out
> as anyone can change the shell to whatever they want fairly easily. The
> yppasswd daemon does little to authenticate things if you know the users
> passwd.

Like I said above, I'm now running yppasswdd with the '-noshell'
option. Thanks for pointing that out.

Perhaps the folks at SUN would be good enough to add some intelligence
to that daemon.

> Another thing to worry about is are you sure you are talking to the
> real owner of the account? Cracker bob greps for your special shell from
> the passwd file and calls in for a new passwd on "his" account.

Well, they have to come see me in person and show a Yale ID (although
those should be easy to fake).

From: (Phil Hubbard x6177)
> [another vote for npasswd]

From: George Pallas <>
> No, it really isn't enough, but as long as you're dealing with "weak"
> passwords, and as long as the matter gets cleaned up within a day or
> two, you should be able to skate by. COMPROMISED passwords are a
> different matter. If you know an account's password has been compromised,
> disable it IMMEDIATELY, using the asterisked password field or similar.
> You may also want to remove the user's .rhosts file, if any, in that
> case.

Not the case I'm worried about. .rhosts is another story...

From: Dave Fetrow <>
> [yet another vote for npasswd]

From: (Brett K. Lynch)
> Please, for you own security, disable the login COMPLETELY, by placing a
> '*' in the pass field, as you mentioned. There are several ways to
> abort any C script, and the risk is simply not worth it. Also, of course,
> at least run C2, and something like Passwd+ or NPassword to make your
> job a bit easier.

I don't see what the risk would be, and there is some value in having
the user see the bad login message (although if they keep trying their
passwd and fail, they'll probably end up contacting me anyway ;-).

From: Jesse Adam <jaa@pollux.GEOG.UCSB.EDU>
> i don't have an answer for you but putting a '*' in the password field
> does not necessarily prevent users from logging in. they can still
> login provided they have created ~/.rhosts to enable remote login from
> another host (presumably from a host where your [NIS]password file
> is not used on that host)

True. I guess the most secure thing is to * out the passwd *and* to
give them a bad shell.

From: Kai Grossjohann <>
> [one more vote for npasswd]

From: (Perry Hutchison)
> Re disabling an account by changing the shell to something that's not
> in /etc/shells, even if you * out the password, their cron jobs will
> still run and I think they can still rsh in if they have a ~/.rhosts .
> That's all I've thought of offhand.

Cron jobs are a good point, but I'm not too worried about that
(assuming that the cron jobs were put it by the real users and not a

.rhosts, as noted above, won't work w/a non-shell.


My thanks to all who responded.


 | Yale Economics Dep't | Lenny Turetsky |
 | System Administrator | |
 | My employers paid for some of my time and energy. |
 | My opinions were never for sale. |

Content-Type: TEXT/PLAIN; charset=US-ASCII; name=nosh
Content-Transfer-Encoding: BASE64
Content-ID: <>


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:15 CDT