effect of bcrypt hash $cost on HTTP Basic authentication's login performance?

[Maxim Dounin]

Hello!

On Tue, Jul 02, 2019 at 05:55:01PM -0700, PGNet Dev wrote:

> On 7/2/19 5:23 PM, Maxim Dounin wrote:
> > On Sat, Jun 29, 2019 at 09:48:01AM -0700, PGNet Dev wrote:
> > 
> >> When generating hashed data for "HTTP Basic" login auth
> >> protection, using bcrypt as the hash algorithm, one can vary the
> >> resultant hash strength by varying specify bcrypt's $cost, e.g.
> > 
> > [...]
> > 
> >> For site login usage, does *client* login time vary at all with
> >> the hash $cost?
> >>
> >> Other than the initial, one-time hash generation, is there any
> >> login-performance reason NOT to use the highest hash $cost?
> > 
> > With Basic HTTP authentication, hashing happens on every user
> > request.  That is, with high costs you are likely make your site
> > completely unusable.
> 
> Noted.
> 
> *ARE* there authentication mechanisms available that do NOT hash on 
> every request?  Perhaps via some mode of secure caching?
> 
> AND, that still maintain a high algorithmic cost to prevent breach 
> attemtps, or at least maximize their efforts?

In nginx itself, the only authentication available is Basic HTTP 
authentication, and it implies hasning on every (authenticated) 
request.

To avoid hashing on every request one have to maintain a session, 
so hashing can only happen once per session, and this is not 
something nginx provides.  You can, however, implement it 
yourself, for example, using auth_request.

Note though that algorithmic cost might not be the best solution 
to prevent "breach attempts".  The only case when algorithmic cost 
is indeed matters is when hashes are leaked, and available for 
offline attacks (and if this happens, you have a problem anyway).  
In most cases you care about online attacks, and these can be 
effectively mitigated by limit_req (http://nginx.org/r/limit_req).

-- 
Maxim Dounin
http://mdounin.ru/