Re: Short report from testing the WLUS 1.2-27
søndag 25. april 2004, 19:43, skrev Andreas Schuldei:
> So what would you think? What *should* happen? right now i
> envision the process like this:
>
> fileimport with weak passwords and double and existing usernames
> leads back to the column selection page, with the weak passwords
> and the boguous usernames marked in the table and a button saying
> "ok, those are bogus, create better ones for me in the process"
This is an generic problem that repeats itself whenever users with
password is created. There is a major design change from WLUS 1.2-25
until 1.2.28. Thats the auto-generating password algorithm with
checking for weak passwords. This really turn some of the functionality
upside down, and trigger some need for escape methods for the user.
All this was brought to the light when introducing a major change in
the password-generating function. The general idea is to strict up the
passwords, and take the choice away from the ICT-manager. This is
general a good idea, that is to enforce stricter procedure to make
passwords. But some of the design in the user-interface tells an other
story. The GUI is wide open to make your own choices when it comes to
user-names, password and so on -- when doing file-import -- or when
creating common password, when creating one or more users from the
GUI.
There is an short path, a long path to solve this, and get rid of the
ambiguity. It's also a third. That is to let the system pick a
auto-password for every user. The GUI don't support that, because of
the suggested Common Password-functionality.
1. The short path is to accept what the GUI tells the users 110%. When
the user says override the built in password-generation algorithm,
just do that. Then you also has to override the "generate better
password in stead"-algorithm. This also overrides the pre-configured
setting in the config-panel for WLUS.
2. The longer path is a way to second guess the user. This is what
Andreas suggests, to return to the "start" position, and give the
ICT-admin better and stricter password(s) to choose from. The
program suggests what the users should select when the password is
to weak. The GUI suggest to the user a stronger passwords to use,
and what the user-name should look like. This has to be consistent
in the GUI, both when generating users from file or from the "make
one-or-more users"-functionality in the GUI.
3. The third path was almost the functionality I observed in 1.2-27 of
WLUS. There is no way of overriding the password-generating
algorithm. It just auto-generated passwords even if the GUI told
the opposite story.
A regular user will immediately reject the third point (3.) of
programing the GUI. This is because of opposite functionality, the GUI
tells one story, but second guess the users choice by default. This is
not good, and is an invitation to make the user angry at the
program. If this program-functionality is chosen, the "Common
Password" choice shold be removed. Also the password-from-file should
be removed as an option.
The first choice (1.) is the obvious choice. That is what the GUI
tells the users, and that is what the users should get.
The second choice (2.) is probably the best way. This is the idea from
Andreas where the user get a feedback with possibilities to choose
from when creating new users. Then the ICT-admin can select stricter
password and other users names thats already taken.
The problem with the second alternative is that it should be done more
consistent. This because of three requests.
4.1 The first ones was from Ralf that wants to edit the naming
rules. If I have understood this right, he wants to have a
password-config-look-alike thing with hierarchy file-system, or
prefix on some of the class-names. To get a class-folder can also
be done today with creating a "user" with the name on the
school-class, where every pupil in that class is in the
school-class-folders group. So in a way this is solved with
thinking a bit different and UNIX-like with using
group-functionality (gid) as they should be used.
4.2 The other one is the tightening of the passwords. This is in a way
coupled to what is pre-configured in the config-WLUS-panel in
Webmin. If the ICT-manager has suggests to weak passwords, the GUI
presents new and stronger passwords. The GUI could also present the
password that is to be replaced.
4.3 When doing 4.2 this should be consistent everywhere, both when
creating new users directly from the GUI, or from the file. This
is, as Andreas suggested, an extra step:
> note that this is some more coding (which i started already) and a
> somewhat bigger change. not sure how intrusive it will be.
All this "in consequence of" strict password-generating, and the
"Common Password from GUI/Preselected password from file".
So the brute force here is to go for alternative 1. Doing exactly what
the GUI tells, with overriding the auto-password-generating when
ICT-admin select "Common Password/Preselected password from file".
The other way is to lett the GUI suggest tighter password when the
ICT-admin has selected to weak ones :-). This is, as Andreas pointed
out, more programming.
How to prioritise?
The easiest way is to select option 1. It's mostly 5 days to release
the WLUS for major use. If the option 2. is almost finished, it's easy
to debug from a usability point of view. I think Andreas know whats we
are up against with testing this now. What do you think?
- K
Reply to: