Re: /etc/shadow and mod_auth_pam with pam_pwdb

[Savochkin Andrey Vladimirovich <saw msu ru>]

On Sun, Feb 21, 1999 at 04:22:42PM +0100, Ingo Luetkebohle wrote:
> On Sun, 21 Feb 1999, Savochkin Andrey Vladimirovich wrote:
> > If you have the same passwords for different services you must to
> > ensure that all the services are equivalently hard to be spied and
> > cracked.  If you use POP3, FTP and other protocols without measures to
> > protect their confidentiality you certainly can have the same password
> > for those services.  On the other hand passwords for login or ssh are
> > protected against compromises.  So it would be unwise to use the same
> > passwords for web.
> 
> Excuse me Andrey, but I those statements are about accepted security
> practice, not about a Pluggable Authentication Module library.
> 
> While I am in agreement with your statements generally, I don't think it is
> wise to enforce them by way of the PAM library. For one thing, your
> statements are not always true. I have SSL encrypted IMAP4, SSL encrypted
> FTP, SSL encrypted http. Those are in the same security league as Secure
> Shell. I see no reason why I shouldn't be able to authenticate all those
> services against one common database.

You're able.  PAM doesn't enforce to use any specific authentication scheme.
You can disable passwords shadowing.  You can use different pwdb_chkpwd.
You can do a lot of things which I can't even imagine.  The original poster
implemented a decision of his problem and asked what people think about it.

Do you consider the default pwdb_chkpwd shipped with PAM as an enforce?
If so I could repeat my opinion that its restriction of the ability to check a
password only of the invoker is a very right thing for the _common_ system.
Many system administrators don't understand security advantages and
disadvantages of different solutions and are quite happy with the existing one.

> 
> > For users being able to invoke processes the modified pwdb_chkpwd is
> > orders of magnitude more efficient than ftp service.  Even non local
> > users are able to invoke pwdb_chkpwd directly e.g. if users are allowed
> > to put their own cgi-bin scripts.  In addition sane ftp server
> > configurations deny access to the powerful accounts.
> 
> Sorry, but I don't buy it. pwdb_chkpwd is *not* orders of magnitude more
> efficient, if it is using an appropriate fail delay. I don't see how users
> can execute brute force attacks using a binary that stalls for one second
> (or any other given time-period) after every unsuccessfull try.

Well, what about 1000 pwdb_chkpwd checking the password at the same time?

Generally speaking you're right that there are methods for password guessing
other than pwdb_chkpwd.  One of the examples is `su'.  However the general
direction should be to reduce the number of such ways and to provide the
reasonable logging for those where the password guessing possibility is
unavoidable.

> 
> Your statement about "sane ftp server configurations" holds true for sane
> pwdb_chkpwd configurations as well.
> 
> And again -- I question that PAM should force me into a certain security
> practice. Its ok and even desirable to *default* to a certain security
> practice, in order to protect the unsuspecting. However, not providing a
> means of bypassing it is "unwise".

The original poster had solved his problem when he asked for comments.
You can bypass anything you want.

> 
> Let me put it another way: Basing the design of an application on how it
> *might* be exploited in a *specific* situation that is not always given, is
> an overly restrictive approach.

Regards
					Andrey V.
					Savochkin