[IRCServices] More suggestions

[Yusuf Iskenderoglu]

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