Password set/change error reporting

[Marcus Watts]

"Paul W. Nelson" <nelson at thursby.com> writes:

...
> Currently, the version 2 draft proposes a single error code to handle policy
> issues:
> 
> >      KRB5_KPASSWD_POLICY_REJECT      8 new cleartext password fails
> >                                        policy; the result string
> >                                        should include a text
> >                                        message to be presented to
> >                                        the user.
> Returning a string (current method) is OK, but makes it very difficult for
> writing internationalized/localized software.  The person changing the
> password might be using Japanese as their language, and the kdc/kpasswd
> server might be serving a multi-lingual community.
> 
> I would like to see the version 2 draft specify extended error codes that
> enumerate common reasons for a password change failing.  Here are some of
> the codes I would like to see:
>  
>     a) Password too short
>     b) Password not complex enough
>     c) Password cant be changed yet (too soon)
>     d) Password was used previously
> Others??
...

The problem with this is that it's both too detailed, and not detailed enough.
For instance, a common password policy at many sites is to require one
or more non-alphanumeric characters.  Here at UM, we have logic that
checks several dictionaries, and the length check depends on the
character set richness of the password.  We don't do any checking for
"bad" characters, but non-7 bit ascii is probably a bad idea.
	[ We also don't check for
		+ .
	in passwords or passwords > 16 characters, even though MGS cares...:
		http://www.merit.edu/michnet/dial-in/numbers/mgs.html
	(Arrgh!)
	]

So, we could add:
	e) password too long
	f) password matched dictionary word
	g) password does not contain non-alphanumeric characters
	h) password contains one or more unacceptable characters

Now, with erors a) and e), it might be nice to tell the user
what an acceptable minimum or maximal length is.  With errors
g) and h), it might be nice to tell them what characters were
acceptable or unacceptable.  But this isn't possible with numeric
error codes.  So, numeric error codes aren't detailed enough.

>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? ]

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... )

				-Marcus Watts
				UM ITCS Umich Systems Group