> the genuine user has to reset their password once it's locked out,
> and we would be looking at why it got locked out, but that will have
> problems with DOS attacks continually blocking access. Many of the
> third party sites I access follow that procedure.
Agreed, the "right" way to perform an account lockout mandates a
password reset after an out-of-band verification. Such a policy
combats timing attacks, because 3 or 5 attempts is too few even for a
very fortunate timing attack.
An implicit requirement, though, is that the password reset needs to
be random and permanent. If the user sets new passwords like
'MyOldPassword2' and 'MyOldPassword3' [1], then the attacker can
basically resume where they left off. The more lockouts that happen in
quick succession, the more pressure there will be to do these mild
modifications -- and also, there will be ever-increasing pressure to
allow the user to get back to work.
And how are you going to get the user back to work other than simply
turning off the account lockout policy for their account? And then --
presto! -- the attacker has simply used your own policy in order to
get you to turn it off (what OWASP calls Abuse of Functionality).
> I suppose most people will be reading a record and then getting PHP
> to do the comparison?
Some authentication recipes suggest that SQL comparisons be avoided
during authentication as an additional weapon against SQL injection.
Thus, yep, the values are fetched from a hard-coded SQL statement and
compared on the PHP side.
While not directly harmful, those recipes can be dangerous IMO b/c if
you sidestep really dealing w/injection in a "critical" query, you
might end up paying less attention in other queries that give an
attacker free rein once they are authenticated.
-- S.
[1] In our app, we always generate random passwords on reset and I
know from our logs that 99.9% of people just keep the random one. But
we also confront the reality that the "sensitive" account (superuser
type) may not be so "sensitively" maintained. That's the user who is
more comfortable going into their control panel and changing the
password to something "memorable." Thus they are actually *more*
likely to reuse the prefix of their old password.