projects / irc.git / blame
| Commit | Line | Data |
|---|---|---|
| 3bd189cb JR |
1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> |
| 2 | <HTML> | |
| 3 | <HEAD> | |
| 4 | <TITLE> [IRCServices Coding] A few things... | |
| 5 | </TITLE> | |
| 6 | <LINK REL="Index" HREF="index.html" > | |
| 7 | <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20A%20few%20things...&In-Reply-To="> | |
| 8 | <META NAME="robots" CONTENT="index,nofollow"> | |
| 9 | <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> | |
| 10 | <LINK REL="Previous" HREF="001498.html"> | |
| 11 | <LINK REL="Next" HREF="001483.html"> | |
| 12 | </HEAD> | |
| 13 | <BODY BGCOLOR="#ffffff"> | |
| 14 | <H1>[IRCServices Coding] A few things...</H1> | |
| 15 | <B>Dylan v.d Merwe</B> | |
| 16 | <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20A%20few%20things...&In-Reply-To=" | |
| 17 | TITLE="[IRCServices Coding] A few things...">dylanvdm at icon.co.za | |
| 18 | </A><BR> | |
| 19 | <I>Fri Sep 20 11:30:58 PDT 2002</I> | |
| 20 | <P><UL> | |
| 21 | <LI>Previous message: <A HREF="001498.html">[IRCServices Coding] Memoserv Forward | |
| 22 | </A></li> | |
| 23 | <LI>Next message: <A HREF="001483.html">[IRCServices Coding] A few things... | |
| 24 | </A></li> | |
| 25 | <LI> <B>Messages sorted by:</B> | |
| 26 | <a href="date.html#1482">[ date ]</a> | |
| 27 | <a href="thread.html#1482">[ thread ]</a> | |
| 28 | <a href="subject.html#1482">[ subject ]</a> | |
| 29 | <a href="author.html#1482">[ author ]</a> | |
| 30 | </LI> | |
| 31 | </UL> | |
| 32 | <HR> | |
| 33 | <!--beginarticle--> | |
| 34 | <PRE>Yes I guess hackers could mess around with this BUT... | |
| 35 | ||
| 36 | # nickserv/mail-auth [OPTIONAL; RECOMMENDED for large networks] | |
| 37 | # Allows verification of E-mail addresses for nicknames by | |
| 38 | # sending an authorization code to the address given in the | |
| 39 | # REGISTER or SET EMAIL command and disallowing identification | |
| 40 | # for the nick until the user sends the authorization code to | |
| 41 | # NickServ with the AUTH command. | |
| 42 | ||
| 43 | # nickserv/sendpass [OPTIONAL] | |
| 44 | # Provides a SENDPASS command which allows users to have | |
| 45 | # NickServ send their nickname password to the E-mail address | |
| 46 | # they have registered for the nickname. | |
| 47 | # NOTE: This module requires the "nickserv/mail-auth" module. | |
| 48 | ||
| 49 | # chanserv/sendpass [OPTIONAL] | |
| 50 | # Provides a SENDPASS command which allows channel founders to | |
| 51 | # have ChanServ send the password for a channel to the E-mail | |
| 52 | # address they have registered for their nickname. | |
| 53 | # NOTE: This module requires the "nickserv/mail-auth" module. | |
| 54 | ||
| 55 | If you read the above it says that they all require the nickserv/mail-auth | |
| 56 | module. | |
| 57 | This is understandable because how can you be sure that you are sending this | |
| 58 | email to a valid email address? Though I must say newbies hardly use | |
| 59 | features like SENDPASS if they don't know what it does (you do get idjits of | |
| 60 | course). | |
| 61 | Newbies will also be inclined to use a valid email address anyway. Advanced | |
| 62 | users will more | |
| 63 | likely use this feature after they come back from holiday or if their mind | |
| 64 | truly has been elsewhere and they forget their password. It is common sense | |
| 65 | (to normal people) that a situation may arise that you might forget your | |
| 66 | password, which is a good reason why you should specify a valid email | |
| 67 | address from the beginning. | |
| 68 | ||
| 69 | I really really really think this should be discussed because I would find | |
| 70 | it much easier if you didn't need to authenticate your passwords first. It | |
| 71 | is also the network's responsibility to make sure that they give adequate | |
| 72 | notification that a *valid* email address should be used. | |
| 73 | ||
| 74 | Not forgetting about abuse of this feature, there is: | |
| 75 | ||
| 76 | # NSSendauthDelay <time> [RECOMMENDED] | |
| 77 | # Sets the minimum length of time between consecutive uses of the | |
| 78 | # SENDAUTH command for the same nick group. If not specified, this | |
| 79 | # restriction is disabled. | |
| 80 | # | |
| 81 | # WARNING: Not setting NSSendauthDelay, or setting it too low, will | |
| 82 | # allow users to abuse this command to send large | |
| 83 | # quantities of mail (mailbombs) to arbitrary users! | |
| 84 | ||
| 85 | NSSendauthDelay 1d | |
| 86 | ||
| 87 | # CSSendpassDelay <time> [RECOMMENDED] | |
| 88 | # Sets the period of time which must elapse between SENDPASS | |
| 89 | # commands for the same channel. If not specified, the SENDPASS | |
| 90 | # command may be used at any time. | |
| 91 | # | |
| 92 | # NOTE: Since users can only send passwords to nicks they have | |
| 93 | # identified for, the potential for E-mail attacks via this | |
| 94 | # command is minimal; however, setting this limit too low (or | |
| 95 | # not setting it at all) can allow users to slow down | |
| 96 | # Services through frequent SENDPASS requests. | |
| 97 | ||
| 98 | CSSendpassDelay 12h | |
| 99 | ||
| 100 | ||
| 101 | I think that the SENDPASS option available in NickServ and ChanServ is very | |
| 102 | helpful as it will save CSops a workout. I was a CSop for some time on a big | |
| 103 | network and getting people's passwords (which were quite funny) becomes | |
| 104 | irritating when there are other things to do. | |
| 105 | ||
| 106 | I also hope that the | |
| 107 | * services.shadownet.za.net changed topic to 'blah blah (nick)' | |
| 108 | will be changed to ChanServ as it really does make it look neater. | |
| 109 | ||
| 110 | Yusuf Iskenderoglu said: | |
| 111 | "No, AFAIK at least Unreal does not allow ChanServ set the TOPIC that | |
| 112 | way." | |
| 113 | ||
| 114 | Yusuf it does. Well I'm not sure about the 3.1 series but the 3.2 definitely | |
| 115 | does. I have checked this feature on another services package (which I | |
| 116 | didn't like) and when I typed /chanserv topic #chan <topic>, ChanServ set | |
| 117 | the topic as I suggested and not the name of the services server. As I said | |
| 118 | it's | |
| 119 | not some huge problem but it would look nicer - like adding blonde streaks | |
| 120 | into a sexy brunettes hair :-) | |
| 121 | ||
| 122 | And thanks for your opinions on the proxy scanner. I must admit I haven't | |
| 123 | used BOPM but will soon. | |
| 124 | ||
| 125 | Ty | |
| 126 | ||
| 127 | D. | |
| 128 | ||
| 129 | ----- Original Message ----- | |
| 130 | From: "Panagiotis Kefalidis" <<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">pkef at hnioxos.ee.auth.gr</A>> | |
| 131 | To: <<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">ircservices-coding at ircservices.za.net</A>> | |
| 132 | Sent: Friday, September 20, 2002 1:50 PM | |
| 133 | Subject: Re: AW: [IRCServices Coding] A few things... | |
| 134 | ||
| 135 | ||
| 136 | ><i> | |
| 137 | </I>><i> | |
| 138 | </I>><i> On Fri, 20 Sep 2002, Yusuf Iskenderoglu wrote: | |
| 139 | </I>><i> | |
| 140 | </I>><i> > | |
| 141 | </I>><i> > | |
| 142 | </I>><i> > Hello; | |
| 143 | </I>><i> > | |
| 144 | </I>><i> > >> How will you ensure that the email is correct ? If it is not | |
| 145 | </I>><i> > >> Authenticated ? Users could have set <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">a at b.c.de</A> as email. | |
| 146 | </I>><i> > >I think we don't care about the email they've set.To set a | |
| 147 | </I>><i> > >valid mail is for their own good in case they forget their | |
| 148 | </I>><i> > >password.I believe just a notice while running the register | |
| 149 | </I>><i> > >proccess,about setting a valid email,is enough. (: | |
| 150 | </I>><i> > | |
| 151 | </I>><i> > It looks as if you have never run sendmail. And have never had | |
| 152 | </I>><i> > To kill 500 sendmail processes trying to time out due to wrong | |
| 153 | </I>><i> > Email addresses, when attackers think they are cleverer. | |
| 154 | </I>><i> I did,but to be honest,i'ven't thought about that(attackers).We can add a | |
| 155 | </I>><i> limit to the SENDPASS command to prevent attackers doing this.I mean, in | |
| 156 | </I>case | |
| 157 | ><i> there is an email set,adding a limit to the user preventing him to use | |
| 158 | </I>><i> the SENDPASS more than 1 time per hour or sth like that, would be | |
| 159 | </I>><i> nice/enough to prevent abuse. | |
| 160 | </I>><i> | |
| 161 | </I>><i> Whatever i've written above is not what i believe as being right. | |
| 162 | </I>><i> My personal opinion is that the most safe way is FIRST authenticate | |
| 163 | </I>><i> the email and then anything else.That's to prevent abuse from attackers | |
| 164 | </I>><i> or any other kind of attack to services or the machine running them | |
| 165 | </I>><i> itself,as yusuf mentioned in his reply. | |
| 166 | </I>><i> | |
| 167 | </I>><i> | |
| 168 | </I>><i> > Please do consider that there are users without root-rights | |
| 169 | </I>><i> > Who also run services, and they cannot modify sendmail settings. | |
| 170 | </I>><i> > | |
| 171 | </I>><i> That's true. :| | |
| 172 | </I>><i> > As of this, a new command a la DENYMAIL add|del|list to prevent | |
| 173 | </I>><i> > Certain email addresses from being used at registration processes | |
| 174 | </I>><i> > Would moreover be fine. | |
| 175 | </I>><i> > | |
| 176 | </I>><i> > SCNR. | |
| 177 | </I>><i> > Yusuf | |
| 178 | </I>><i> > | |
| 179 | </I>><i> Regards, | |
| 180 | </I>><i> Gizm0.- | |
| 181 | </I>><i> | |
| 182 | </I>><i> ------------------------------------------------------------------ | |
| 183 | </I>><i> To unsubscribe or change your subscription options, visit: | |
| 184 | </I>><i> <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding</A> | |
| 185 | </I>><i> | |
| 186 | </I> | |
| 187 | ||
| 188 | ||
| 189 | ||
| 190 | </PRE> | |
| 191 | ||
| 192 | <!--endarticle--> | |
| 193 | <HR> | |
| 194 | <P><UL> | |
| 195 | <!--threads--> | |
| 196 | <LI>Previous message: <A HREF="001498.html">[IRCServices Coding] Memoserv Forward | |
| 197 | </A></li> | |
| 198 | <LI>Next message: <A HREF="001483.html">[IRCServices Coding] A few things... | |
| 199 | </A></li> | |
| 200 | <LI> <B>Messages sorted by:</B> | |
| 201 | <a href="date.html#1482">[ date ]</a> | |
| 202 | <a href="thread.html#1482">[ thread ]</a> | |
| 203 | <a href="subject.html#1482">[ subject ]</a> | |
| 204 | <a href="author.html#1482">[ author ]</a> | |
| 205 | </LI> | |
| 206 | </UL> | |
| 207 | ||
| 208 | </body></html> |