Subject: [netatalk-admins] Information on other authentications

From: Kent Reuber <[email-masked]>
Date: Tue, 20 Apr 1999 17:38:59 -0700

I am running Netatalk 1.4b2+asun. I'd like to enable a more secure login
than cleartext. The afpd.conf file alludes to a kerberos 4, randnum, and
rand2num methods.

I am running Netatalk on my Linux box (RedHat 5.1). I am also running a
Kerberos server (for secure telnet sessions) as well. Kerberos would be
preferable, but I'm not sure how well the Umich Kerberos authentication UAM
will work with MacLeland, the Kerberos client we use at Stanford. Any
suggestions here would be welcome.

The randnum methods would also be better than what I'm running now. When I
enable random number authentication in afpd.conf and restart afpd, the
Chooser login method says two way encryption" but my login is denied.

Pointers to documentation would be very welcome.

Kent
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Kent Reuber ([email-masked])              Phone (650)725-8092
Customer Assistance                                    Fax (650) 725-0995
Information Technology Systems & Services  215 Panama St., Bldg A (Birch)
Stanford University                               Stanford, CA 94305-4128
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

---

From: "Alex Yu" <[email-masked]>
Date: Tue, 20 Apr 1999 20:48:06 -0400

> The randnum methods would also be better than what I'm running

You need to have a .passwd (cleartext password, no longer than 8 characters,
no character return key) in ~ directory.

Alex

---

From: Jim Zajkowski <[email-masked]>
Date: Tue, 20 Apr 1999 20:52:04 -0400 (EDT)

On Tue, 20 Apr 1999, Kent Reuber wrote:

} Chooser login method says two way encryption" but my login is denied.

You need to create a ".passwd" file with your *cleartext* password in it,
chmod'd 0600, in your home directory.  Note that it doesn't need to be
your real password; I use a different password for netatalk than my
system password.

Jim

---

From: "Alex Yu" <[email-masked]>
Date: Tue, 20 Apr 1999 20:57:02 -0400

> You need to create a ".passwd" file with your *cleartext*

I think we really need to find a way that don't require a cleartext .passwd.
I mean.... what's the point by using two way encryption if .passwd is a
cleartext passwd?

Alex

---

From: Jim Zajkowski <[email-masked]>
Date: Wed, 21 Apr 1999 00:53:19 -0400 (EDT)

On Tue, 20 Apr 1999, Alex Yu wrote:

} I think we really need to find a way that don't require a cleartext .passwd.
} I mean.... what's the point by using two way encryption if .passwd is a
} cleartext passwd?

>From the fetchmail Design Notes, which answers this question:

 --- 8< ---
The reason there's no facility to store passwords encrypted in the
.fetchmailrc file is because this doesn't actually add protection.

Anyone who's acquired the 0600 permissions needed to read your
.fetchmailrc file will be able to run fetchmail as you anyway -- and if
it's your password they're after, they'd be able to rip the necessary
decoder out of the fetchmail code itself to get it.

All .fetchmailrc encryption would do is give a false sense of security to
people who don't think very hard.
 --- 8< ---

Jim

---

From: Michael Han <[email-masked]>
Date: Tue, 20 Apr 1999 23:18:42 -0700

Previously...
>[Thank you, I think I will snip it]
> --- 8< ---

I think Alex is trying to point out that there's something wrong with
rand2num *itself*. And if he wasn't, I'd sure like to make the same
assertion. rand2num is potentially better than cleartext, but still
doesn't work the way I tend to think about password encryption. A
hashed password should be sent, which is compared to the same which is
stored on the server. That way a root compromise of the server doesn't
compromise all the user passwords on the box. And root can't casually
be grabbing user passwords either.

fetchmail is a client, and hence, for it to work in an automagic
fashion, it needs your password. afpd is a server and shouldn't need
to know anyone's password. Only if the password provided is authentic.

The real question is if anyone feels like trying to write a 'crypt'
uam or something like that. I think there's a need, personally. I
suppose there's a new kerberos UAM in the works, too.
-- 
[email-masked]
I will not prescribe medication
 - The collected wisdom of Bart Simpson

---

From: "Alex Yu" <[email-masked]>
Date: Wed, 21 Apr 1999 02:21:49 -0400

> From the fetchmail Design Notes, which answers this question:

I think what I am trying to say is JUST to use one set of password.

Alex

---

From: Michael Han <[email-masked]>
Date: Tue, 20 Apr 1999 23:27:40 -0700

Previously...
>suggestions here would be welcome.

