[Cryptography] NIST SP 800-63-3

[Arnold Reinhold]

> On Aug 14, 2017, at 6:04 AM, Jerry Leichter <leichter at lrw.com <mailto:leichter at lrw.com>> wrote:
> 
> Two comments on this:
> 
>> o Limiting the rate and number of failed attempts (100 max) before a successful authentication.
> What happens after the 100 failed attempts?  As has been pointed out many times in the past, locking out the account gives an attacker a simple denial of service attack.
> 
> I've always liked the VMS approach - dating back to the 1980's:  After some threshold of incorrect attempts within a defined period (say, 5 within 2 minutes) is reached, the account is put into "evasion mode" for a random period of time between (say, 2 to 10 minutes).  In evasion mode, *all* passwords are rejected.  As long as attempts to log in continue, evasion mode is extended.  Once they stop, evasion mode times out and the correct password will work again.  Yes, denial of service is possible - but the attack has to continue indefinitely.
> 
>>  “In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier.
> This has a downside:  It may make it more difficult to recover from a lost password.
> 
> A system I work on stores passwords suitably one-way hashed.  The way the system is structured, there's relatively little reason for the administrator to have to log in - though it does happen now and then.  Our support guys receive a significant number of calls from admins who's forgotten their administrator password.  Assuming they haven't also forgotten the root password on the box :-), we can get them back in operation by inserting a known hashed password/salt value into the password file.  Were we to also encrypt using a secret key, this would be much harder.
> 
> Yes, we already have a secret key for other purposes; and, yes, we could presumably write some code to generate a new admin password from it.  FYI, we use the secret key for a related, but different, purpose:  As part of encrypting customer information that we don't want to see in diagnostic uploads.  Our diagnostic procedures never look at the area where the secret is kept, so even though we get encrypted copies of some of their sensitive information, we can't decrypt it.
> 
>                                                        -- Jerry
> 

Here is what NIST SP800-63B says re your first point:

"5.2.2 Rate Limiting (Throttling)

When required by the authenticator type descriptions in Section 5.1, the verifier SHALL implement controls to protect against online guessing attacks. Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100.

Additional techniques MAY be used to reduce the likelihood that an attacker will lock the legitimate claimant out as a result of rate limiting. These include:

	• Requiring the claimant to complete a CAPTCHA before attempting authentication.

	• Requiring the claimant to wait following a failed attempt for a period of time that increases as the account approaches its maximum allowance for consecutive failed attempts (e.g., 30 seconds up to an hour).

	• Accepting only authentication requests that come from a white list of IP addresses from which the subscriber has been successfully authenticated before.

	• Leveraging other risk-based or adaptive authentication techniques to identify user behavior that falls within, or out of, typical norms.

When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts for that user from the same IP address.”

That would seem to include the VMS approach, unless VMS was silent about it's lockout, which I think users would find extremely obnoxious. Presumably the NIST-recommended throttling would start long before the 100 limit was approached. Other methods should, imho, include sending email to the account holder after a few fails and allowing a help desk to temporarily reset the lockout time, allowing a locked out user to enter the correct password immediately. Another related measure I would include is not counting a blank password or an entry the same as the previous entry as failed attempts, since they are of no benefit to an attacker and represent common user errors (e.g. caps lock on). 

As for your second point, I think the dangers posed by inadequate security in storing password validation data have reached such a level that they overwhelm any concern about requiring some new tools for password reset.

Arnold Reinhold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170814/da9c7973/attachment.html>