Fwd: Password generation classes

<gokoproject@gmail.com> wrote:

> On Tue, Sep 29, 2015 at 8:07 PM, Jonathan Kingston <jonathan@jooped.com>
> wrote:
>
>> As to create somewhat of a new topic diversion on this group I wanted to
>> table the discussion of password creation.
>>
>>
> The Credential management API at some point will need to allow users to
>> create passwords somehow.
>>
>
> Not sure if this is really within the scope of CM. Is "allow" the right
> term here?
>

Yup, I'm not sure what is. 'A feature of Credential Management will
generate passwords for the users.'


>
>> The core issues as I see it are:
>> - Sites create schemes that users can't understand
>> - Sites are under the illusion that limiting down the character set to
>> include x upper, x digits, and x special chars makes passwords much stronger
>> - Sites have a finite storage limitation
>> - Sites have a processing limitation
>> - Users are likely to pick bad passwords so some of these rules, limits
>> and design choices have happened because of that
>>
>
> This is true and I hate that every organization has its own scheme because
> everyone claims "oh yeah because this is our requirement."
>
> I am not understanding the actual proposal. Is this proposal about the
> ability for a website to inform UA that it only accept one or more
> password/credential classes and UA must reject if the password does not
> fulfill the requirement? or are you also proposing that CM should implement
> password generation (as what follows in the 3rd part of your email).
>

My suggestion is that the CM should implement the password generation based
upon the class specified. The UA could step I guess but that wasn't part of
my initial thinking.


>
> I just want to say that IMO user-agent should refrain from deciding what
> is better for the end-user and for the website, instead, it should just
> accept what the website wants. But this means we are back to square one -
> every website will come with its own requirement. I think allowing
> user-agent to reject input instead of having someone to write javascript to
> remind user "this is bad" would be helpful (but I am not sure the UX part
> of this).
>
>
The advantage of the CM creating a password is ultimately the website can
always reject a password however if we limit the password generation
choices to a set of approved classes the website can check if it meets the
requested strength as it always does. However we force the websites hand
somewhat in only opening up x number of options to pick from.

So in the comment that I linked to it sets out some example classes that we
could create as 'standards' much the same way the cyphers passwords use
become the storage shape in a database.
This reduces the set of things a website can specify when it is using the
Credential Management API which gives many benefits:


   - The credential manager can make UI choices based on the credential
   class that they use
   - This may include on multiple uses warning that a password is stale
   - The website gets a known shape back
   - The credential manager implements specified classes which are known to
   be strong



For brevity here is the part of the comment that matters:

So my suggestion is 'credential classes':

   - Checks for credential variance (chi, trigram, quadgram)
   - Lengths relating to storage and usage
   - Example use cases for each class
      - suggested use times
      - usages etc

I'm not sure on what these would be to become useful however it might look
like this:
class 1

   - chi variance of over 5
   - length over 5 and under 20
   - Example use: Single use token

class 2

   - chi variance of over 25
   - length over 100 and under 200
   - Example use: credential that doesn't change for a year

A application would inform the credential manager what class of credential
they require, this prevents the credential manager sending things that the
app can't cope with however also prevents the site making bad choices.

The credential manager would also have the ability to inform users of
applications using weak credentials for longer time periods than suggested.


---

This might for example look like:

navigator.credentials.get({ "password": true, credentialClass: 2 })


The problems with this proposal so far are:
- I don't like numerical classes
- How do we deprecate older classes?
- Should asking range of classes be possible?