Mmm, Umich's kerberos UAM currently doesn't support AFP on TCP, so if
you were hoping to get snappy AFP on TCP performance, you can't
kerberize your afpd. This is actually caused by the AppleShare Client
on the Mac having a different interface for third-party UAMs.
Documentation for this interface was pretty slow about getting
available... I hear the UAM is being reworked to support new nifty
things like kerberized afpd's on TCP.
-- 
[email-masked]
I did not see Elvis
 - The collected wisdom of Bart Simpson

---

From: [email-masked]
Date: Wed, 21 Apr 1999 10:36:01 -0400

> From:    Kent Reuber <[email-masked]>
> To:      [email-masked]

> suggestions here would be welcome.

The AuthManUAM will probably work fine with "MacLeland", since I
understand that it's Kerberos IV support is just AuthMan repackaged.
However, AuthManUAM is not compatible with AppleShare 3.8.1, i.e. the
version that supports AFP/TCP.  We'll release a version of AuthManUAM
before WWDC, which starts 10 May.

:wes

---

From: Osma Ahvenlampi <[email-masked]>
Date: 21 Apr 1999 14:26:38 +0300

> be grabbing user passwords either.

It's not that simple.

UNIX crypt() passwords are stored hashed, but the login is done by
getting a plaintext password, hashing it, and comparing it to the
stored hash. The server application did get to see the password, and
in most cases it also passed over a wire in unencrypted form.

AppleShare randnum stores a plaintext password on the server and
passes challenge/response on the wire to verify that both ends have
the same password. Windows NT encrypted passwords are stored on the
server as hash values, but that doesn't matter - the hash value is a
plaintext equivalent and with a modified client, knowing the hash is
sufficient for login.

There is no easy solution for having passwords stored in encrypted
form AND sending them over the wire encrypted. One way is to encrypt
the entire authentication or even service channel and use UNIX crypt()
style passwords within the channel - you're still telling the server
application the actual password though, only no one can listen in on
the conversation. Another is to use public-key cryptographic
authentication, but that requires the user to carry a smart card with
them or to remember a 1024-bit (300-number) secret value. Yet another
solution is to use one-time passwords, which again requires the user
to carry along a smart card-like device or a list of future passwords
printed on a piece of paper.

-- 
Osma Ahvenlampi

---

From: a sun <[email-masked]>
Date: Wed, 21 Apr 1999 01:04:30 -0700 (PDT)

umm, i guess i should shed some light on this as people don't seem to
have read the relevant sections in inside appletalk. for randnum and
2-way randnum to work, the server needs to know your
password. checking against /etc/passwd isn't good enough as that's a
1-way hash with the real password unextractable. in the future, better
ways of dealing with passwords will be available as netatalk will have
a more pluggable uam architecture. currently, however, that's not the
case.

if you aren't sure why randnum and 2-way randnum need server knowledge
of your password, i'll give you some hints:
	"randnum" stands for encrypted randum number
  "2-way randnum" stands for 2-way encrypted randum numbers

now, ask yourself how do you do verification when all you're doing is
sending and receiving encrypted random numbers?

-a

---

From: Michael Han <[email-masked]>
Date: Wed, 21 Apr 1999 10:23:48 -0700

Previously...
>> be grabbing user passwords either.

Of course not.

>plaintext equivalent and with a modified client, knowing the hash is

This is stuff I would hope we all knew already. But all in all, I
think most people would feel more comfortable with cleartext
tranmission and hashed storage, rather than hashed transmission and
cleartext storage... I could be wrong, but that's my take on things.
There are *definitely* better ways to do things than either of the
above, but I really wasn't trying to talk about that...
-- 
[email-masked]
I did not see Elvis
 - The collected wisdom of Bart Simpson

---

From: Jim Zajkowski <[email-masked]>
Date: Wed, 21 Apr 1999 17:06:52 -0400 (EDT)

On Tue, 20 Apr 1999, Michael Han wrote:

} And root can't casually be grabbing user passwords either.

So?  root can just "su mikehan" and *blam* he's mikehan.  Doesn't need a
password.

Jim

---

From: "Espen H. Koht" <[email-masked]>
Date: Wed, 21 Apr 1999 23:26:18 +0100 (BST)

> cleartext storage... I could be wrong, but that's my take on things.

Count me out. I consider it my responsibility to keep my system as secure
as possible, and prefer basing my system around that goal, rather than
worrying about whether everybody else around me are able to keep their
systems secure or not. 

The moment my system is insecure, its only a marginal difference to a
cracker whether the passwords are stored hashed or not, if they can then
sniff the network. 

If my system is secure, I'd rather that my passwords aren't sniffed from
someones elses insecure system.

Ideally, there would be good third option which would eliminate having to
make such choices of course.

Espen

---

From: "Alex Yu" <[email-masked]>
Date: Wed, 21 Apr 1999 22:40:29 -0400

> Count me out. I consider it my responsibility to keep my

