[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: /etc/shadow and mod_auth_pam with pam_pwdb



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.

> 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.

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".

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,

--
		Ingo Luetkebohle / 21st Century Digital Boy
dev/consulting Gesellschaft fuer Netzwerkentwicklung und -beratung mbH
url: http://www.devconsult.de/ - fon: 0521-1365800 - fax: 0521-1365803 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []