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.
