[IRCServices Coding] A few things...

Dylan v.d Merwe dylanvdm at icon.co.za
Fri Sep 20 11:30:58 PDT 2002


Yes I guess hackers could mess around with this BUT...

#         nickserv/mail-auth  [OPTIONAL; RECOMMENDED for large networks]
#             Allows verification of E-mail addresses for nicknames by
#             sending an authorization code to the address given in the
#             REGISTER or SET EMAIL command and disallowing identification
#             for the nick until the user sends the authorization code to
#             NickServ with the AUTH command.

#         nickserv/sendpass  [OPTIONAL]
#             Provides a SENDPASS command which allows users to have
#             NickServ send their nickname password to the E-mail address
#             they have registered for the nickname.
#             NOTE: This module requires the "nickserv/mail-auth" module.

#         chanserv/sendpass  [OPTIONAL]
#             Provides a SENDPASS command which allows channel founders to
#             have ChanServ send the password for a channel to the E-mail
#             address they have registered for their nickname.
#             NOTE: This module requires the "nickserv/mail-auth" module.

If you read the above it says that they all require the nickserv/mail-auth
module.
This is understandable because how can you be sure that you are sending this
email to a valid email address? Though I must say newbies hardly use
features like SENDPASS if they don't know what it does (you do get idjits of
course).
Newbies will also be inclined to use a valid email address anyway. Advanced
users will more
likely use this feature after they come back from holiday or if their mind
truly has been elsewhere and they forget their password. It is common sense
(to normal people) that a situation may arise that you might forget your
password, which is a good reason why you should specify a valid email
address from the beginning.

I really really really think this should be discussed because I would find
it much easier if you didn't need to authenticate your passwords first. It
is also the network's responsibility to make sure that they give adequate
notification that a *valid* email address should be used.

Not forgetting about abuse of this feature, there is:

    # NSSendauthDelay <time>  [RECOMMENDED]
    #     Sets the minimum length of time between consecutive uses of the
    #     SENDAUTH command for the same nick group.  If not specified, this
    #     restriction is disabled.
    #
    #     WARNING: Not setting NSSendauthDelay, or setting it too low, will
    #              allow users to abuse this command to send large
    #              quantities of mail (mailbombs) to arbitrary users!

    NSSendauthDelay 1d

    # CSSendpassDelay <time>  [RECOMMENDED]
    #     Sets the period of time which must elapse between SENDPASS
    #     commands for the same channel.  If not specified, the SENDPASS
    #     command may be used at any time.
    #
    #     NOTE: Since users can only send passwords to nicks they have
    #           identified for, the potential for E-mail attacks via this
    #           command is minimal; however, setting this limit too low (or
    #           not setting it at all) can allow users to slow down
    #           Services through frequent SENDPASS requests.

    CSSendpassDelay 12h


I think that the SENDPASS option available in NickServ and ChanServ is very
helpful as it will save CSops a workout. I was a CSop for some time on a big
network and getting people's passwords (which were quite funny) becomes
irritating when there are other things to do.

I also hope that the
* services.shadownet.za.net changed topic to 'blah blah (nick)'
will be changed to ChanServ as it really does make it look neater.

Yusuf Iskenderoglu said:
"No, AFAIK at least Unreal does not allow ChanServ set the TOPIC that
way."

Yusuf it does. Well I'm not sure about the 3.1 series but the 3.2 definitely
does. I have checked this feature on another services package (which I
didn't like) and when I typed /chanserv topic #chan <topic>, ChanServ set
the topic as I suggested and not the name of the services server. As I said
it's
not some huge problem but it would look nicer - like adding blonde streaks
into a sexy brunettes hair :-)

And thanks for your opinions on the proxy scanner. I must admit I haven't
used BOPM but will soon.

Ty

D.

----- Original Message -----
From: "Panagiotis Kefalidis" <pkef at hnioxos.ee.auth.gr>
To: <ircservices-coding at ircservices.za.net>
Sent: Friday, September 20, 2002 1:50 PM
Subject: Re: AW: [IRCServices Coding] A few things...


>
>
> On Fri, 20 Sep 2002, Yusuf Iskenderoglu wrote:
>
> >
> >
> > Hello;
> >
> > >> How will you ensure that the email is correct ? If it is not
> > >> Authenticated ? Users could have set a at b.c.de as email.
> > >I think we don't care about the email they've set.To set a
> > >valid mail is for their own good in case they forget their
> > >password.I believe just a notice while running the register
> > >proccess,about setting a valid email,is enough. (:
> >
> > It looks as if you have never run sendmail. And have never had
> > To kill 500 sendmail processes trying to time out due to wrong
> > Email addresses, when attackers think they are cleverer.
> I did,but to be honest,i'ven't thought about that(attackers).We can add a
> limit to the SENDPASS command to prevent attackers doing this.I mean, in
case
> there is an email set,adding a limit to the user preventing him to use
> the SENDPASS more than 1 time per hour or sth like that, would be
> nice/enough to prevent abuse.
>
> Whatever i've written above is not what i believe as being right.
> My personal opinion is that the most safe way is FIRST authenticate
> the email and then anything else.That's to prevent abuse from attackers
> or any other kind of attack to services or the machine running them
> itself,as yusuf mentioned in his reply.
>
>
> > Please do consider that there are users without root-rights
> > Who also run services, and they cannot modify sendmail settings.
> >
> That's true. :|
> > As of this, a new command a la DENYMAIL add|del|list to prevent
> > Certain email addresses from being used at registration processes
> > Would moreover be fine.
> >
> > SCNR.
> > Yusuf
> >
> Regards,
> Gizm0.-
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>