Proposed text at the bottom. Peter Saint-Andre wrote: > 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.
So I chatted about this with Alexey using a real-time communications technology. ;-) We concluded that we need to refer to Section 7.3.5 of rfc3920bis: http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html#sasl-process-neg-failure Therefore I would propose the following adjustment: *** 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 *except as described in Section 7.3.5 of rfc3920bis*, and it is instead recommended to limit the number of connections and connection attempts on a per-IP basis. *** This does not address the issue of whole countries behind NATs, for which we might want to add a note in Section 4.2 of XEP-0205. /psa
