[IRCServices] More suggestions

[Strider]

I think he means no one ELSE can register it for 24h, you have 24h to
confirm it. What would be the point in making a user wait?

I actually like these suggestions for the most part. I've seen too many
users on our network register about 3 nicks and register as many chans as
possible (results in ban anyways because we can see them do that through
modifications we've made).

As for the memo, it is true any of the linked nicks can see the memo. Maybe
make a confimation instead. User attempts a link, person being linked to has
to confirm it before the link is active. But then, if you have the access to
link, then chances are this could be worked around anyways.

Beau (Strider) Steward
chatcircuit administrator and 6bit band member
strider at chatcircuit.com        www.chatcircuit.com
ircadmin at chatcircuit.com     irc.chatcircuit.com
strider at 6bit.net                    www.6bit.net
----- Original Message -----
From: "Yusuf Iskenderoglu" <uhc0 at rz.uni-karlsruhe.de>
To: <ircservices at ircservices.za.net>
Sent: Tuesday, March 20, 2001 11:51 AM
Subject: Re: [IRCServices] More suggestions


>
> Hello;
>
> On Tue, 20 Mar 2001, Partizanu wrote:
>
> > a) Have NickServ sends a memo each time a nick is linked - inform the
> > nick owner that another nick was linked to his nick
>
> Not effective because memos are merged together and become visible by any
> of the linked nicks.
>
> >
> > b) Make an option to logging system adding switch-style on services.conf
> >
> > NSLog +IPEL-RMA
> > R - registration
> > I - identification
> > M - manual drop
> > P - password change
> > E - email changed
> > L - links
> > A - access list add/del
> > Maybe the same for CSLog?
>
> What is the use of seeing access changes ? What services root is
> interested in access list changes ? Not sure about linking but, I already
> enforced services to log everything listed here.
>
> >
> > And about password/email discussion:
> >
> > 1. Rezervation phase
> > /msg nickserv register mypass my at email.address
> > NickServ - Your nick is now reserved
> > NickServ - Please check my at email.address for instructions
> >
> > Services sends a 'master-password' to my at email.address
> > Nick is now reserved, no one can register it for 24 h
> > Nick can't be added to access lists BUT it can be drop/forbid/suspend
>
> It is unlikely that you can enforce people to not-being-able-to-get-opped
> after registration. This way you would even prevent people registering
> channels they would like to register, or they had to wait 24 online (with
> a ppp connection, of course, or do all of your users have direct
> connection?)
>
>  >
> > 2. Confirmation phase
> > /msg nickserv confirm <master-password>
> > NickServ - Your nick is now confirmed and register
>
> Except from the 24h pause, I do not see any difference to the AUTH system
> I already described.
>
> > ----------------
> > What problems solve this:
> > a) verify if the email address if it's a valide one or not
> > b) verify if the email address is actually 'reachable' for the user
> > c) prevent users register lots of nicks in a easy way
> AUTH results in the same, too.
>
> > d) make sure user really wants that nick (is not a 'one night nick') -
> > why wait x days for a nick to expire in this case?
>
> My implementation was a services.conf definition of NSExpireNonauth days.
> How will you know that the remote mail system is not accidentally down?
> What happens, if the master password email cannot be sent within 3 days,
> but the fourth?
>
> > e) user can't change nick's passws without the 'master-passwd' - a
> > safety check never hurts
> > f) user can't change nicks's email address without the 'master-passwd' -
> > a safety check never hurts
> > (about (e) and (f) - I don't think users change their pass and mails so
> > often that this procedure become a pain
> > - let's keep in mind that passwd and email are important identification
> > elements - again a little safety measure won't hurt)
>
> I do not share your opinion of turning the services system to undernet's
> diplomacy of channel registrations. Services is a tool, which is there
> to make life easier. Points of security are correct, but in my oppinion
> not necessary.
>
> > g) a user can loose his password, he will always be able to change it
> > useing the 'master-passwd'
> > h) a password can be stolen, the thief can't change it
> > i) it's unlikely that the 'master-passwd' can be taken (this is used
> > only once at registration and from time to time when changeing
> > passwd/email) - it's not used everytime like the current nick passwd
>
> The same is also with the AUTH system.
>
> Regards;
> yusuf
>
>
> Yusuf Iskenderoglu  ***  eMail uhc0 at rz.uni-karlsruhe.de
>
>
> -----------------------------------------------------------
> To unsubscribe, mail ircservices-request at ircservices.za.net
> with the word UNSUBSCRIBE in the subject of the mail.
> http://www.ircservices.za.net/mailman/listinfo/ircservices
>