Andreas Premstaller wrote:
> Bob Lord wrote:
> > Matthew Thomas wrote:
>
> >> * Why do you include fields for the number of characters, symbols,
> >> numbers, and upper-case characters in a password? Do you assume that
> >> the user can't count? Are these fields going to be updated onblur,
> >> in which case they'll be inaccurate while the user is typing? Or
> >> are they going to be updated as the user types, in which case
> >> they'll be distracting?
> >
> > It changes as you type. Try it out.
> >
> > Users choose weak passwords. But unless they get feedback on what's
> > "worse" and what's "better", they're not going to improve the quality of
> > their passwords. This is important because this dialog allows you to
> > change your "Master Password". The Master Password protects your web
> > site names and passwords if you select the "Encrypt Sensitive Data"
> > option. It also protects your private keys (if you have obtained
> > personal certs).
> >
> > I'm open to suggestions on how to give people real time feedback in a
> > way that's simple to understand.
>
>
> I think that the quality meter is enough feedback to the user about the
> quality of the password. A quality meter like this one is also used in
> NAI's PGP.
> I don't see the need to count characters, numbers, ... in a password. A
> user usually/hopefully chooses a password she/he can remember, and if
> the user can remember it, I guess she/he is also able to count the
> characters.
> If you want to tell the user how to choose as good password, maybe a
> section in the help explaining how you measure that is better.
Robert Bihlmeyer also suggested this approach, and I agree. The
quality meter is enough. We can add some text clearly explaining how to
choose better passwords.
> > Which brings me to another more general point: If you really want to
> keep all those parameters in the prefs ("those parameters" probably
> makes you understand that - as >90% of all other users I am not familiar
> with most of them), I hope somebody is prepared to write a rather
> extensive help section explaining them.
We already have extensive help which we will start to wire up later this
week or next week. When we rejigger some of the UI around to make it
conform to the rest of the client, we'll start hooking those help
buttons up.
> I really like NAI'S PGPpackage. You can work with it reading a very
> small part of the documentation, but if you are interested, you find a
> lot of background information in the help and documentation files.
>
>
> >> * What are all the checkboxes in the Cipher Viewer for? Why would I
> >> want to turn any of these off? How would turning them off help me in
> >> browsing the Web? ... Etc, etc.
> >
> > You would want to turn off a cipher if some clever math wiz was able to
> > find a flaw with it. This does happen from time to time. You might also
> > want to turn off the low-grade encryption ciphers to make sure you're
> > only using the high-grade crypto.
>
>
> How should a user find out that some clever math wiz was able to crack
> that cipher? Is mozilla/netscape/somebodyelse going to send an email to
> every user? The minority of users that have (a) the knowledge to care
> about this and (b) access to up-to-date information should also be
> technically savy enough to set one line in their prefs-file.
If someone were to break one of these ciphers, you'd read about it in
popular press along with alarmist quotes about how the future of
ecommerce is in doubt. You'd hear about it. :-) And you'd want a very
simple way of turning the offending cipher off.
>
> However, thank you for your hard work, the introduction of PSM2 has made
> browsing of secure sites (no, I do not know what technology they use)
> much more pleasant.
Thanks!
-Bob
--
Bob Lord
Director, Security Engineering
Netscape Communications Corp.
http://www.mozilla.org/projects/security/pki/
http://people.netscape.com/lord/jobs
