Since your users don't have email, it sounds like the plan is to use
the hint (and response) to directly gain access to the account. So
really you're creating two paths to sign in, and you're asking your
users to come up with two passwords instead of one.
First, consider dropping one of the two sign-in paths (i.e., just have
the main password, don't put any strength requirements on it like
minimum length, etc. OR just have the hint/response to sign in). The
path you're down has a lot of cognitive load to sign up (remember
username, create & remember password, create & remember hint and
Second, if showing the second password in plain text during sign up
isn't a concern, why not show the main password that way too (or
instead)? This should reduce the worry that you can't check if it was
mistyped during sign up by not having that "confirm password" entry.
Finally, if there's really not that much at stake, is a password even
necessary? This may be too drastic, but maybe not.
On Jul 10, 2008, at 12:29 PM, Steven Chalmers wrote:
> @ Jeremy White - Regarding availability of e-mail. > > Jeremy, you guessed correctly that these users do not have e-mail. > > I believe that the best way to justify my design is to consider the > following design criteria (which I should have included in my first > post): > 1) This is a low security risk application > 2) The users do not have e-mail > 3) We want to lessen the load on our internal help desk for password > resets.