well... this is the way i look in this problem.  if there is always a chance
that ppl will sniff your network, and you have to run a ftp server without
any auth, such as ssl or skey due to lack of multi-platforms ftp
applications that supports skey/ssl/sftp, then what's the point to use 2-way
encryption in netatalk?

maybe you say that people should be smart enough to use 2 seperate
passwords, but guess what, they don't.  no ppl like to remember 2 or more
complex passwords.  this is just how it goes.  what happen if you force your
boss to remember 2 seperate passwords?

i don't really like to have a cleartext password idea...  i mean, system
administrator or IT professionals shouldn't do such thing.  if you are
talking about to admin a 100+ employees company....  just be careful that
people might sue you because you take away their privacy.

alex

---

From: Michael Han <[email-masked]>
Date: Wed, 21 Apr 1999 23:08:28 -0700

Previously...
>So?  root can just "su mikehan" and *blam* he's mikehan.  Doesn't need a

Right, but in a lot of (admittedly ill-advised) cases, if root knows
[email-masked]'s password, *blam* he's also [email-masked],
[email-masked]. Not to mention, *blam* he's authentic ATM
card-holder mikehan. It's not a good idea to set oneself up for this
password cascade, but most do.

Meanwhile, I'm off to register some domain names ;-)
-- 
[email-masked]
No one is interested in my underpants
 - The collected wisdom of Bart Simpson

---

From: David Winkel <[email-masked]>
Date: Thu, 22 Apr 1999 10:12:29 -0400 (EDT)

Interesting that root can't grap passwords...  It seems like it wouldn't
be that difficult to find a hacked copy of in.telnetd and/or in.ftpd that
just stores passwords in a file as well as authenticating people.  Then,
as root, just replace the stock ones with hacked ones, and collect
passwords like that.  If you're root, you can do anything, including
collect passwords.  (For that matter, on solaris 2.x, truss -fp of inetd
will give you passwords, if you're smart enough to interpret the output.)

If root is compromised, it's a fair bet that most of the accounts on the
machine can be compromised, given a competent enough hacker, and enough
time.

> Meanwhile, I'm off to register some domain names ;-)

 ~~~~
           [email-masked]               UofM/ITD Web Services
                      University of Michigan Webmaster

  I'm not comfortable dropping the Services out of Web Services Production.

---

From: Everette Allen <[email-masked]>
Date: Thu, 22 Apr 1999 11:32:31 -0400

Nice try wes but no cookie.  I have tried many times to get authman uam
to work with MacLeland.
It will not.  When andy maas wrote macleland he used parts of Authman as
a template (and some libs) but he redid most of it to fit the Stanford
"athena" model (ie hesiod support, etc).  Since authman, kclient, and
macleland do not appear to cache V4 tickets in a compatible way they
won't work (at lease for me in a mixed MIT/AFS environment).  One could
run netatalk 1.3.3 on RedHat and use macleland native but there is no
ASIP support and several bugs fixed in 1.4bx of netatalk.
Just as Wes is working to release new uam for authman, we here at NC
State have been working on a version of a uam which will work with
KClient API from MIT and with Stanford's 1.3.3 patches and asun's AFP
over TCP/IP patches.  This could work with KClientLeland (and KClientMan
too)except it needs an update to latest KClient api(the keeper is Simon
Andersson at Stanford).  Look for this with its source code to go public
domain some time early June 1999.  We have tested on linux ppc and i386
but solaris 2.6 is our target deployment.

-- 
Everette Gray Allen                               Consultant IV
Box 7109 NCState Campus                     Computing Services
Raleigh, NC 27695-7109                       919-515-2517

---

From: William Uther <[email-masked]>
Date: Sun, 16 May 1999 12:55:16 -0400

Hi,
  Did the new AuthManUAM get released yet?

  By the way, the AuthMan/AuthManUAM link on the netatalk page is old.
(i.e. on the page <http://www.umich.edu/~rsug/netatalk/obtaining.html>
there is a link to
<ftp://terminator.rs.itd.umich.edu/mac/AuthMan/AuthMan%201.0.9A.sea.bin>
which no longer exists.  It should probably be replaced with a link to
<http://www.umich.edu/~rsug/authman/>.)

\x/ill         :-}

---

From: [email-masked]
Date: Sun, 16 May 1999 14:34:11 -0400

> From:    William Uther <[email-masked]>
> To:      [email-masked]

> Did the new AuthManUAM get released yet?

Not yet.  We have to replace all the DebugStr()'s with proper alerts.
We've made changes to asun's release to support this version, and since
we're currently in San Jose, we haven't been able to test it against an
AppleTalk-only afpd, just TCP so far.  Expect something sometime next
week.

> By the way, the AuthMan/AuthManUAM link on the netatalk page is old.

Thanks.

:wes