| |
In lugnet.people, Todd Lehman writes:
> In lugnet.people, Kevin Loch writes:
> > In lugnet.people, Todd Lehman writes:
> > > Disable accounts on repeated fails and you make it trivial to DoS someone.
> > > Disable IP addresses and you lock out the innocent on shared proxy servers.
> >
> > Not if you only disable loggin in as that user from that ip.
>
> Is there a way to tell if a given IP address is a shared proxy server or not?
> If you disable login access as one user from a given IP address, then you
> effectively disable login access as _all_ users from that IP address, because
> it would be just as trivial to DoS everyone in succession as it would be to
> DoS a single person. In other words, disabling logging in as a user from a
> given IP address still locks out the innocent on attacks coming through shared
> proxy servers.
>
>
> > I think a minimum of 6 characters is a good limit. It's the character
> > diversity that is causeing problems.
>
> Crack programs use dictionaries.
Um, yes I know that. It's also possible to generate "human random"
dictionaries that speed up brute force of "strong" passwords where
users are forced within certain limits. BTW, I wonder what the keyspace
is of all (8 chars and less as typical) LUGNET filter approved
passwords is? Remember the more you restrict the keyspace the less
secure it is mathematically.
>
> > Also, you could make failed attempts
> > take a few extra seconds to further delay brute force attacks.
>
> I'm kinda wary of that because it is so trivial for a potential attacker to
> fork multiple copies of itself and work right arond the delay as if it wasn't
> even there. If you delay 3 seconds, then a cracker program just forks extra
> copies of itself and works in parallel. So sleep-delays over HTTP don't count
> for much. On the other hand, a server could probably get around that by
> making a password mutex for each IP address, whereupon failure the process who
> owns the mutex would delay some number of seconds before releasing the mutex
> to the next process. That way, no HTTP process checking a pw could step
> around any other.
>
>
Problem solved (login locking).
> > You cold even make successful logins take a few extra seconds just for good
> > measure.
>
> Cookie == micro-login. Successful logins have to be as fast as possible.
>
>
cookie=no dely, unless you are concerned with people hacking cookie/ip pairs.
but successful user/pw login should be delayed exactly the same as user/pw
failiure. If you really wanted to be slick, drop successful and unsuccessful
logins into the homepage with no indication of login status. Give successful
and unsuccessful logins similar cookies. Of course that would impact
the user experience so you wouldn't do that :)
> > BTW, no password is required to post right?
>
> Right.
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Re: LUGNET Memberships
|
| (...) Is there a way to tell if a given IP address is a shared proxy server or not? If you disable login access as one user from a given IP address, then you effectively disable login access as _all_ users from that IP address, because it would be (...) (24 years ago, 25-Sep-00, to lugnet.people, lugnet.admin.general)
|
113 Messages in This Thread:
(Inline display suppressed due to large size. Click Dots below to view.)
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
