Subject: Re: [netatalk-admins] shared Logins on UNIX/Mac?

From: [email-masked] (William P. McGonigle)
Date: 10 Aug 98 14:46:15 EDT

For clarification, Michael is looking for both client-side and server-side NIS
UAM's.

The client-side UAM might be out there, but I wouldn't expect a server-side one
until after ASIP 6 has been out for a little while.

I haven't seen any myself, but I think it's a great idea.  Then again, I was
gung-ho for the full DCE suite in Copland...

-Bill

---

From: Oliver Wrede <[email-masked]>
Date: Tue, 11 Aug 1998 12:40:05 +0000

First, I thank all of you who replied to my request.

I found a workaround, which seems very promising:

MacLogin

http://users.ccnet.com/~kiberkli/maclogin/about-maclogin.html

I saw this on the page

http://www.umich.edu/~rsug/netatalk/links.html
following a remark from Michael Han.

Especially the hint upon clear-text passwords in MacOS was very new
to me. I always trusted those MacOS admins who claimed that MacOS
is much more secure than UNIX systems...

Are there any paket sniffers out there already wich grab the
AppleShare passwords from the TCP/IP network (or even from the
DDP layer?)

Michael Han asked:

>Yes, a bit off-topic, then. Is there some reason you're particularly
>attached to running a true AppleShare server (I acknowledge there
>*are* good reasons)

We have a lab enviroment with mainly MacOS and some NT machines. The
UNIX-Server does all the Internet stuff and serves als Fileserver
for the User-spaces.

We just have 2 new machines for serving.  Our staff is somewhat split into
contra-heterogenous and pro-heterogenous admins. Due to lack of experience
with MacOS-servers and UNIX in Mac-enviroments as well, we can't solve this
without keeping both doors open.

Samba is going to be able to represent a full featured NT server soon,
and so our first idea was to have Linux serve as authentificator for all
machines in our department using the same usernames and Logins for
everything. Netatalk plays the same role in this game like Samba does. And
because we already use NIS for sharing logins, I naturally thought a NIS
client for Mac would do the trick.

I am pretty sure we will have AppleShare IP 6.0 when it is available.
I personally did not have a chance for a closer look on it. Everything I
heard sounded good. Does anybody of you participate in the Beta-program?

But especially the very good performance of Netatalk (thanks to all of you
who did this good piece!!) is a reason why our Mac-believers had to rethink
some of their arguments.

Oliver

. Oliver Wrede . . . . . . . . . . . . . . . . . . . [email-masked] .
. tel. +49 2203 913 200 .  office +49 221 9522 601 . fax +49 221 9522 605  .
. School of Design, University of Applied Science, Cologne . . . . . . . . .
. www.ds.fh-koeln.de/~owrede . . . . . . . . . . . . ICQ# 6580315  . . . . .

---

From: Michael M Han <[email-masked]>
Date: Tue, 11 Aug 1998 09:10:53 -0700

Previously...
>MacLogin

*THAT'S* what you were trying to do? ah... Check out Apple Network
Administrator's Toolkit 2.0, too. It's more expensive, but it appears
to be a much more robust approach than MacLogin.

>[snip]

That's a laugh. MacOS more secure than UNIX. Pretty much every UNIX is
minimally C2-classified (US Dept. of Defense rates OS security), as is
NT and Netware. MacOS has never been tested and won't be until OS X
Server at the soonest, because all MacOSes I've ever seen wouldn't
even merit a rating...

But in more technical terms, the MacOS-native encryption for passwords
requires that the server know the *clear-text* form of the password.
This is distinct from Unix or NT which one-way *hash* the password.
When they receive passwords, they first hash them and then compare
them to the stored value. MacOS may not in fact store clear-text
passwords; it may encrypt them. But it would have to be a two-way
encryption, meaning that it would be trivial to decrypt the passwords.
A sufficiently large key and good implementation would thwart such
attempts, but that would bring on questions of US Export laws
regarding encryption. I've never actually seen this stated from an
authoratative source, but this is a conclusion I reach based on
information that's readily available.

