Lawrence Greenfield wrote:
> From: Christopher Wong <[EMAIL PROTECTED]>
> Date: Tue, 11 Sep 2001 17:56:08 -0400
>
> [...]
> Thanks. Does it slow down retries in the case of unsuccessful attempts?
> Otherwise, it would be as vulnerable to password guessing as pwcheck
> is. That weakness of pwcheck makes it practically useless: access to
> its port is comparable to read access to /etc/shadow and must be
> restricted accordingly. That makes pwcheck redundant.
>
> Please stop just rnadomly suggesting things. The unix domain socket
> that is used by pwcheck/saslauthd can be protected to only the Cyrus
> user, preventing any other Unix user access to it, even if you do
> allow users to log into the system.
>
> Generally, /etc/shadow isn't there to stop on-line password guessing,
> it's to stop someone from downloading the crypts and running off-line
> dictionary attacks.
>
I think that Christopher's point is that someone with access to the pwcheck
socket could use it to mount a password attack, since pwcheck doesn't pause
after an unsuccessful login. In that sense it is true that "access to its
port is comparable to read access to /etc/shadow and must be restricted
accordingly". Access to the pwcheck port is only required for the Cyrus user
though, so there is no problem for a pwcheck daemon that correctly sets the
permissions for the socket.
> On the other hand, if forking is unlimited then a user might use
> saslauthd to guess numerous passwords in parallel. Consequently,
> slowing down retries may not be enough. Could you explain how saslauthd
> addresses these issues?
>
I don't know about saslauthd, but the approach I use in my Perl-based
pwcheck daemon is to use a preforking approach with a limit on the maximum
number of processes.
> The imapd process slows down on bad passwords, but nothing in the base
> code stops someone from opening large number of IMAP connections, but
> such an attack is very obvious.
>
For someone with access to the pwcheck socket imapd's behaviour is not
relevent (and Chris mentioned that his concern is access to the socket).
What matters is the behaviour of the pwcheck or saslauthd daemon.
Having said that, the argument that pwcheck is "practically useless" still
doesn't make sense. Access to the pwcheck socket can be restricted to the
Cyrus user, and as a unix socket it is only accessible if you have local
access to the machine. So if you have local access to the machine _and_
access to the Cyrus account, you can mount a password guessing attack on the
shadow file. Hardly a huge problem, although I think I will add a pause into
my preforking Perl daemon framework as a precaution. I'll announce this on
the list when it's done.
