Password set/change error reporting

[Nicolas Williams]

On Fri, Apr 04, 2003 at 02:58:26PM -0500, Marcus Watts wrote:
> >From a program standpoint, none of this matters.  With any sort
> of automated system to select or set passwords (such as uniqname
> here at the University of Michigan, or batch account creation processes
> used at many institutions), it doesn't matter to the program what
> the error was.  It failed, a human needs to see the error message,
> and there's nothing more the program can do.  The main usefulness
> of the error code is to distinguish between conditions the program
> *can* make use of -- such as deciding whether the remote server
> is down (and the operation might succeed later), some sort of
> program error (which ought to be logged for a programmer) and some
> sort of user error (which might be correctable by an administrator
> or local user.)  So, so far as most programs go, KRB5_KPASSWD_POLICY_REJECT
> is about as detailed as it's worth getting.  The english text
> that SHOULD accompany this can go into more detail about why
> the password wasn't acceptable or how to fix it.
> 
> The other use of numeric error codes, of course, is for
> nationalization.  But really, this is a bad way to handle it,
> because it's not clear how you would translate potential per-site
> policy errors ("Do not use + or . in passwords") or ("You may not
> use swear words in passwords") into a universal numeric error code.
> [ Of course, this kind of begs the problem that since the server
> doesn't know the user's locale, how can the server generate useful
> english text? ]

IMO:

a) The protocol should have the server communicate the policy errors as
   human-readable text to the clients, though first

b) the clients should communicate a list of RFC3066 language tags
   representing the languages understood by the actual users so that

c) the server should perform all localization and tell the client which
   language it localized into.

d) Such strings should be Unicode 3.x encoded in UTF-8, no normalization
   required (the client can normalize in the process of displaying the
   text).

This is what the soon to be published v2 draft will specify in this
respect.

The language negotiation will take care of L10N and the use of Unicode
and UTF-8 will take care of I18N.

No more than one generic policy rejection error code is needed.

> Personally, I don't like to go into a lot of detail about
> why passwords weren't acceptable.  Telling users that
> passwords must be 8 characters or more is (I think) more
> or less a guarantee that most users will pick passwords
> that are *exactly* 8 characters.  I'd rather give them
> a less specific error, like:
> 	Your password was too obvious
> than something that encourages people to stick right
> at the limit of the program's pickiness:
> 	Your password must be 8 or more characters and contain
> 	at least one non-alphanumeric character.
> ( which probably guarantees most passwords will be exactly
> 8 with exactly one non-alphanumeric... )

One benefit of letting the server perform localization and NOT having a
multitude of error codes, one for each imaginable policy violation, is
that site administrators can make their own error messages and
associated l10n message catalogs.  Site admins could even make their own
policies, as simple or complex as they like, provided that implementors
provide a server-side hook for 3rd party password policy checkers.

Cheers,

Nico
--