>AppleShare passwords from the TCP/IP network (or even from the

This can't be done. MacOS *does* encrypt passwords while they're on
the wire. It uses what they call RandNum which involves the exchange
of a random number which is hashed using the password as a key. The
same passwords will hash the randnum identically. I expect that
RandNum would be reasonably hard to compromise, though I've never
really thought very hard about it.
_________
mike ([email-masked])
I will not charge admission to the bathroom
 - The collected wisdom of Bart Simpson

---

From: Tony Stuckey <[email-masked]>
Date: Tue, 11 Aug 1998 12:10:50 -0500 (CDT)

> Server at the soonest, because all MacOSes I've ever seen wouldn't

	If you don't have physical access to the machine, MacOS is quite
secure.  You can run a MacOS web server or file server on the general
internet without worry.  Most unix systems run too many services to say 
the same thing.
	Under both unix and MacOS, it is usually the service, rather than
the kernel, which is broken into via the net.
	Also, the lack of a shell-style program on the Macintosh implies
that it would be harder to take advantage of a break-in.
-- 
Anthony J. Stuckey                              [email-masked]
"When I was young, the sky was full of stars.
 I watched them burn out one by one."  -Warren Zevon

---

From: Casey Bisson <[email-masked]>
Date: Tue, 11 Aug 1998 13:24:46 -0400

Please don't think that I'm trying to start a flame war, or veer too far off
topic...

>From my understanding, the US Dept. of Defense rates single computer
installations, not OSs. The ratings refer primarily to the isolation of users and
data in a multiuser system, and to network security. As the MacOS is not
multiuser, it would not be considered. However, it's security to attack from the
network is considered better than many other OSs (though I will concede that no
Mac runs as many network services as most unix boxes).

The anti-Microsoft plug of the day is that the security rating for the NT
installation was done with no networking, with networking it failed.

Casey Bisson
Information Technology
Plymouth State College

---

From: Osma Ahvenlampi <[email-masked]>
Date: 12 Aug 1998 16:25:39 +0300

> NT and Netware. MacOS has never been tested and won't be until OS X

You can't DoD certify "UNIX". C2 certification only applies to
specific configurations right down to exact hardware make and model,
installed extra hardware, and the programs installed on the system.

NT 3.51 on a Compaq Proliant server (forget which one, but an old one)
is indeed C2 certified when not equipped with networking hardware. I
doubt there's much else off-the-shelf operating system software that
is (but I'm sure you can special-order such configurations from Sun or
Hewlett-Packard).

MacOS is sometimes called more secure than UNIX simply because it is
not a multi-user system, and offers no TCP/IP network services. On the
other hand, most UNIX installations offer a whole slew of them, all
enabled by default, and in unqualified hands, a UNIX system is very
difficult to keep secure. That's the price you pay for its
versatility. On the other hand, if you're actually looking for
something that can serve a network, and are able to configure all
parts of it correctly, well, MacOS won't do it.

> When they receive passwords, they first hash them and then compare

This isn't quite true either. Perhaps a MacOS server does need to
store passwords in clear-text to avoid transmitting them over the
network (although I don't understand why that helps). UNIX passwords
are stored as one-way hash strings, and the server doesn't know the
real password. Comparison is done by hashing the incoming password and
seeing if the hashes match.

NT encrypted network passwords, on the other hand, _are_ hashed on
disk and not transmitted in the clear over the network. Unfortunately,
due to the authentication algorithm, the on-disk hash checksum of the
password is functionally equivalent to the clear-text password - if
you can get your hands on it, and if you can use modified client
software, you don't have to know the original clear-text password at
all. Guess why the password file is one of the strongest-protected
files in the NT registry..

In short: MacOS security, if the description above is correct, relies
on the server being uncompromised and the password file safe. NT
security depends on the same thing, adding some extra technical
difficulties to the would-be-cracker (but technical difficulties can
be overcome, and these aren't that difficult to overcome). UNIX
password security, on the other hand, is not necessarily compromised
if the password file is stolen (if all passwords in it are good, the
only feasible attack, the brute-force dictionary search, is not
feasible). It does, however, transmit passwords in cleartext, so it
really isn't good for anything but console logins or strongly
encrypted session protocols (like ssh, IMAP over SSL, or similar).

> attempts, but that would bring on questions of US Export laws

No two-way encryption scheme would help, because the decoding key
would have to be known by the server, and would be compromised along
with the password file itself. No shared-secret handshake (like the NT
authentication) is safe either, unless the passwords are one-time use
only (see S/KEY by Bellcore, or the equivalent algorithm described in
RFC 2289). Public-key authentication works, but requires that the user
carries her secret key with her in safe storage (the iButton, as
featured on the JavaRings, would be a good solution for that - see
www.ibutton.com).

Authentication isn't easy. ;)

> of a random number which is hashed using the password as a key. The

Sounds like the NT authentication, and has the same drawbacks.

-- 
Ideas "off the top of the head" are like dandruff -- small and flaky.
Osma Ahvenlampi <[email-masked]>

---

From: Jonathan Benson <[email-masked]>
Date: Wed, 12 Aug 1998 10:00:47 +1000

> really thought very hard about it.

This can in fact be done.  I had a user here who had a program that
allowed him to see the passwords people were using to connect to file
shares on the various Macs in here.   I forget the details as he was
someone I could trust and has since left.

Jonathan

--
Jonathan Benson B.Eng. (Soft Sys Hon) <[email-masked]>
Systems Administrator, Phoenix Magazines, Phone: +61 3 9696 7200
http://www.phoenixmags.com.au

---

From: Will Cox <[email-masked]>
Date: Wed, 12 Aug 1998 11:06:05 -0400 (EDT)

<TANGENT> 
I don't think a discussion of NT's (or UN*X's) security foibles
is quite appropriate to this thread, but for argument's sake :-) 

The C2 rating is for 3.5 on a particular hardware platform, and has not
been maintained, so does not apply to 3.51 or 4.0, or to any other
hardware platform. 

http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-95-003.html
</TANGENT>

I checked out the MacLogin UAM, and since the documentation's in MS Word,
don't think I'll end up using it. However, from the readme and description
on the web site, it doesn't appear to suit my purposes for a centralized
authentication source for both Apple ASIP and Linux netatalk user/pass
combinations.

Perhaps pam_ldap

http://anath.gmp.usyd.edu.au/pam_ldap/
ftp://anath.gmp.usyd.edu.au/pub/pam_ldap/pam_ldap-0.04.tar.gz

could work on the Linux side of things, provided you can authenticate or
sync the LDAP user/pass with ASIP.

There're are two LDAP directories coming out for Mac OS that purport to
store user account information for AppleShare/IP, but I've not worked with
the betas enough to know if they store user/pass combinations as well as
mail information. There's also discussion of this topic on the
appleshareip-list. 

http://www.oneclick.com/server/specs.html
http://www.cesoft.com/quickmail/dirsys/mds.html
http://www.lists.apple.com/appleshareip.html

On the other hand, the password in most LDAP directories is stored and
passed over the wire in the clear (unless SSL is used, in which case it's
only stored in the clear). The only exception to this that I know of is
the Lotus Domino directory, which stores the password as a hash (but
that causes problems using the Domino directory for authentication to
non-Domino hosts).

/cwc

---

From: Osma Ahvenlampi <[email-masked]>
Date: 13 Aug 1998 01:10:32 +0300

> only stored in the clear). The only exception to this that I know of is

Netscape Directory Server stores passwords as UNIX crypt() or SHA hash
values. Similar patches are available for UMich slapd as well. Both
still expect the password to be sent in the clear.

In fact, the support in these requires that you store the password has
hash string in the form "{crypt}e3HTnV/p4DaC.", and will then be able
to compare the password given in the bind request to the hash
value. So it does require specific support from the client software
used to set the password, but not from clients which simply try to
bind using a predetermined password.

-- 
Drilling for oil is boring. 
Osma Ahvenlampi <[email-masked]>

---

From: Bill Studenmund <[email-masked]>
Date: Sat, 12 Sep 1998 10:04:11 -0700 (PDT)

> someone I could trust and has since left.

What kind of file servers were they? Specifically, if the login screen
said the password was "2 way encrypted" and you were able to read it, then
you should have informed Apple - that'd be big news. If, however, the
login said the password was "Clear Text," well, you just learned the
definition of clear text. ;-)

Stealling clear text passwrods w/ a sniffer should be trivial. The one
protection would be that most cracker sniffing programs won't be looking
for them. The ones we've seen look at specific IP protocols.

Take care,

Bill