1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices] More suggestions
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20More%20suggestions&In-Reply-To=3AB77F94.294F5848%40expres.ro">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"001655.html">
11 <LINK REL=
"Next" HREF=
"001660.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices] More suggestions
</H1>
15 <B>Yusuf Iskenderoglu
</B>
16 <A HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20More%20suggestions&In-Reply-To=3AB77F94.294F5848%40expres.ro"
17 TITLE=
"[IRCServices] More suggestions">uhc0 at rz.uni-karlsruhe.de
19 <I>Tue Mar
20 19:
51:
02 PST
2001</I>
21 <LI>Previous message:
<A HREF=
"001655.html">[IRCServices] More suggestions
23 <LI>Next message:
<A HREF=
"001660.html">[IRCServices] More suggestions
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#1658">[ date ]
</a>
27 <a href=
"thread.html#1658">[ thread ]
</a>
28 <a href=
"subject.html#1658">[ subject ]
</a>
29 <a href=
"author.html#1658">[ author ]
</a>
36 On Tue,
20 Mar
2001, Partizanu wrote:
38 ><i> a) Have NickServ sends a memo each time a nick is linked - inform the
39 </I>><i> nick owner that another nick was linked to his nick
41 Not effective because memos are merged together and become visible by any
45 </I>><i> b) Make an option to logging system adding switch-style on services.conf
47 </I>><i> NSLog +IPEL-RMA
48 </I>><i> R - registration
49 </I>><i> I - identification
50 </I>><i> M - manual drop
51 </I>><i> P - password change
52 </I>><i> E - email changed
54 </I>><i> A - access list add/del
55 </I>><i> Maybe the same for CSLog?
57 What is the use of seeing access changes ? What services root is
58 interested in access list changes ? Not sure about linking but, I already
59 enforced services to log everything listed here.
62 </I>><i> And about password/email discussion:
64 </I>><i> 1. Rezervation phase
65 </I>><i> /msg nickserv register mypass
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">my at email.address
</A>
66 </I>><i> NickServ - Your nick is now reserved
67 </I>><i> NickServ - Please check
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">my at email.address
</A> for instructions
69 </I>><i> Services sends a 'master-password' to
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">my at email.address
</A>
70 </I>><i> Nick is now reserved, no one can register it for
24 h
71 </I>><i> Nick can't be added to access lists BUT it can be drop/forbid/suspend
73 It is unlikely that you can enforce people to not-being-able-to-get-opped
74 after registration. This way you would even prevent people registering
75 channels they would like to register, or they had to wait
24 online (with
76 a ppp connection, of course, or do all of your users have direct
80 ><i> 2. Confirmation phase
81 </I>><i> /msg nickserv confirm
<master-password
>
82 </I>><i> NickServ - Your nick is now confirmed and register
84 Except from the
24h pause, I do not see any difference to the AUTH system
87 ><i> ----------------
88 </I>><i> What problems solve this:
89 </I>><i> a) verify if the email address if it's a valide one or not
90 </I>><i> b) verify if the email address is actually 'reachable' for the user
91 </I>><i> c) prevent users register lots of nicks in a easy way
92 </I>AUTH results in the same, too.
94 ><i> d) make sure user really wants that nick (is not a 'one night nick') -
95 </I>><i> why wait x days for a nick to expire in this case?
97 My implementation was a services.conf definition of NSExpireNonauth days.
98 How will you know that the remote mail system is not accidentally down?
99 What happens, if the master password email cannot be sent within
3 days,
102 ><i> e) user can't change nick's passws without the 'master-passwd' - a
103 </I>><i> safety check never hurts
104 </I>><i> f) user can't change nicks's email address without the 'master-passwd' -
105 </I>><i> a safety check never hurts
106 </I>><i> (about (e) and (f) - I don't think users change their pass and mails so
107 </I>><i> often that this procedure become a pain
108 </I>><i> - let's keep in mind that passwd and email are important identification
109 </I>><i> elements - again a little safety measure won't hurt)
111 I do not share your opinion of turning the services system to undernet's
112 diplomacy of channel registrations. Services is a tool, which is there
113 to make life easier. Points of security are correct, but in my oppinion
116 ><i> g) a user can loose his password, he will always be able to change it
117 </I>><i> useing the 'master-passwd'
118 </I>><i> h) a password can be stolen, the thief can't change it
119 </I>><i> i) it's unlikely that the 'master-passwd' can be taken (this is used
120 </I>><i> only once at registration and from time to time when changeing
121 </I>><i> passwd/email) - it's not used everytime like the current nick passwd
123 The same is also with the AUTH system.
129 Yusuf Iskenderoglu *** eMail
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">uhc0 at rz.uni-karlsruhe.de
</A>
139 <LI>Previous message:
<A HREF=
"001655.html">[IRCServices] More suggestions
141 <LI>Next message:
<A HREF=
"001660.html">[IRCServices] More suggestions
143 <LI> <B>Messages sorted by:
</B>
144 <a href=
"date.html#1658">[ date ]
</a>
145 <a href=
"thread.html#1658">[ thread ]
</a>
146 <a href=
"subject.html#1658">[ subject ]
</a>
147 <a href=
"author.html#1658">[ author ]
</a>
projects / irc.git / blob