I know about the Tenex password bug, yes, I surely agree I
don't want to be *too* precise. Fortunately, there's no danger
of that, since the kerberos server does not know passwords, only
keys, it hasn't a ghost of a chance of leaking any knowledge
about the password beyond "yes" or "no". Given that
passwords can be > 8 characters, and keys are fixed
at 8 bytes, there could well be many passwords that
hash to the same key. If somebody comes up with a
fast way to dehash keys, then I suppose the kerberos
server *could* say "your password is either 1 character too short
or 63 too short;" mind you, I'm not advocating that!
The "unix algorithm" about being coy about non-existant people
made a lot of sense when Unix machines were expensive, small,
slow, and networked only by telephone, if at all. In such
a case, even knowing "who" had valid loginids on the system
might be valuable data all by itself. An outsider might be
able to learn a lot about a company just by knowing who
works on what projects. Knowing "who" was also a valuable
clue to a system cracker, because it's a well known fact
that computer scientists always pick passwords consisting
of their birthday or girlfriend's name. Making it
computationally difficult and slow also meant any serious
attempt to try random passwords would be extremely
obvious, and that the phone line could be traced before any
significant risk would be incurred.
Now that Unix machines are cheap, big, fast, and have high
speed networks with poor to nonexistant monitoring tools,
all of the reasoning behind the "Unix algorithm" is gone.
It's not useful to know which secretaries share a
computer; novice users (perhaps because they don't assume
they know it all) select *much* better passwords, and
better networks & computers make intrusion attempts
practically invisible and approaching microscopic.
In fact, except in rare cases, I think [EMAIL PROTECTED]'s
approach (2) is the correct one (help the user upon login as much
as possible), and I do not think any place that holds with (1) should
be running anything nearly as insecure as Kerberos. The value of
Kerberos is not in its security which, while good, is not perfect.
In fact, kerberos 4 has a number of well-known short-comings,
and DES, upon which it's based, is still the subject of serious debate
on its validity, besides being subject to unfortunate rsetrictions by
the US Commerce Department. The real value is in the public interoperability;
that software from many places can work together using kerberos, that
the algorithms and source are public and freely available, and that it
can be used at a large site with many many users to share information
in a relatively secure fashion.
Any site that is truely security conscious will not want to
deal with nearly so many users in the first place (security risks
generally go up very steeply as #of users increases),
and probably won't be nearly so interested in running PD
software, without a fairly lengthy review process first.
If such a site ran AFS at all, I think they might either
want to run it only inside on a special network insulated
>From the real world, relying on the network to provide
the security, and/or, given the proven independence of
most of AFS from udp or RX based kerberos, might implement
their own separate proprietary security system, and
use that to issue and distribute AFS tokens. There
are a number of other improved security systems that
would make perfect sense for such installations. Switching
security systems is not nearly sufficient here however,
such a site would need to review many parts of its operation,
and of its use of AFS. E-Mail, especially with the outside world,
would almost surely be incompatible with this sort of site;
pts entries might need different protection, perhaps nothing
in AFS should be available without authentication; certainly all
workstations would need proper physical security, restrictive
gateways or an entirely isolated network might make sense,
perhaps security guards, id badges, or gas pressurized network
links would be needed, tape backup security, proper destruction
of used tapes & printouts, hiring practices for employeers, etc...
Such a system is only as good as its weakest link; and there
aren't any easy short-cuts here.
In most installations, the risk just doesn't justify these
kinds of measures, and the real value of most systems is
in the use people make of them. Here at the UofM, somebody
has to deal with educating users on the system,
distributing identities on the system, dealing with password
resets, provide e-mail to users, provide lookup services so
users can find each other, troubleshoot problems as they
arise in workstations, networks, and the server, and so on.
These all have costs & benefits, and security is just one more
minor factor in the whole mess. Kerberos is an attractive
underlying solution to one part of the problem; saying "incorrect
user" vs. "incorrect password" is another, and if it
even occasionally saves a consultant's time in running "maX.500"
to discover the same thing, it's worth it.
-Marcus Watts
UM ITD RS Umich Systems Group
