7 Nov
2018
7 Nov
'18
1:35 a.m.
On 11/06/2018 03:24 PM, Dan Cross wrote:
Isn't that authorization?
Not really.
Authentication is proving that you are who you claim to be. - Show
your drivers license to the bouncer.
Authorization is deciding if the authenticated entity is allowed to have
access or not. - Is your name on the list of people allowed into the
nightclub?
Access Control - The bouncer, allowing you in or physically barring you
from entering.
Each is a discrete function. They all work in close concert with each
other.
Not really. It provides the data that lets one perform
a relatively weak
validation of e.g. a password, but it is not *itself* an authentication
protocol.
Fair enough.
Older versions of Kerberos often included modified
versions of popular
servers and their clients that had been modified to use the kerberos
protocol for authentication, and also often to encrypt communications.
I take it that you mean that the Kerberos software that was distributed
also included an alternate telnet / rsh / etc daemon that took advantage
of Kerberos.
For example, the version of `telnet` that shipped with
MIT kerberos back
in the day had an option that could be used to encrypt the data stream;
similarly with rlogin, et al.
*nod*
I have a dim memory that the version of FTP might
support encryption
for the control connection but not data connections (but I also might be
purely imagining that).
Maybe. There has been a LOT of energy put into FTP.
I'm guessing most of this stuff has been dropped
from more recent
distributions
Likely.
because...really...telnet?
~chuckle~
I supported multiple old Solaris 6 machines about 5 years ago that I
still had to use telnet to connect to.
I feel like telnet as a service REALLY does need to go away. That being
said, I still find the telnet (or any NVT) client a valuable diagnostic
tool.
What I meant is that SSH supports a limited sense of
checking whether
a given key matches and making a yea or nay decision based on that.
I'm not sure I understand what you're alluding to. But that's getting
off topic. So I digress.
Correct. `ypcat passwd` often gave you a bunch of
hashed passwords in
field two of a stream 7th Edition /etc/passwd formatted entries.
I would have hoped that there would have been some intelligence to only
return the record of the person requesting the information. Or that the
password field was redacted for other users.
I guess the ypcat binary could be augmented to do that filtering client
side. But that still leaves the underlying problem there for alternate
NIS clients.
I have, again, some vague memory that at some point
this was changed so
that root on the localhost could get a shadow-style map, but normal users
couldn't see the password hashes. But I might totally be making that up,
and of course, it wasn't robust security since what went over the wire
wasn't encrypted and breaking root on a host could still get you all
the hashes on the network.
It's still subject to alternate ypcat impersonation binaries too.
Contrast with Kerberos, where breaking root on a host
doesn't compromise
much beyond that host (modulo leveraging that to steal user passwords
and the like).
ACK
Ha! That's a hoot.
;-)
--
Grant. . . .
unix || die