[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] Web interface for POP3
- Subject: Re: [cobalt-users] Web interface for POP3
- From: "Steve Werby" <steve-lists@xxxxxxxxxxxx>
- Date: Tue May 29 08:25:15 2001
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
"Zarrir Junior" <zarrir@xxxxxxxxxxxx> wrote:
> Thanks Steve,
>
> I had thought about the second alternative but this service is run
> on about 50 virtual sites and i have other 200 that would be off line
> because of that.
That's too bad, it was worth mentioning just in case. I've been thinking
about your situation and I've thought of another option. I haven't hacked
qpopper, but I figured there had to be a way have it authenticate against a
file other than /etc/passwd so I looked on Eudora's qpopper site and found
this URL - http://www.eudora.com/qpopper/faq.html#password_files. It sounds
like you have to recompile PAM to build a new module for POP authentication.
See http://www.kernel.org/pub/linux/libs/pam/. If you can get that to work
it would be fairly trivial to build a PHP (or Perl or your favorite
scripting language) script called from cron to parse /etc/passwd regularly
and generate a version of the file listing users who are allowed to access
POP via port 110 from anywhere they want. Then you could either run POP on
another port (you won't publicize) for your webmail to access. You could
also optionally repeat the process to creat a new PAM module for the webmail
users, based on cryptic usernames you generate using some method and which
you modify Rymo to use internally based on a file/db that maps whatever user
login info. you have your users supply to the username that PAM is
expecting.
> Rymo is written in Php but i´m pretty newbie in Linux in order to
> mess with MySQL or cryptic usernames. Anyway , it is the best idea. I´ll
try
> to study a bit more or maybe somebody can point me in the right direction.
Cryptic usernames don't have to be very cryptic. The goal for you is to add
an additional layer so the user doesn't know the actual username stored on
the system that allows access to POP internally. If you don't allow shell
access *and* you are responsible for adding users, not your clients this is
quite easy - I actually use a naming convention that my users could figure
out, but whose main purpose is making it easier for me to know who owns what
files (mainly by ensuring usernames are 8 characters or less so I can see
them easily when doing an "ls") and when contacted what site/server someone
is on, and helping against dictionary email/login attacks based on security
by obscurity. Here's my convention:
[e][112][0005]
1st char - code for specific server, char 2-4 - site number, char 5-8 - user
# for that site
If I wanted to make it more secure, I'd generate the username randomly, but
that eliminates much of the benefit of the naming convention. I do have a
site that has a very basic webmail program (phpop) on it where the users
don't have shell access or any knowledge of their username. I modified
phpop to allow my users to login using their email address and server login
password (they do not know the actual username) and I have phpop internally
lookup the server username from a MySQL database table based and use that
username and supplied password to login.
If you're new to Linux (and PHP and databases?) this might be a little
overwhelming. And I don't know how hard this would be to implement with
your users or for you to automate / control username generation, etc. but
hopefully this has given you some ideas. And if you can't do it yourself
there are definitely people out there like me who do server admin /
programming for a living and could implement something for you.
--
Steve Werby
President, Befriend Internet Services LLC
http://www.befriend.com/