Best practices for self-service password reset solutions?
December 26, 2008 10:30 AM Subscribe
Best practices for self-service password reset solutions?
My company is preparing to start a project to make self-service password reset available to our users. The technology of the project is fairly straight forward but I would appreciate some suggestions about how others have handled rolling this out. These are a couple of my concerns (but other suggestions are welcome as well):
- How did you secure the external web site so someone couldn't guess passwords all day? We use RSA SecurID so we're thinking about setting up a portal that only requires username and SecurID token which then takes you to the PW reset page. We have a decent amount of remote and traveling users so external access is a must.
- The system is worthless unless users register and answer their challenge questions BEFORE they forget their password. How did you get users to initially register? We've discussed nuisance messages upon login, raffle off a prize (day off, special parking spot, etc) to all registered users or shaming them by providing lists to all department heads. We have about 1200 users so it would be a huge pain to harass employees and their managers to register. Our best case scenario would be a way to literally force them to register.
I'd also be interested in hearing from users of self-service password reset solutions and what they like and don't like about their solution.
My company is preparing to start a project to make self-service password reset available to our users. The technology of the project is fairly straight forward but I would appreciate some suggestions about how others have handled rolling this out. These are a couple of my concerns (but other suggestions are welcome as well):
- How did you secure the external web site so someone couldn't guess passwords all day? We use RSA SecurID so we're thinking about setting up a portal that only requires username and SecurID token which then takes you to the PW reset page. We have a decent amount of remote and traveling users so external access is a must.
- The system is worthless unless users register and answer their challenge questions BEFORE they forget their password. How did you get users to initially register? We've discussed nuisance messages upon login, raffle off a prize (day off, special parking spot, etc) to all registered users or shaming them by providing lists to all department heads. We have about 1200 users so it would be a huge pain to harass employees and their managers to register. Our best case scenario would be a way to literally force them to register.
I'd also be interested in hearing from users of self-service password reset solutions and what they like and don't like about their solution.
Best answer: A few random thoughts that don't necessarily add up to a complete course of action:
* In my experience, a WELL-WRITTEN, BRIEF, plain text (non-HTML), easy to read email with a clear call to action that lists the benefits of compliance will get between 80-90% participation from a user group (in a corporate environment, not a web service email blast). Make sure that the email is clear as day. Run it past marketing and HR. Have a non-geek read it. Show a draft to that one user that never wants to learn anything and wants a tech to do everything for him/her.
* Once you've done that, hopefully you've got a much shorter list of non-compliant users, and a few possible courses of actions. Depending on your relationship with HR, there are several annual checks probably already in place (sign a handbook, review 401K, etc.) so you could try and insert yourself as a step to one of those. Another route you mentioned is shaming users via their managers. I wouldn't personally choose that one, but it would work.
* Are your timesheets electronic? Depending on your LDAP/AD structure, you could check a flag and redirect users that visit the timesheet page to the questions page.
* It's easy to think up "sticks" but one of my favorite "carrots" to dangle in front of users is more shared drive storage space (either departmental or personal). Something on the order of a few hundred megs, maybe a gig.
posted by mysterious1der at 11:40 AM on December 26, 2008
* In my experience, a WELL-WRITTEN, BRIEF, plain text (non-HTML), easy to read email with a clear call to action that lists the benefits of compliance will get between 80-90% participation from a user group (in a corporate environment, not a web service email blast). Make sure that the email is clear as day. Run it past marketing and HR. Have a non-geek read it. Show a draft to that one user that never wants to learn anything and wants a tech to do everything for him/her.
* Once you've done that, hopefully you've got a much shorter list of non-compliant users, and a few possible courses of actions. Depending on your relationship with HR, there are several annual checks probably already in place (sign a handbook, review 401K, etc.) so you could try and insert yourself as a step to one of those. Another route you mentioned is shaming users via their managers. I wouldn't personally choose that one, but it would work.
* Are your timesheets electronic? Depending on your LDAP/AD structure, you could check a flag and redirect users that visit the timesheet page to the questions page.
* It's easy to think up "sticks" but one of my favorite "carrots" to dangle in front of users is more shared drive storage space (either departmental or personal). Something on the order of a few hundred megs, maybe a gig.
posted by mysterious1der at 11:40 AM on December 26, 2008
Best answer: I assume you have some password complexity tests in there. Well, what I do is list the rules to the side (uppercase letters, numbers, 6 or more characters, etc), then, as people type, I put a nice green box next to each one like "OKAY" or "PASS" as they get it right. Then, once all of the complexity rules are satisfied, something else obvious changes. Javascript is wonderful for this immediate feedback.
One of your "as they type" items should be a password confirmation, since they are typing their password twice.
Send an email for every change/reset attempt.
Log each and every attempt to a file. Log IP address and everything they typed (except the password itself). Do a reverse DNS right then and log that, too. Timestamp, down to the second. If there is a reason that they fail, like not typing in their first name, log that, too. Seem like a lot? You'd be amazed at how handy it is. It's so handy, I wrote a log "helper" program for some tech support folks to parse the logs so they can just call up all of a user's attempts and see precisely what it is they are doing wrong (or right).
You could use a secondary log, a rolling log, to make sure someone wasn't trying to hit the same login over and over. I have seen particularly frustrated users hit a login fifteen times.
Users named "David" will use "Dave" for their first name. "Elizabeth" can be Betty, Liz, Eliza, Lisa, etc. Do not try to "fix" this.
Do try to account for users who use their middle names. If you're doing LDAP/AD, you may have both to look up against. Exclude those users who have an initial for their middle name from this benefit.
Some users may have hyphenated last names. Split at the hyphen, then test the name against (Jones, Smith, and Jones-Smith). You laugh, but people often forget that they have the hyphenated name as the "official" name.
Come to grips with the idea that many users will not read the directions, therefore your error messages must be sparklingly clear. I can put directions in BIG RED TYPE, they still get ignored.
Memail me if you have more questions.
posted by adipocere at 12:42 PM on December 26, 2008
One of your "as they type" items should be a password confirmation, since they are typing their password twice.
Send an email for every change/reset attempt.
Log each and every attempt to a file. Log IP address and everything they typed (except the password itself). Do a reverse DNS right then and log that, too. Timestamp, down to the second. If there is a reason that they fail, like not typing in their first name, log that, too. Seem like a lot? You'd be amazed at how handy it is. It's so handy, I wrote a log "helper" program for some tech support folks to parse the logs so they can just call up all of a user's attempts and see precisely what it is they are doing wrong (or right).
You could use a secondary log, a rolling log, to make sure someone wasn't trying to hit the same login over and over. I have seen particularly frustrated users hit a login fifteen times.
Users named "David" will use "Dave" for their first name. "Elizabeth" can be Betty, Liz, Eliza, Lisa, etc. Do not try to "fix" this.
Do try to account for users who use their middle names. If you're doing LDAP/AD, you may have both to look up against. Exclude those users who have an initial for their middle name from this benefit.
Some users may have hyphenated last names. Split at the hyphen, then test the name against (Jones, Smith, and Jones-Smith). You laugh, but people often forget that they have the hyphenated name as the "official" name.
Come to grips with the idea that many users will not read the directions, therefore your error messages must be sparklingly clear. I can put directions in BIG RED TYPE, they still get ignored.
Memail me if you have more questions.
posted by adipocere at 12:42 PM on December 26, 2008
The system is worthless unless users register and answer their challenge questions BEFORE they forget their password. How did you get users to initially register? We've discussed nuisance messages upon login, raffle off a prize (day off, special parking spot, etc) to all registered users or shaming them by providing lists to all department heads.
I assume you're in a corporate environment and looking to reduce the volume of support calls for password resets, right?
Here's what I suggest: You could follow mysterious1der's suggestion of a brief, clear e-mail linking to a quick/simple setup page. You could optionally send out a second e-mail a week or two later to those people who did not respond.
Then anyone who makes a tech support call asking for a password reset, if they have not set up this memorable question/answer, the tech taking the call could set up the memorable data before resetting their password.
Now, granted, some users may ignore your two emails and never call tech support, but those users aren't bothering tech support so what's the problem? I mean, if User A isn't forgetting his password and isn't making tech support calls to reset it, it seems irrelevant if he isn't set up on the password reset self service system? It seems like a waste of his time and yours to bully/threaten/force him to set up a service he will never need to use.
posted by Mike1024 at 3:36 PM on December 26, 2008
I assume you're in a corporate environment and looking to reduce the volume of support calls for password resets, right?
Here's what I suggest: You could follow mysterious1der's suggestion of a brief, clear e-mail linking to a quick/simple setup page. You could optionally send out a second e-mail a week or two later to those people who did not respond.
Then anyone who makes a tech support call asking for a password reset, if they have not set up this memorable question/answer, the tech taking the call could set up the memorable data before resetting their password.
Now, granted, some users may ignore your two emails and never call tech support, but those users aren't bothering tech support so what's the problem? I mean, if User A isn't forgetting his password and isn't making tech support calls to reset it, it seems irrelevant if he isn't set up on the password reset self service system? It seems like a waste of his time and yours to bully/threaten/force him to set up a service he will never need to use.
posted by Mike1024 at 3:36 PM on December 26, 2008
« Older What is the architectural style of this home?? | Once upon a time, there was a magic recipe . . . Newer »
This thread is closed to new comments.
Create the user accounts beforehand with whatever basic information (name etc.) you have. Send out emails containing a unique activation URL for each user. When users click the URL in the email (which at that stage is all you're asking them to do), send them to a page where they enter their SecurID token and set up challenge questions.
With that you'll be able to keep track of which users clicked the link but didn't bother to go further, and which ignored the email completely or didn't get it. Maybe save the carrot (or stick) until you see how many users respond.
posted by le morte de bea arthur at 10:53 AM on December 26, 2008