Re: webmail server & getpwnam "inherently unreliable" -- Precisely why is that?

From: Admin (admin@linnix.com)
Date: 03/12/02 

From: admin@linnix.com (Admin)
Date: 12 Mar 2002 09:37:43 -0800

rut@linuxmail.org (gaius.petronius) wrote in message news:<188cd7b2.0203111751.3ceb66ac@posting.google.com>...
> admin@linnix.com (Admin) wrote in message news:<f431c10.0203111110.351209df@posting.google.com>...
> > "Nico Kadel-Garcia" <nkadel@bellatlantic.net> wrote in message news:<S83j8.1245$vH1.126@nwrddc01.gnilink.net>...
> > > "gaius.petronius" <rut@linuxmail.org> wrote in message
> > > news:188cd7b2.0203102144.32642664@posting.google.com...
> > > > cross-posted because it basically touches on 2 aspects of the password
> > > > issue on a webmail server, the code to check the passwd, and the
> > > > system itself.
> > > >
> > > > quote from http://cr.yp.to/checkpwd/interface.html
> > > >
> > > > "WARNING: getpwnam is inherently unreliable. It fails to distinguish
> > > > between temporary errors and nonexistent users. Future versions of
> > > > getpwnam should return ETXTBSY to indicate temporary errors and ESRCH
> > > > to indicate nonexistent users."
> > Have your own wrapper modules to call getpwnam? I do checking in my
> > own
> > getpwname before and after calling getpwnam.
> > > >
> > > > Precisely why is the getpwnam library function(?) "inherently
> > > > unreliable"?
> Because mail program authors abuse the functionality.
> > > >
> > > > The background to all this is that the management types have requested
> > > > a "webmail" server which has the same look and feel of a hotmail,
> > > > yahoo, et cetera.
> > Easily enough, just forward their mail to hotmail and yahoo. In fact,
> > that's
> > what many of our user does, forward to hotmail and yahoo while on the
> > road.
> > Disconnect forwarding while on site.
> > > >
> > > > i at least got what i asked for in order to implement this: a separate
> > > > server which i plan to alias usernames from the original server (step
> > > > 1), and then use programs like checkpwd.
> > > >
> > > > but in the end the machine is still using the same old smtp plain text
> > > > login, so i don't really see the point and don't see how i can ensure
> > > > security against a cracker sniffing what he knows to be the first N
> > > > number of packets in a POP or IMAP exchange.
> > >
> > > *INSIST* on SSL use to prevent this.
> > >
> > > > am i right or wrong about the uselessness of trying to strengthen the
> > > > password login aspect of this machine in face of the fact that they
> > > > will send plaintext passwords over the internet?
> > >
> > > Basically, yes.
>
> forced to do this anyway, and with a timeframe of 4 days to get it
> into production (aside from regular duties), i and another guy will
> implement SSL for the https connection, and then use "WebMail"
> (whatever that is), which will utilize cgi programs to authenticate
> the user. i use the term "authenticate" loosely, since this WebMail
> interface apparently stores usernames and passwords in a mysql
> database on the machine for "administrative convenience." i opposed
Convenient for whom? Now you have to deal with one more set of
user/passwd.
> the idea but couldn't offer a better solution, so they are going with
> this webmail creature. The cgi programs will interface to 'qmail.'
>
We use neomail, simple interface, but as least it authenticates users
with "/etc/passwd".
> i'm going to sit this box outside the DMZ and disable all other
> services beside https, smtp, pop3, and imap.
>
> -- is there a way to configure PAM to require the following password
> structure:
> at least 8 positions, at least 2 numbers, at least 1 NON-alphanumeric?
Most passwd program warns against simple passwords. You will have to
enforce it with your own rules and codes. We have our password setup
build into the Webmail interface (for the user to change it easily and
frequently).
>
> > > > isn't that a giant step in the direction of breaking security in
> > > > itself? that means whatever crackers may be doing at client sites
> > > > automatically infects this webmail server.
> > >
> > No worst than what they can do with regular email or http.
>
> but now they are on *foreign* machines entering sensitive data.
That's different from infecting the webmail server. SSL should
protect against wire-tapping, to a certain degree.
>
> > > See above. Explain that this is, in fact a common problem and that crackers
> > > *love* to break into firewalls to monitor this sort of traffic.
>
> they are unconcerned; and yet i am still "responsible" to ensure
> security.
>
> > No to mension the system admin of your client reading your email.
>
> Yeah. i know some of those guys. They strike me more as NT "Power
> Users." So i would guess that their systems have crackers burrowed in
> them.
>
> > Don't forget that they don't report to you or your company.
>
> Right.
>
> After 35 years of the internet, when do you think IPSec can become a
> standard?
Which IPSec? Most IPSec are difficult to set up. Anyway, I don't
think that will solve your problem of mobile users. IPSec is mostly
for stable tunnels between fixed systems.

Relevant Pages