Re: [Re: nick collide prevention ideas]

[m de`jour <b4y2k@xxxxxxxxxxxx>]

Christophe Kalt <kalt@xxxxxxxxxxx> wrote:
> On Jul 03, m de`jour wrote:
***
> | add a new command to ircd:  /rnick for random nick
> 
> any client can do this.  (mine used to)

Yes of course, but this is a -server- command, not a client script command.  A
client command would simply request a common type random nick with the old
/nick command.  Then anyone watching then could also request that same
combination with the standard /nick command by a clone on a lagged/split
server.  But /rnick as a server command would produce a special,
non-requestable random nick.



> | This /rnick function would assign a totally random nick of 9 characters.
> | 
> | It would begin with a number.
> | 
> | Read that somewhere ;) Beeth I think - this leading digit part is not my
own
> | orignal idea but neat..  and the /rnick function comes from a script I
just
> | started testing.  Putting both functions together might well be the
simplest,
> | easiest method to implement a satisfactory solution to mass collides.
> | 
> | Users could not request a specific nick starting with a number. 
> | Only servers would be able to assign nicks starting with digits
> | and all would be totally random 9 character nicks - all
> | beginning with a digit.  
> 
> that would work, granted that users would agree to live with
> random nicknames, which i highly doubt.


"Normal" users are not the really the issue.  They are not the targets of mass
collides and therefor can go merrily on their way with whatever standard nick
they want, if available.

A function such as /rnick as described would seem to address at least 2 types
of abusive takeover tricks, mass nick collides and also opcheating by stealing
the nick if a recently quit client.  With no pick-a-nick on demand, no
intercepting +o modes.  And there is some privacy protection too, as it would
prevent interception of private msgs. 

---------

First, I do not have much technical knowledge as to how ircd works.  I am
simply a user that suffers from mass nick collides and such other abuses that
a non-requestable random nick would fix.

After reading your comments about many of my other suggestions, and the
technical and practical concerns, I think the last idea about adding an
optional /rnick function would be the easiest to implement.

Would normal users want to live with it?  No matter.  The /nick command would
not be deprecated.  They would continue as is.  This is a new option; no one
is forced to use it.  Primarily it would be those who suffer from frequent
takeover attempts would use it, and they would beg for it I am quite sure. 
The most likely application would be for 24/7 connection clients such as
automated bots and screened ircII/BitchX type clients.  I don't think a bot
worries about its nick.  But as you'll note below, I offer a new twist that
allows both a recognizable nick and an effective level of collide protection.

Also, if implemented, it would quire possibly result in fewer bots, since one
of the primary reasons for having large numbers of bots/screens is for nick
collide protection.

As for the mass-collide aspect, putting aside the additional opcheating
protection etc, what is needed for it to be effective?  [Note - the techniques
described below should by and large make nick lockout for both splits and
quits obsolete and unneeded].

Only one op has to survive a mass collide.  With ten ops in a channel, nine
can be collided but as long as one survives, the takeover attempt is a total
failure.  Colliding 99% of the target ops is not good enough.  It has to be
100% or nothing.  In the simplest form, a channel of ten ops could be
protected against mass collides if just one op decides to use  this special
random nick.

Look at the typical channel security.  Many channels are manned with numerous
bots etc; usually more than needed for most channel protection.  Why?  Because
raw numbers of ops are needed to provide a reasonable level of nick collide
protection, since the difficulty of mass collides seems to be related to some
exponential, not linear equation.  Even so, reports of 30, 40, 50 and more
mass collides in some channels is not all that uncommon.

Many who run bots have 2, 3 or more b/g processes from the same server, at
times on different vhosts.  With a pragmatic acceptance of non-abusive
chanserv bots and implementation of this /rnick function, multiple bot
connections from the same server would offer little advantage.  No longer
would high raw numbers of bots be needed just to be "collide-resistant".

