[Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks)

Peter Saint-Andre stpeter at stpeter.im
Tue Jan 13 19:56:27 UTC 2009


Alexey Melnikov wrote:

> In Section 3, bullet 3 says:
> 
>> Limiting the number of authentication attempts for a given Jabber ID in a given time period.
>> While such a limit may seem beneficial, in fact it might result in locking out the legitimate
>> owner of a Jabber ID if a malicious entity attempts a large number of illegitimate
>> authentication attempts for the Jabber ID; therefore such a limit is not recommended
>> and it is instead recommended to limit the number of connections and connection
>> attempts on a per-IP basis.
> 
> I think this text is also arguing against counting the number of
> failed authentication attempts on a single connection, which is wrong.
> Limiting the number of authentications on a single connection doesn't
> result in lockout (the client can disconnect and reconnect) and it
> only punishes malicious (or broken) clients. This is also much easier
> to implement than a counter across multiple connections.

If you have forgotten your password you might try to authenticate 3 or 4
times before giving up.

If I'm trying to hack your password (dictionary attack) I might try to
authenticate 1000 times or whatever over some period of time.

Therefore, allowing a reasonably number of authentication retries is a
good idea but allowing an unreasonable number is a bad idea. For SASL,
rfc3920bis says at least 2 and no more than 5 authentication retries per
connection / stream:

http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html#sasl-process-neg-failure

If one hits the SASL limit, the server would terminate the stream (SASL
failure) and one would need to reconnect. Therefore, for a given
connection or stream one would be allowed 3 to 6 auth attempts. If I
want to hack your password, I'd need to "lather, rinse, repeat" (new
stream, ~5 auth attempts, failure; new stream, ~5 auth attempts,
failure; etc.). Therefore I would quickly accumulate connection attempts
to hack your account, whereas if you forget your password then you might
connect once or twice (~5 to ~10 auth attempts) then give up.

I think we have consensu that such an approach is appropriate.

Now, if I'm trying to DoS you then I could repeatedly do the
connect+auth+retry dance until your account gets locked down.

The question is, how does a server determine when to lock down an
account? You seem to envision that lockout might happen based on
exceeding some limit per time period for any of the following options:

1. authentication attempts per account
2. authentication attempts per IP address
3. connection attempts per account
4. connection attempts per IP address
5. simultaneous connections per account
6. simultaneous connections per account

Currently XEP-0205 says a server could do #1 but the consequences might
be a DoS against the legitimate user, so instead it recommends #4 or #6
because the spec assumes that the attacker will come from a different IP
address than the one used by the legitimate user. But #4 and #6 don't
solve the problem that Waqas mentions (a DoS attack launched by someone
from your same IP address, e.g. from behind the same NAT).

I hope that clarifies the options, even if it doesn't describe a full
consensus.

/psa




More information about the Standards mailing list