Subject: Re: 1.99gb window limit
From: Steve Freitas (sflist@ihonk.com)
Date: Tue Oct 03 2000 - 15:23:32 EDT
>DHX just requires MacOS 9, or 8.1-8.6 with Appleshare Client 3.8.5(?) or
>later.
>
>> - -transall -uamlist uams_guest.so,uams_randnum.so -nosavepassword
>>
>> would be better, so long as you have OpenSSL installed (the RPM's
>> dependencies seem to take care of that anyway). 2-way encrypted passwords
>> just work out of the box.
>
>Not really out of the box, randnum requires plain text passwords on the
>server. It's basically a server side vs. client side configuration issue.
>I personally would rather not have plain text passwords on the server.
I would *strongly* suggest that DHX via PAM is the default, for the
following reasons:
1. It works out-of-the-box with Mac OS 8.1 and up. I think this is
sufficiently inclusive for a default config.
2. It's secure out-of-the-box because passwords do not reside in
unencrypted form (e.g. ASCII *or* hexadecimal) on the server.
3. It works out-of-the-box, because a Netatalk newbie doesn't have to go
adding user accounts (via afppasswd) or setting up .passwd files in
individual directories before s/he can login. Let's face it -- a lot of
Netatalk admins are going to have lower *nix skills because of their
history with the Mac's ease of use. If we can make this a matter of "rpm
-i netatalk1.5.0.i386.rpm ; /etc/rc.d/init.d/atalk start", that will help
it be more widely adopted.
Randnum, while it permits pre-8.1 clients to login without any additional
effort, won't work out of the box because it requires a lot more admin
setup work, uses insecure passwords on the server, and requires more
maintenance. "What is an admin good for but to work?" you might
reasonably ask. Well, when the tradeoff for all the ease and security of
DHX via PAM is simply that pre-8.1 clients need an AppleShare client
upgrade, I don't agree that randnum provides sufficient value in enough
situations to warrant being the default behavior.
Plus, I can't harp on the security issue enough. Too many projects give a
backwards glance to security on their way to release -- let's make this
as secure as possible by default. If people want to open up potential
holes, let them do it by hand.
Steve
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:32:17 EST