1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices] Suggestion
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Suggestion&In-Reply-To=3ab53607.41755%40prima-lan.net">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"001634.html">
11 <LINK REL=
"Next" HREF=
"001659.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices] Suggestion
</H1>
15 <B>Mark Hetherington
</B>
16 <A HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Suggestion&In-Reply-To=3ab53607.41755%40prima-lan.net"
17 TITLE=
"[IRCServices] Suggestion">markh at eurodltd.co.uk
19 <I>Tue Mar
20 19:
14:
04 PST
2001</I>
21 <LI>Previous message:
<A HREF=
"001634.html">[IRCServices] Suggestion
23 <LI>Next message:
<A HREF=
"001659.html">[IRCServices] Suggestion
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#1656">[ date ]
</a>
27 <a href=
"thread.html#1656">[ thread ]
</a>
28 <a href=
"subject.html#1656">[ subject ]
</a>
29 <a href=
"author.html#1656">[ author ]
</a>
34 <PRE>><i> >> Since users having their passwords taken almost
35 </I>><i> certainly means they
36 </I>><i> >> chose an easy-to-guess password, the right solution is to
37 </I>><i> educate the
38 </I>><i> >> users. I don't see why Services should have to run
39 </I>><i> through hoops to try
40 </I>><i> >> and solve this problem. (Of course, if your server is being
41 </I>><i> >> packet-sniffed, then you have other problems altogether.)
43 </I>><i> >This is correct, but you also have to see, that passwords
44 </I>><i> are
"guessed
"
45 </I>><i> >via scripts, which use sockets (mirc has socket events e.g.)
46 </I>><i> And start a
47 </I>><i> >good amount of connects, each with
3 nick password guesses,
48 </I>><i> sure it takes
49 </I>><i> >time on good passwords, but sometimes users simply cannot
50 </I>><i> stop themselves
51 </I>><i> >from setting the cellular phone number as their password, su
52 </I>><i> suddenly it
53 </I>><i> >gets limited to numbers only etc, etc.
55 </I>><i> Hm, that's a good point. Looks like I need a better way
57 </I>><i> password guessers.
59 Maybe emulate the system used for Car radios etc. After the first failure of
60 3 "suspend
" the nickname for
1 hour, then
2 hours then
4 hours etc until it
61 is ultimately locked out entirely and an admin has to take steps to restore
62 the nickname to the user after sufficient authentication.
65 </I>><i> >Each time a nickname is registered, a nick gets an
66 </I>><i> authentication code, a
67 </I>><i> >la dalnet, which cannot be changed, and which is not shown.
68 </I>><i> Thi code is
69 </I>><i> >emailed to the address given with the register command.
70 </I>><i> After that, the
71 </I>><i> >person has to issue /nickserv AUTH
<code
> within some
72 </I>><i> services.conf days,
73 </I>><i> >or the registration will expire. If people claim to have lost their
74 </I>><i> >passwords, but can prove that they have the authentication
75 </I>><i> code, because
76 </I>><i> >it was emailed to them, a services oper can issue /nickserv
77 </I>><i> GETAUTH nick,
78 </I>><i> >and check the real authentication code against the given, if
79 </I>><i> they match,
80 </I>><i> >it is highly possible that the person is the real owner, so
81 </I>><i> >sendpass/getpass can be issued.
83 </I>><i> While this is a good idea if you want to ensure
84 </I>><i> accountability of your
85 </I>><i> users, I don't see how it solves the problem of E-mail addresses being
86 </I>><i> changed after registration. On the other hand, if this is
87 </I>><i> applied to SET
88 </I>><i> EMAIL as well, you can avoid that problem; but then you have
89 </I>><i> to deal with
90 </I>><i> people who can't use their old address and distinguishing them from
91 </I>><i> crackers who guessed the password and want to steal the nick.
93 Is this or a similar authentication system likely to be in a future version
94 of services? It is a system I would like to see since if nothing else it
95 reduces the registrations
"made on a whim
" when the process is more work
96 than /ns register pass.
98 If not, would Yusuf care to share his
"patch
" with others?
111 <LI>Previous message:
<A HREF=
"001634.html">[IRCServices] Suggestion
113 <LI>Next message:
<A HREF=
"001659.html">[IRCServices] Suggestion
115 <LI> <B>Messages sorted by:
</B>
116 <a href=
"date.html#1656">[ date ]
</a>
117 <a href=
"thread.html#1656">[ thread ]
</a>
118 <a href=
"subject.html#1656">[ subject ]
</a>
119 <a href=
"author.html#1656">[ author ]
</a>
projects / irc.git / blob