All posts in the topic Password Reset (Short link)
Summary
- There are 16 posts — by 4 authors — in this topic.
- Latest post made by Michael JasonSmith at 2008 Feb 15 02:32 UTC
| From | File | Date |
|---|---|---|
| Michael JasonSmith | password-reset.png password-reset.xcf.bz2 | 2007 Sep 25 02:36 UTC |
| Michael JasonSmith | password-reset.png password-reset.xcf.bz2 | 2007 Sep 25 03:56 UTC |
Richard, Dan, Alice and myself have been thinking over how registration, login
and passwords should work with GroupServer, to make the entire process easier.
Below is a reworking of what the help for the Password Reset would look like
with the new system.
Resetting Your Password
To reset your password, carry out the following.
1. Click Reset Password on the login page. The Reset Password page
will be shown.
2. Enter the email address that you wish to use, with your online
groups on GroupServer, in the Email Address entry box. If you have
more than one address registered with GroupServer, enter your
preferred address into the Email Address entry box.
3. Click the Reset button. An email message, containing a link to the
password reset page will be sent to you.
4. Click the link in the password-reset email message that has been
sent to you. The Set Password page will be shown.
5. Enter your new password in the first entry, and repeat the
password in the second entry.
6. Click the Set Password button. Your profile page will be shown.
Note: Administrator Password-Reset
Some administrators can reset passwords for group members. If
this occurs, you will receive an email message informing you that
your password has been reset. From this message, you can carry
out the tasks 4–6 above.
The biggest change is to what we send out: a link to set the Set Password page
rather than a new password. The link would contain a unique ID, which would log
the user in, so he or she could set the password. Linking the user to the Set
Password page should encourage the users to set a password that he or she can
remember :)
Administrators get the ability to reset passwords, as described in the note
above. The message the user will get in this circumstance will be slightly
different, as it would contain the name and email address of the administrator
who reset the password, and a link to the email address of the privacy officer
of the site.
Do you all think that sending out a link to the Set Password page is a good
idea? Do you prefer sending out passwords?
Sounds good, Michael.
> 2. Enter the email address that you wish to use, with your online
> groups on GroupServer, in the Email Address entry box. If you have
> more than one address registered with GroupServer, enter your
> preferred address into the Email Address entry box.
How will the system respond if the user enters an email address that is
not known by the system?
How about an email to the address submitted informing the user that the
address is unknown to the system, and suggesting that they try one of
the following three options.
1: Reset their password (no account will have been affected at this
stage) by entering one of their other email addresses on the Reset
Password page.
2: Request that the group administrator add the new email address to the
user's profile.
3: Click a link, or reply to the email to confirm the creation a new
account.
I like your suggestion, Dan. I am unsure of the particular order, but that is
easy to change ☺
To give people an idea of just how simple I am aiming to make the pages,
below is a mock-up of the first password-reset page (in PNG format for
viewing, and GIMP XCF-format for editing). It contains the following
elements.
* A page title.
* Instructions that no one will read, but I feel ethically obliged
to provide.
* A text-entry box that has an associated title and icon. The icon
should give an extra hint to those who missed the title
* A Reset button.
* A link to the context-sensitive help.
Are there any elements that I could remove?
The following files were added to this topic:
I like it a lot. The only thing I would change is the title: I prefer
the action of "Reset Password" to "Password Reset", which has always
seemed odd to me.
I like Reset Password more too: it gives a nice repetition to Reset down
the left-hand side of the page
The following files were added to this topic:
Richard and I were discussing the resetting passwords on the telephone, and we
decided that it makes more sense to send the password reset message to *all*
the users address, not just the one he or she entered. What do others think?
I have added the prototype Reset Password page to this group http://groupserver.org/groups/development/reset_password_prototype It is a non-functional prototype, but does use Zope formlib to render itself. There are two minor alterations that I need to do: 1. Highlight the required from-fields, and 2. Make the text-entry a lot wider. Both require CSS changes; as we are in the middle of changing how we do skinning, I did not want to change the style sheets! Baring the two changes I mentioned, are there any comments about the page? To answer my previous, question http://groupserver.org/r/post/6NJ1Dsr427ELOoiYNwSLwr the password reset message will go to all the user's email addresses.
I have added a prototype Set Password page to this group http://groupserver.org/groups/development/set_password_prototype It is very similar to the existing Change Password page, which is found in every user's profile. However, I am concerned about some of the language used on the page, and the restrictions that we should place on passwords. For the second password-entry, I used “Confirm Password” as the label. What do you all think of this label? I have also seen * “Repeat Password” (GroupServer 0.x), * “Retype new password” (GNOME, Wikipedia), * “Password (again)” (LiveJournal), * “Confirm” (Facebook), * “Confirm new password” (Google) and * No label at all (Slashdot). From the above sample, I am reasonably confident that there is no standard label. I also suspect that most people will fill out the second box as a matter of course, regardless of the label. However, there is no harm getting the details right ☺ My second concern is what restrictions, if any, do we place on the password? Currently, the JavaScript embedded into the page ensures that the password is set to something, so no blank passwords are allowed. However, we could ensure that the password contains at least one number, a mixture of upper and lower case, and cannot be cracked by the standard tools. Alternatively, we could use a "strength metre", like Google, to rate the password. I am against placing onerous restrictions on passwords, because that will annoy users. I also dislike the meter idea because it will be confusing to those who are not familiar with security, and not help those who are familiar with security. However, I am willing to be convinced otherwise on either count ☺
On Mon, 2007-10-29 at 12:48 +1300, Michael JasonSmith wrote:
> My second concern is what restrictions, if any, do we place on the
> password? Currently, the JavaScript embedded into the page ensures
> that the password is set to something, so no blank passwords are
> allowed. However, we could ensure that the password contains at least
> one number, a mixture of upper and lower case, and cannot be cracked
> by the standard tools. Alternatively, we could use a "strength metre",
> like Google, to rate the password.
I think I prefer the strength meter. I don't believe it will be
confusing to those who are not familiar with security ... people are not
familiar with security because they don't have it pointed out to them
very often. I think people will generally 'get it' anyway. For those
that are familiar with security ... well, it's an interesting novelty to
play with.
I think that password enforcement is *bad*: we want people to choose a
password they remember, and that won't cause them to have to use the
password reminder everytime they visit the site, and that is
commensurate with the security required for the site.
I will create a enhancement-ticket in Trac, to remind us to create a
password-strength metre ☺
Michael,
'Confirm password' seems succinct and unambiguous to me.
I agree that we should not place onerous restrictions on passwords. I
think that a strength meter, if well-done would be kinda fun, for people
with all levels of familiarity with security (geeks could compete for
the highest score). This, and the chance to usefully educate people
would mitigate the confusion that would be caused for some. I suspect
that most people do not perceive a high security risk over access to
GroupServer sites. They just want a password they can remember. So is it
worth us going to the trouble of adding the meter?
As we are requiring passwords to be non-blank, we have the opportunity
to require them to be of a minimum length (say 6 characters), without
being onerous. Does that create enough strength to be worth considering?
And are all those commas (even the one in "messages, to") necessary?
For now I am favour ensuring that the password is set to *something*, and
leaving off any other restrictions, such as ensuring the length of the password
is at least six characters. In many ways, I would prefer a five-letter mixture
of upper and lower case Latin letters, numbers and punctuation to a
seven-letter word (such as michael ☺).
I have attacked the introductory text of the Set Password page, and it is a bit
shorter, and has fewer commas.
On Tue, 2007-10-30 at 13:36 +1300, Michael JasonSmith wrote:
> For now I am favour ensuring that the password is set to *something*,
> and leaving off any other restrictions, such as ensuring the length of
> the password is at least six characters. In many ways, I would prefer
> a five-letter mixture of upper and lower case Latin letters, numbers
> and punctuation to a seven-letter word (such as michael ☺).
Yes, agreed. Anything else is a refinement. I'm always in favor of
education rather than enforcement, FWIW.
The prototype Set Password page now sets passwords. http://groupserver.org/groups/development/set_password_prototype I have restricted the page to authenticated users, as it makes no sense to set the password for a non-authenticated user.
I have changed the Set Password and Password Reset pages to check for passwords matching when the user clicks Set, rather than dynamically checking as the user types. Thanks to Tim for his helpful criticism http://groupserver.org/r/post/7K7Fc4x9UaK0QiATO5TNBj In our “tests” the users seem to be able to set passwords with the new system without any fuss, which was not the case with the old system. (In reality, our test involved shipping it live and getting 500 people to try and log in for the first time!)