[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ9ii1EGygAB0khFmkaNJMUFZdK1unRndVuW+6u5Pva1BgV27A@mail.gmail.com>
Date: Tue, 10 May 2016 13:26:09 -0400
From: Matt Weir <cweir@...edu>
To: passwords@...ts.openwall.com
Subject: Re: Password-Manager Friendly (PMF) semantic markup
I hate how skeptical this sounds but ... what does everyone think the
likelihood of the values represented in this field represent the password
policy that is currently in place?
Many of the disclosed databases I've seen are a true mishmash of different
password policies and underlying technologies used over time. What
mechanisms do you think could be implimented so that this data field
matches up with the true requirements, and how should password managers
fail gracefully when these fields are incorrect?
My concern is that such a mechanism could cause more user frustration than
it solves due to website owners not keeping their info up to date, and that
frustration would be (incorrectly) focused on the password management
programs themselves.
Matt
On Tue, May 10, 2016 at 1:10 PM, Royce Williams <royce@...hsolvency.com>
wrote:
> On Tue, May 10, 2016 at 8:27 AM, Jeffrey Goldberg <jeffrey@...dmark.org>
> wrote:
> > On 2016-05-10, at 11:17 AM, Jim Fenton <fenton@...epopcorn.net> wrote:
> >
> >> On 5/10/16 7:12 AM, Royce Williams wrote:
> >>>
> >>> We might include not just password complexity rules, but other
> >>> qualities of authentication, including:
> >>>
> >>> - Password aging policy
> >>> - Supported 2FA/MFA methods
> >>> - Supported types of federation (log in with Google, Facebook, etc.)
> >>> - Hashing method and parameters (salt, rounds, etc.) -- a signal of
> >>> (in)competence ;)
> >>> - SAML awareness? (not sure what's possible/useful here)
> >>>
> >> Ugh, let's not give them a place to express a password aging policy when
> >> the only sensible answer is "no aging". I'd rather that we didn't
> >> encourage password complexity (composition) rules either.
> >
> > If a site or service has such rules, then it would be good for password
> > managers to know about them.
>
> Indeed.
>
> >> Hashing method and parameters: How is this information actionable by
> >> password managers?
> >
> > I agree. While we should encourage sites to document such things, this
> > isn’t the place for it.
>
> I guess what I'm suggesting is that passwords as data entry are a
> subset of authentication parameters, and creating a specification that
> covers more of the spectrum can open up benefits that we cannot
> foresee. The underlying password hashing method might influence what
> passwords are chosen/generated. (I'm not going to use "correct horse
> battery staple" if the underlying storage method is descrypt, for
> example).
>
> And I'm not suggesting that hashing method would be required. I'm
> suggesting that we define it, but make it optional.
>
> Royce
>
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.
