Subject: [netatalk-admins] Using 2-way encrypted password

From: Alex Yu <[email-masked]>
Date: Thu, 04 Mar 1999 19:35:44 -0500

Hello,

I need help on using 2-way encrypted password.  I installed des before I
compiled and install netatalk (lastest version).  Then I edited afpd.conf
with -rand2num.  My question is why it doesn't work?  I tried
login/changepasswd with cleartxt.  It works very well.  I need to enable
2-way encrypted password but why it just doesn't work?  I mean, it keep
telling me that my password is incorrect.  Would someone help me out?

I have 2 more questions.  Why netatalk only display "server" as an info
string on Chooser?  I tried apfd with option -n, but it still display
server as an info string.  Also, how can I force a machine with netatalk to
be in a zoon?

Thanks for your help.

Alex

---

From: Alex Yu <[email-masked]>
Date: Thu, 04 Mar 1999 21:40:39 -0500

Hello,

Mar  4 21:41:05 test afpd[2362]: randnum/rand2num login: test
Mar  4 21:41:05 test afpd[2362]: Failed to open /home/test/.passwd
Mar  4 21:41:05 test afpd[2362]: 0.07KB read, 0.05KB written
Mar  4 21:41:05 test afpd[2359]: server_child[1] 2362 done

This is the log I got.  Is .passwd a plain text file or?  How can I use
/etc/passwd as password?  How ~/.passwd work with /etc/passwd?  Please help!

Alex

---

From: Thornton Prime <[email-masked]>
Date: Thu, 4 Mar 1999 18:54:59 -0800 (PST)

> /etc/passwd as password?  How ~/.passwd work with /etc/passwd?  Please help!

Plain text. Don't even put in a CR after the password. Make sure
permissions are so that no one can rwx.

thornton

---

From: Alex Yu <[email-masked]>
Date: Thu, 04 Mar 1999 22:19:11 -0500

>permissions are so that no one can rwx.

I just found out that atalk uses its own passwd for rand2num (2-way encryed
password).  I would like to know how can I use /etc/passwd | shadow as my
main passwd?  Many users do not want to use 2 different passwds or to
change passwd twice if they need to.  Because security issue, I have to
disable ssh/telnet for local users, so I want to be able to let them to
change their passwd throug AppleTalk and it will auto update the main
/etc/passwd | shadow.  Please help!

Alex

---

From: PayPC System Mail Subscriber <[email-masked]>
Date: Fri, 5 Mar 1999 18:45:09 +1000

Alex Yu said in Re: [netatalk-admins] ~/.passwd at 05/Mar/1999 (Fri) 13:19:11.

> /etc/passwd | shadow.  Please help!

Alex, because the etc/shadow password is a salted one-way hash done with an 
algorithm very different from Appleshare's, there's no way for the 
2way-randnum method to check against the /etc/shadow passwords.

So therefore, you must have a "look-aside" password (the samba folks have to 
do this also to support encrypted logins from NT systems)...  Adrian's method 
is OK...  however I *****STRONGLY***** advise the following:

*FORCE* all of your users to keep DIFFERENT passwords in their .passwd from 
their normal UNIX one.  At the moment, my userbase is intelligent [no 
management or salesdroids yet] so I don't need to police them, however, it 
would be easy to write a passwd (UNIX-side) filter that would check ~/.passwd 
and disallow passwords that match their Appleshare ones.

This is prudent because of this in-the-clear password... even IF that file 
were compromised, all the person could do is login via AppleTalk... if your 
network is like mine, I use TCP Wrappers *and* firewalls to disallow all but 
LOCAL network logins for Appleshare and SAMBA services.... so an outsider to 
my net gets NOTHING if he discovers the .passwd file's contents.  They have 
to be on a MACINTOSH that's within my local network to do any mischief at 
all, and even then, it's going to be limited to just what they can get at via 
netatalk.

So because of all of the above, I find the .passwd cleartext issue to be an 
acceptable solution.  There *IS* one bad thing about it, though.  It allows 
"evil" superusers to be able to silently harvest passwords [yes, they have 
unfettered access to everything, *but* they might be able to use those 
passwords on other systems where they may NOT be superusers or even allowed 
access at all]...  since I'm the sole BOFH on my net, this is not a worry [I 
don't do it]... but in larger and more politically infested organisations, 
this might be.

Of course, in the end security becomes more an issue of POLICIES more than 
technology in the long run....  requiring each major service to have unique 
passwords for your users is the best way to contain security breaches.  
Nothing is worse than the Happy-Happy NT model where one password opens up a 
world of access.

=Rob=