Near total protection against nick collides from this /rnick function would
make multiple numbers of clients from the same server unnecessary.  And for
sure, with nick collide takeovers made improbable if not impossible, some
kiddies would change to DoS attacks.  For this, AFAIK, multiple numbers of
clients from a server offer no protection.  What counts is the number of
servers providing connections, not the number of b/g processes from those
servers.

For DoS protection, 100 bots/screens, ten on each of ten shell servers offers
no more protection than just one client from each of ten servers, afaik. This
is not my area of expertise so I might be wrong about that.

So the idea I listed last seems to be the easiest to implement and would not
force anyone to change the way they do things now.  And there could be a few
interesting twists also.

That last suggestion on my earlier list was to add a new command to ircd: 
/rnick 

With that command, which require no argument, the server would assign a random
9 character nick, prefixed with a leading character from those not now
available by the /nick command.

Those would be the digits 0 to 9 and perhaps the "-" dash/minus sign.  Is
there some technical reason that the "-" was not available before for the
leading character when it could be used in any other place, like digits?

I'll assume not, just in case it could be made available, therefore that there
could be 11 special leading characters:  digits 0 to 9 and the "-"

usage:  /rnick  -with no argument- would cause the server to assign a nine
character random nick with the first character being a digit, making any such
nicks non-requestable with the /nick command as digits would still not be
allowed with that command.

/rnick would assign something like:   3ab^yhd8\

For the fully random prefixed nick assigned by the /rnick command with 10
digits available for the 1st character and 43 characters for the remaining 8
of a 9 character random nick, there would be 116,882,002,776,010 possible
combinations if my math is correct.

[Numbers change slightly if the "-" is used in addition to or instead of the
leading digit.]

If someone was able to join 100000 clones on a split server and they were each
able to request a random nick with the /rnick command once per second, it
would take over 37 years to reliably match 100% of their targets if no
requests were duplicated.  If a split lasts that long they can have my
channels.


That's the basic function...

... Now for a couple twists.

Reserve the "-" for a variant usage where the /rnick command would accept an
optional argument.

This /rnick [option] usage would allow requesting a partial or total nick
which would be prefixed with the "-" sign.

Exact nicks would be restricted to IRCops

If an IRCop requests /rnick syrk, he would be assigned "-syrk".

This would allow IRCops the option of a collide-resistant nick and still keep
it recognizable.  It would not be totally collide proof because another IRCop
could request that same nick by "accident" on a split server and get it.  But
we all know that would NEVER happen :)

Regular users could use this syntax too, but with a variation.  For non-IRCops
it would only be partial request with partial forced randomization by the
server.

For such regular users, perhaps 4 or 5 characters could be selected, with the
server adding 3 or 4 random characters.

If a non-IRCop requested /rnick betty, the server would assign something like:
"-betty5`g".

If another user requested /rnick betty5`g, they nick they would get would have
the last 3 characters forced to random by the server, to something like
"-bettyD^n".  Just 3 random characters provides over 80k other possible
combinations. 

One in 80,000 odds is admittedly not quite as good as the one in 100+ trillion
odds of matching a nine character fully random nick.  But 100% nick collision
prevention is not needed for 100% channel protection from collides, nor need
that be the goal.  Since only 0% +1 need survive a mass collide to cause total
failure for the attempt, 10% effectiveness would be a boon to channel
protectors.

The advantage of these options is retaining some name recognition and also,
for these, if the "-" is available for use, it would facilitate alphabetic
sorting on the channel nick list, a good option for live ops.

If for some technical reason the "-" can't be so used, perhaps a specific
digit could be assigned for this function to help maintain the alphabetic
sorting.

Admittedly, if something like this is implemented and is as effective as it
would seem to promise, the kiddies will turn to other tactics, like DoS. 
However, since there would be little to be gained any longer from causing
servers to split, as is the case now, the DoS would be targeted away from the
irc servers and toward the chanop/bot servers.  At least there should be fewer
netsplits, which are so disruptive to chat continuity.

DWC!  :)



____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.