[IRCServices] Suggestion

[Mark Hetherington]

> >>      Since users having their passwords taken almost
> certainly means they
> >> chose an easy-to-guess password, the right solution is to
> educate the
> >> users.  I don't see why Services should have to run
> through hoops to try
> >> and solve this problem.  (Of course, if your server is being
> >> packet-sniffed, then you have other problems altogether.)
> >
> >This is correct, but you also have to see, that passwords
> are "guessed"
> >via scripts, which use sockets (mirc has socket events e.g.)
> And start a
> >good amount of connects, each with 3 nick password guesses,
> sure it takes
> >time on good passwords, but sometimes users simply cannot
> stop themselves
> >from setting the cellular phone number as their password, su
> suddenly it
> >gets limited to numbers only etc, etc.
>
>      Hm, that's a good point.  Looks like I need a better way
> to detect
> password guessers.

Maybe emulate the system used for Car radios etc. After the first failure of
3 "suspend" the nickname for 1 hour, then 2 hours then 4 hours etc until it
is ultimately locked out entirely and an admin has to take steps to restore
the nickname to the user after sufficient authentication.

>
> >Each time a nickname is registered, a nick gets an
> authentication code, a
> >la dalnet, which cannot be changed, and which is not shown.
> Thi code is
> >emailed to the address given with the register command.
> After that, the
> >person has to issue /nickserv AUTH <code> within some
> services.conf days,
> >or the registration will expire. If people claim to have lost their
> >passwords, but can prove that they have the authentication
> code, because
> >it was emailed to them, a services oper can issue /nickserv
> GETAUTH nick,
> >and check the real authentication code against the given, if
> they match,
> >it is highly possible that the person is the real owner, so
> >sendpass/getpass can be issued.
>
>      While this is a good idea if you want to ensure
> accountability of your
> users, I don't see how it solves the problem of E-mail addresses being
> changed after registration.  On the other hand, if this is
> applied to SET
> EMAIL as well, you can avoid that problem; but then you have
> to deal with
> people who can't use their old address and distinguishing them from
> crackers who guessed the password and want to steal the nick.

Is this or a similar authentication system likely to be in a future version
of services? It is a system I would like to see since if nothing else it
reduces the registrations "made on a whim" when the process is more work
than /ns register pass.

If not, would Yusuf care to share his "patch" with others?

Mark Hetherington.
CTCP Networks.