software/!RELEASES/ircservices/achurch.org/services/lists/ircservices/2001/001695.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices] auto suspension after invalid passwords
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20auto%20suspension%20after%20invalid%20passwords&In-Reply-To=01b801c0b397%240582b6a0%249c011ac4%40africa.didata.local">
   8    <META NAME="robots" CONTENT="index,nofollow">
   9    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
  10    <LINK REL="Previous"  HREF="001693.html">
  11    <LINK REL="Next"  HREF="001696.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices] auto suspension after invalid passwords</H1>
  15     <B>Jonathan Morton</B>
  16     <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20auto%20suspension%20after%20invalid%20passwords&In-Reply-To=01b801c0b397%240582b6a0%249c011ac4%40africa.didata.local"
  17        TITLE="[IRCServices] auto suspension after invalid passwords">chromi at cyberspace.org
  18        </A><BR>
  19     <I>Fri Mar 23 15:36:00 PST 2001</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="001693.html">[IRCServices] auto suspension after invalid passwords
  22 </A></li>
  23         <LI>Next message: <A HREF="001696.html">[IRCServices] StartUp problems
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#1695">[ date ]</a>
  27               <a href="thread.html#1695">[ thread ]</a>
  28               <a href="subject.html#1695">[ subject ]</a>
  29               <a href="author.html#1695">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>&gt;<i>Imho, the feature has good intentions but isn't very robust. Let's look at
  35 </I>&gt;<i>what it's trying to do:
  36 </I>&gt;<i>
  37 </I>&gt;<i>- Prevent a user from brute forcing the nick's password.
  38 </I>&gt;<i>
  39 </I>&gt;<i>What are we currently doing to prevent this:
  40 </I>&gt;<i>
  41 </I>&gt;<i>- Kill the user after X invalid passwords. This allows opers to see who is
  42 </I>&gt;<i>getting a password wrong _a lot_. They can then akill the person's host.
  43 </I>&gt;<i>
  44 </I>&gt;<i>What is the current method lacking:
  45 </I>&gt;<i>
  46 </I>&gt;<i>- If there are no active opers (ooops), then the user could get away with it
  47 </I>&gt;<i>for a while. So basically a temp akill might surfice. Atleast it would make
  48 </I>&gt;<i>it slightly harder for the user to brute force the nickname effectively.
  49 </I>&gt;<i>
  50 </I>&gt;<i>Finally, the chances of someone brute forcing a nickname's password are
  51 </I>&gt;<i>already small - seeing as we have a minimum password length. So, maybe this
  52 </I>&gt;<i>extra security is unnecessary?
  53 </I>
  54 Maybe I'm biased because it was my idea, but I think the temp AKILL would
  55 work spendidly.  If the abuser reconnects before the AKILL expires, a
  56 k:line is automatically added - no oper interference needed.  If by chance
  57 it was a genuine mistake on the part of the user, they can e-mail the
  58 admins and get the k:line lifted (when the next oper comes along), and
  59 everything is fine.
  60
  61 If the abuser reconnects on a different IP, he eventually runs out of IPs -
  62 also if an oper is watching the status window he can get rid of the abuser
  63 without problems.  If the abuser is smart enough to wait for the AKILL
  64 timeout before attempting to reconnect in the first place, this still slows
  65 him down (probably enough to make it not worth his while).
  66
  67 I'm a strong believer in letting the server do as much work as cannot
  68 possibly be handled by anyone other than the oper.  On any decent-sized
  69 network, the workload on a given oper must be tremendous - anything the
  70 server can do to reduce problems (while not introducing new ones) has to be
  71 a good thing.
  72
  73 --------------------------------------------------------------
  74 from:     Jonathan &quot;Chromatix&quot; Morton
  75 mail:     <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">chromi at cyberspace.org</A>  (not for attachments)
  76 big-mail: <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">chromatix at penguinpowered.com</A>
  77 uni-mail: <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">j.d.morton at lancaster.ac.uk</A>
  78
  79 The key to knowledge is not to rely on people to teach you it.
  80
  81 Get VNC Server for Macintosh from <A HREF="http://www.chromatix.uklinux.net/vnc/">http://www.chromatix.uklinux.net/vnc/</A>
  82
  83 -----BEGIN GEEK CODE BLOCK-----
  84 Version 3.12
  85 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
  86 PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
  87 -----END GEEK CODE BLOCK-----
  88
  89
  90
  91
  92 </PRE>
  93
  94 <!--endarticle-->
  95     <HR>
  96     <P><UL>
  97         <!--threads-->
  98         <LI>Previous message: <A HREF="001693.html">[IRCServices] auto suspension after invalid passwords
  99 </A></li>
 100         <LI>Next message: <A HREF="001696.html">[IRCServices] StartUp problems
 101 </A></li>
 102          <LI> <B>Messages sorted by:</B>
 103               <a href="date.html#1695">[ date ]</a>
 104               <a href="thread.html#1695">[ thread ]</a>
 105               <a href="subject.html#1695">[ subject ]</a>
 106               <a href="author.html#1695">[ author ]</a>
 107          </LI>
 108        </UL>
 109
 110 </body></html>