[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD7EdQZ68ZdJ=nANuFsV9uJu+4dUSikWMUet4sG6M-OfBAj2eg@mail.gmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
