Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 16 Dec 2016 09:52:17 -0800
From: Jim Fenton <fenton@...epopcorn.net>
To: passwords@...ts.openwall.com
Subject: Re: proposed NIST guidelines on passwords

It should be clear that there is a security benefit from prohibiting
really obvious passwords like "Password1". But as I pointed out in slide
17 of the presentation, choosing dictionary size is a tradeoff between
effectiveness and frustration (user experience). The SP 800-63B draft
doesn't recommend a particular dictionary size.

Yes, we're mostly dealing with online attacks here. An 8-character
minimum is not sufficient for offline attacks against a hashed database
unless it is a keyed hash (and the key isn't breached).

The algorithms you are suggesting sound interesting. Please make this
comment when the public comment period opens early next year. I'll
forward the announcement when the comment period begins to this list for
those who aren't avid readers of the Federal Register :)

-Jim

On 12/16/16 1:21 AM, Martin Rublik wrote:
> Hi,
>
> thanks for the pointer, I quickly watched the video. The part relating
> to dictionaries caught mine attention and I have a few questions.  
>
> Don't you think that the dictionary check might be even more
> frustrating than the composition rules? After all, users probably
> won't know the entire dictionary. 
>
> As for comparing BadPassword -> BadPassword1 you could use
> something Levensthein distance or Needleman-Wunsch algorithm (simmilar
> to Levensthein distance with the difference that you can weight
> adding/removing a character), still the user experience might be a
> problem.
>
> What is the main purpose of the dictionary check? Should it be a
> protection against online attacks? 
>
> Martin 
>
>
>
> On Thu, Dec 15, 2016 at 6:13 PM, Jim Fenton <fenton@...epopcorn.net
> <mailto:fenton@...epopcorn.net>> wrote:
>
>     FYI, I gave a presentation at Passwords '16 Las Vegas about the
>     rationale for many of these changes:
>
>     http://www.slideshare.net/jim_fenton/toward-better-password-requirements
>     <http://www.slideshare.net/jim_fenton/toward-better-password-requirements>
>
>     Expect a new public comment period to begin early next year.
>
>     -Jim
>
>     On 12/15/16 6:58 AM, Martin Rublik wrote:
>     > Hi,
>     >
>     > NIST published new draft on Digital Authentication Guidline
>     >
>     >
>     https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-verifiers
>     <https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-verifiers>
>     >
>     > Summary related to passwords is following:
>     >
>     > - at least 8 chars minimum length
>     > - at least 64 chars should be allowed by application
>     > - printing ASCII, space and UNICODE allowed (the application should
>     > perform normalization, little worried about this one)
>     > - password hints should not be implemented,
>     > - passwords should be checked by the application against: passwords
>     > obtained from breaches, dictionary words, context specific such as
>     > username. These passwords should not be allowed / user should be
>     warned
>     > - no composition rules such as different character sets
>     > - no periodic change (unless a breach was detected)
>     > - mandatory encryption/hashing (PBKDF2 mentioned)
>     >
>     >
>     >
>     > Martin
>
>
>


[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