httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neal Rhodes <ne...@mnopltd.com>
Subject Re: [users@httpd] Could Apache login support CAPTCHA and lockout?
Date Sun, 09 Oct 2011 21:39:40 GMT

Yes, thank for the responses and clarification.   True the Basic Auth
isn't really a login, as there is no logout per se. 

One would suppose from the responses that using .htpasswd and Basic Auth
is really a lousy approach to security, since an attacker can just wail
away indefinitely trying repeatedly, unless one configured something
like fail2ban to cut off repeated attempts.   I was just looking to
improve on that if possible. 

On Thu, 2011-10-06 at 22:54 +0200, Jeroen Geilman wrote:

> On 2011-10-04 14:44, Neal Rhodes wrote: 
> 
> > We have bunches of web applications which use the regular Apache
> > login protection, 
> 
> 
> Do you mean HTTP Basic Auth, as defined in RFC 2616 ?
> 
> 
> > and they won't run unless REMOTE_USER is set by the Apache login.   
> > 
> > 
> >         <Limit GET>
> >         require valid-user
> >         </Limit>
> >         
> >         <Limit POST PUT DELETE>
> >         require valid-user
> >         </Limit>
> >         
> >         AuthName O-Visitor
> >         AuthUserFile /usr/appl/cgi/.htpasswd
> >         
> >         AuthType Basic
> >         
> 
> 
> 
> Yes, this is HTTP Basic AUTH.
> It says so right there.
> 
> 
> 
> > Looking at improving security, it would seem that it would be much
> > harder to conduct brute-force attacks on these systems if we could
> > configure Apache login to do two things: 
> 
> 
> You can't.
> There is no "login", just an Authorization: header which has to be
> sent for every page that requires it.
> 
> 
> >         A. Present the CAPTCHA style validation prompt as part of
> >         the login, to make it difficult for scripted attacks to
> >         proceed;
> >         B. Lockout an individual username in the .htpasswd file
> >         after X failed login attempts.
> 
> 
> Actual login-ness (a state of logged in being different from a state
> of not being logged in) must be achieved through non-HTTP means,
> possibly supported by HTTP features such as cookies.
> 
> 
> 
> -- 
> J.

Mime
View raw message