On Tue, Jan 13, 2009 at 3:56 PM, Alexey Melnikov <[email protected]> wrote: > On Fri, Nov 7, 2008 at 11:46 PM, Peter Saint-Andre <[email protected]> wrote: >> This Last Call has ended, with no feedback received. >> >> XMPP Extensions Editor wrote: >>> This message constitutes notice of a Last Call for comments on >>> XEP-0205 (Best Practices to Discourage Denial of Service Attacks). >>> >>> Abstract: This document recommends a number of practices that can >>> help discourage denial of service attacks on XMPP-based networks. >>> >>> URL: http://www.xmpp.org/extensions/xep-0205.html >>> >>> This Last Call begins today and shall end at the close of business on >>> 2008-11-07. >>> >>> Please consider the following questions during this Last Call and >>> send your feedback to the [email protected] discussion list: >>> >>> 1. Is this specification needed to fill gaps in the XMPP protocol >>> stack or to clarify an existing protocol? 2. Does the specification >>> solve the problem stated in the introduction and requirements? 3. Do >>> you plan to implement this specification in your code? If not, why >>> not? 4. Do you have any security concerns related to this >>> specification? 5. Is the specification accurate and clearly written? >>> >>> Your feedback is appreciated! > > One quick (and late) note: > > 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. >
The text is arguing against locking down an account on a large number of failed attempts. That is, someone other than me making the failed attempts, and the account being locked (for me as well as the one making the failed attempts). Even if you only block the IP from which the failed attempts are coming, it would still allow someone behind the same router as me to lock me out of my account (which is one of the problems with IP based blocking). -- Waqas
