On 13-07-26 01:26 PM, McClenon, Brady wrote:
Agreed.  We have relatively short DHCP leases for students and our
wireless clients.   I also wonder about cellular networks.  Does each
phone get a public IP, are they NAT’ed or some other method in which
blocking one IP address could affect many users?

Hmm, the cell network issue could be a problem with IP blocking. But, one might still be able to come up with a proper frequency and expiry time to mitigate this issue.

And yes, I think cell networks usually proxy their requests. And I think my provider even proxied HTTPS requests through the CONNECT method. It's all vague now. I haven't used connections through my cell phone in a long time.


Brady McClenon

Senior Server Administrator

Applications Research & Development

Information Technology Services

SUNY College at Oneonta

607-436-3203

“Quotes found on the internet are not always accurate.”  - Abraham Lincoln

*From:*Scott Battaglia [mailto:[email protected]]
*Sent:* Friday, July 26, 2013 2:50 PM
*To:* [email protected]
*Subject:* Re: [cas-user] cas throttling

I don't believe CAS2 ever had that feature enabled (if they did there is
a 99% chance CAS3 would have launched with it).

IP-based blocking is not always accurate depending on your environment.
  You could accidentally block a huge number of people because of one
very bad person.


On Fri, Jul 26, 2013 at 1:31 PM, Trenton D. Adams <[email protected]
<mailto:[email protected]>> wrote:

    On 13-07-26 10:13 AM, Trenton D. Adams wrote:

        On 13-07-25 02:48 PM, Andrew Morgan wrote:

            On Thu, 25 Jul 2013, Trenton D. Adams wrote:

                Hmm, it doesn't seem reasonable for an authentication
                system to not be
                throttled.  Any ideas on why it's not on by default?  I
                know it was
                for CAS 2.

                Can we get it enabled by default going forward?


            Our CAS system uses our LDAP service to handle
            authentication, and our
            LDAP service already has a password policy with handles
            lockout after X
            number of failed authentication attempts.  Additionaly, we have
            different password policies for different categories of
            users ("higher"
            security accounts allow fewer failed authentication attempts).


        How does your LDAP support this feature?  Is it based on
        account?  if
        so, that seems rather inferior to IP based throttling.  If for some
        reason I was able to gain access to all of the LDAP ids (temporarily
        maybe, not as unlikely as one might think) I could use a dictionary
        attack, and attempt the same password on every account.  That
        wouldn't
        trigger an account based lock out.

    Sorry, I've always had attention problems.  You already stated it
    was based on account.  But, that does seem rather inferior to IP
    based blocking, don't you think?  I remember CAS 2 being something
    like 100 repeated attempts in quick succession was deemed as an
    attack, and that IP was blocked.


        And, if LDAP does IP based throttling, that wouldn't work too
        well with
        CAS, as it would block everyone.


            We don't really want CAS to handle the lockout/throttling
            for us, so I
            would prefer it wasn't enabled by default.  However, it
            isn't too
            difficult to overlay our own configuration with Maven, so we
            can remove
            it if the defaults do change.

            Thanks,
                  Andy



    --
    Trenton D. Adams
    Senior Systems Analyst/Web Software Developer
    Navy Penguins at your service!
    Athabasca University
    (780) 675-6195 <tel:%28780%29%20675-6195>
    :wq!

    --
        This communication is intended for the use of the recipient to
    whom it
        is addressed, and may contain confidential, personal, and or
    privileged
        information. Please contact us immediately if you are not the
    intended
        recipient of this communication, and do not copy, distribute, or
    take
        action relying on it. Any communications received in error, or
        subsequent reply, should be deleted or destroyed.
    ---

    --
    You are currently subscribed to [email protected]
    <mailto:[email protected]> as: [email protected]
    <mailto:[email protected]>
    To unsubscribe, change settings or access archives, see
    http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed [email protected]  
<mailto:[email protected]>  as:[email protected]  
<mailto:[email protected]>
To unsubscribe, change settings or access archives, 
seehttp://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user



--
Trenton D. Adams
Senior Systems Analyst/Web Software Developer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!

--
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to