The problem I see with this is that if the users are not going to use
cryptographically strong passwords in the first place, what would make
you believe that they will use one of the randomly generated passwords.
The big problem that exists with those passwords is that end users (in
my experience) do not like those type of passwords, and will just come
up with their own favourites.
As well, if you provide suggested passwords, there is more potential for
abuse if someone gains access to that code, or is able to watch the
"suggested" passwords.
But, I think most importantly, if users are not going to use secure
passwords in the first place, they are not going to use these suggested
passwords either.
.....Kelly John Rose.....
James Barkley wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A user authenticates with a username/passwd and you not only give the
user the option to change his/her password any time they want but also
make it mandatory that they change their password at least once every
so often (e.g. 6 months). You know that users are not good at
choosing good passwords, but you happen to have a good application
module for generating random strong passwords. So, when the user is
at the change password page and about to type in "Mets4Ever" as their
new password, why not give them a list of 10 or so cryptographically
strong, randomly generated passwords as suggestions for them.
Assuming you are using https, then this seems like reasonable
security... or am I missing something?
- -Jim Barkley
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
iD8DBQFCX2sJVtbq2E0xxN0RAu/qAJ9IniLfMUhKv2UpSweiXVfQn/wGRwCbBNQt
zPNrsUoEcHrAlvIqbunriPM=
=EYEs
-----END PGP SIGNATURE-----
