CREDENTIAL: Support generation of passwords from LocalCredential

[jonathanKingston]

I think there should be flexibility in generating the passwords however there should probably be a minimum set requirement for passwords that the site can't change.

I suspect LocalCredentials could have a constructor/method which takes a dictionary of the following (examples):

• min-length: minimum length of password generated
• min-special-chars: minimum number of non whitespace and alphanumeric chars generated
• min-cycles: minimum number of algo cycles to generate the password
• requires-upper: generated password requires an upper-case char
• requires-numeric: generated password requires a number

However there will also need to be a way to declare an input with these parameters so that a user can indicate when they want a password generating to adhere to the websites security measures.
As mentioned on the mailing list pattern was suggested for this use-case however parsing regex is problematic.

[mikewest]

Marking this as future work for the moment; I think we need to agree on a minimum viable API before we start exploring this kind of thing. For instance, note that Apple supports a similar API on iOS8 right now, with basically no options. Is that enough? Maybe?

But let's work through the set of issues we already know about before picking up new work. :) Maybe we can pick this back up after FPWD.

[jonathanKingston]

Certainly worth picking up after FPWD however it is a failing that is impacting my current usage because our default passwords are more secure than most of the generated passwords out there so it causes a user interface issue which users seem to have already trained themselves to expect the passwords to always just work.

This is something that I am keen for password managers to pick up and as previously mentioned the approach so far is reverse engineering pattern which will work without creating this API however it is actually more work so I might suggest to LastPass and others that they implement a shim api for something as mentioned above to get a working example going to help give suggestions to the specification.

[jonathanKingston]

I'm thinking of making it the following:

dictionary GeneratedPasswordCredentialData : CredentialData {
  DOMString minLength;
  DOMString minSpecialChars;
  boolean requiresUpper;
  boolean requiresNumeric;
};

[Constructor(GeneratedPasswordCredentialData data), Exposed=Window]
interface GeneratedPasswordCredential {
};
GeneratedPasswordCredential implements PasswordCredential;

[jonathanKingston]

I feel the following is better than my above suggestions.

Credential classes

For a long time people have generated credentials which have restricted on length, special characters, non dictionary words and various ot
her techniques.

If a credential management system is used then the only considerations become the applications themselves and not what users are doing.

The considerations are:

• Storage capacity
• Complexity of credential
• Size doesn't impact system reliability

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.

[indolering]

This seems like a very strange addition to the spec, why are we letting site administrators determine the entropy of passwords? It would be better to assume mixed case, minimum length, digits, and special character requirements so you can account for it in the entropy estimation model. It might make sense to set a max-length or disallow certain character classes for backwards compatibility, but (IMHO) this just complicates the spec (and thus the security model) without adding any real value.