Re: best practices for user friendly and secure forgotten password resolution

(Note:  feel free to ignore the below--it's based on thought, not  
personal experience implementing such a system...)

A few disconnected ideas here (in no particular order):
- Maybe a way to get around this would be to always send the user an  
email?  In the case of an email address that was on file, they'd get  
an email with the instructions for resetting their password.  If it  
wasn't, they'd get an email with the error message you're currently  
displaying.  This could even be seen to enhance security--if someone  
was trying to break into my account and failing, I'd at least know  
about it.

- It wouldn't help your current users much, but implementing OpenID  
might help with this going forward--that way you wouldn't be  
responsible for password resets, it would be the person's OpenID  
provider that was.

- It would also be really nice to offer some other way to get back  
into the account even if they don't have the valid email address (such  
as the questions Jeff Lowe just mentioned).  I've had instances where  
I've lost access to an email address for various reasons, and  
therefore been locked out of a system.

For what it's worth,

Ian

On Aug 21, 2009, at 2:29 PM, Laura Malone wrote:

> Hi all,
> The use case I'm asking for input on is this: The user has forgotten  
> their password and types in an email address that is not in our  
> system. Currently we tell them that we don't have that email address  
> in our system and to try another or register. However, we have been  
> mandated to address the security issues around this approach.  
> Apparently, by telling the user we don't have that email address in  
> their system allows a hacker/attacher to keep trying other email  
> addresses until they get a match.
> So in other words, there is a conflict between the ease of use in  
> telling a user who has forgotten their password that we don't have  
> their email address in our system vs. the potential breech of  
> security that this messaging apparently invites.
> My question is, have you resolved this conflict in your website, and  
> if so, how?
> Thanks for any insight,
> Laur Malone
> _______________________________________________
> This is the BayCHI Discussions mailing list, [email protected]
> To change your subscription options, or to unsubscribe, visit http://baychi.org/mailman/listinfo/discussions
_______________________________________________
This is the BayCHI Discussions mailing list, [email protected]
To change your subscription options, or to unsubscribe, visit http://baychi.org/mailman/listinfo/discussions