Re: Fwd: Password generation classes

Jonathan Kingston wrote:
> 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?

That will break when the need of a new credentialClass arises. Suppose
a new credential type may be needed because the old one can now be
broken. Increasing the length would be a trivial fix, but with fixed
classes, the server can't request that. You need all clients to upgrade
their browser.
(Allowing a range of classes can help with that, but is not a complete
fix, either)


I think the goal should be to create an algorithm defining the number
of «entropy bogobits» of a password candidate. Then the website would
just request that the password is at least of n bogobits (the spec
would obviously provide some recommendations, preferably with
associated constant names).


Nonetheless the above, I think we can't escape from character classes.
The website may be linked with a backend (eg. LDAP) which is where the
passwords are aactually stored, and the one vetting their
characteristics. As such, the website that follow it has little option
than rejecting the password for reasons like "not containing a symbol"
(which is a funny case since what each system considers to be a symbol
is usually undocumented).

Thus, a way to express those restrictions should be grudgingly
included. Then the password generator would adjust the length to comply
with the rules while keeping with the entropy fakebits required by both
the user and server.

On the other hand, I agree that having a maximum password length is
undesirable (and could often result in "it's no possible to generate a
password for this site that meets the security criteria"). No
application should be having issues with a password of "just" 250
characters. (There's that huge well-known software company that
truncated at 16 characters, but even they removed that limit)

Best regards

Received on Thursday, 1 October 2015 01:18:10 UTC