[IRCServices Coding] A few things...

[Andrew Church]

     RTFM (section 3-1-5).  I could go on for pages and pages about the
many ways the ability to send mail to arbitrary addresses could be abused,
but I'll leave that as an exercise for the reader.  All Services functions
that allow the sending of mail will require the mail-auth module
(memoserv/forward requires it as well, and the documentation has been
corrected to reflect this); this decision is final and is not open for
discussion.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/

>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
>>
>
>
>
>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding