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 10:21:20 +0100
From: Martin Rublik <martin.rublik@...il.com>
To: passwords@...ts.openwall.com
Subject: Re: proposed NIST guidelines on passwords

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> 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
>
> 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
> >
> > 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