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

If no one uses the systemor gets so angry at it that they hate it 
then the entire app proves worthless anyhow. I would err on the side  
of usability, dealing with security in other waysthat is, given an  
absolute need for security in the first place. Banks run into this  
problem frequently; in that case, an actual human must be called to  
resent the account.

High-security sites may consider finger-printing clients.

However, if security of a game site is in question, who cares?

In such a case, I would establish other means to ID end-users. Names  
are a start. Names of favorite pets, etc.

Regardless, security should not get in the way of user-centered  
design, or in any way building the app, as a car is not built around  
the ignition key.


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

Greg Austin
[email protected]
_______________________________________________
This is the BayCHI Discussions mailing list, [email protected]
To change your subscription options, or to unsubscribe, visit http://baychi.org/mailman/listinfo/discussions