On 10/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> It seems that you should only be able to access the "change password" page if 
> you are either:
>
> 1.) Previously successfully authenticated
> 2.) Required to authenticate as part of change password.

There is a third option. I worked on one site where 'change password'
was implemented pretty much identically to 'password reset', ie we
send you a URL that, for a limited time, will let you change your
password (and can only be used once). The reasoning behind this was:
- password reset needs to be done this way for subscribed users
anyway, to keep this issue away from the helpdesk. I was point-blank
refusing to implement the alternative solution, "store the password in
plain text and mail it back" :)
- with only one way to change the password, there's less code to
audit. All of the use cases - subscribe, forgot password, expired
password, user-initiated password change - worked the same way.

>So, I guess my interpretation of the "best practice" for password change ...

My interpretation: get out of the game of managing passwords
completely - use single sign on with some central authentication
authority (like CAS, Athens, etc). And if one is not already
available, consider putting a central authority like CAS in place
instead of writing it into your app*.

Cheers,
Baz

* ok so customer requirements do sometimes get in the way here :) ...
but you did ask.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

Reply via email to