[Operators] in-band registration [forever]
skupko.sk at gmail.com
Tue Apr 10 23:28:11 UTC 2012
[un]fortunately our server is supporting 'unprotected' IBR and we are
not going to disable/'protect' it during next few months/years. For sure
there are also accounts used during attacks registered on our server,
but I think this is the same on all XMPP servers with any open
registration and administrators have to just take care of them (somehow).
@Peter - I find it very useful and simple way to register and do not
want to complicate lives of our potential users. Therefore we are not
running captcha (as 'security' module) for IBR - from my (and our
server's) present point of view it's meaningless and today's attackers
can breach it easy.
@Kevin - that your comparison is not completely right. I do not think
that we need to move away from IBR. I like that approach for
registration and it make sense to install XMPP client and register on
any XMPP server trough using just that one application.
The only we need is to find the way how to protect our servers from the
attacks in the efficient and effective way. (there is nothing efficient
and effective known at this time) The response to this could be
"xep-0268" - already proposed by Peter Saint-Andre on February this year
- and I hope that all of us will push on developers of our XMPP servers
to implement it once it will be available.
This is a question of making XMPP mature and I do not think there is
need to 'move away from IBR' or 'block all XMPP servers with unprotected
IBR from federation'.
IBR is a (nicest?) feature of XMPP and cannot be punished for
'not-the-best' security implementation of XMPP. :-)
On 04/10/2012 11:22 PM, Kevin Smith wrote:
> On Tue, Apr 10, 2012 at 10:13 PM, Peter Saint-Andre<stpeter at stpeter.im> wrote:
>> Has in-band registration outlived its usefulness? It was originally
>> designed as a user-friendly way to jumpstart use of Jabber
>> technologies back in 1999. Perhaps it's not so appropriate today?
> FWIW, my view is that servers with unprotected IBR are conceptually
> very similar to open proxies and we need to move away from it.
More information about the Operators