[WEB SECURITY] First time login and password resets...
jim at manico.net
Mon Jan 31 13:59:52 EST 2011
Juan is expressing current best practice. A very reasonable risk posture.
I was also impressed with some of the ideas in :
... Takeaway: avoid email and either ask a lot of questions to allow for the
reset, and/or possibly use a cell phone as a second factor. Email is
inherently plaintext and insecure.
On Jan 31, 2011, at 11:19 AM, "Calderon, Juan Carlos (GE, Corporate,
consultant)" <juan.calderon at ge.com> wrote:
>From my point of view you have it pretty much all covered. my personal
Generate a temporary token (30 min to 1 day max). So email will be useless
after that period in case the computer or user email is compromised
Send a HTTPS link to user with the temp token. Avoid wire sniffing
The end user will have answer a challenge question (one of at least 2
entered on registration) and then reset its password. Supply an identity
element, in this case challenge response instead of previous password and
reset password as it should be in hash or salted hash format thus not
reversible nor displayable to user.
Request for password reset and password reset success should be notified to
user via registered email
This approach implies users register themselves, also, if your site is not
public but corporate level and contains sensitive information, I strongly
recommend you also add a manager authorization step to keep accountability
for system accesses granted.
As everything in security the approach is not perfect, but I think is good
enough due to limited time window and measures taken to avoid disclosing the
*Juan C Calderon*
*From:* websecurity-bounces at lists.webappsec.org [mailto:
websecurity-bounces at lists.webappsec.org] *On Behalf Of *Milton Smith
*Sent:* Monday, January 31, 2011 10:00 AM
*To:* websecurity at lists.webappsec.org
*Subject:* [WEB SECURITY] First time login and password resets...
Wondering what everyone does to communicate first time credentials or
password resets to users. There are two challenges.
1. Ensure person we communicate credentials to is the correct person
(e.g., owner of credentials)
2. Do not disclose credentials in plain text over network
To a certain extent the computer has not helped us with these challenges.
Simply reverting to phone does not solve these challenges either. For
example, calling a user with their new credentials is similar to mailing the
credentials in the clear. It's likely IT staff does not know the person on
the other end of line and phone conversations can be intercepted.
The solution I have been considering is to email an HTTPS link to users.
Next, mandatory password reset at logon. This prevents sniffing
credentials over net. Of course, you can sniff the URL then login.
However, if this is done it will be obvious to the user since they will not
be able to logon with the password they were sent. A bit after the fact I
realize but perhaps better than nothing. Next, what if I made the link so
it's only good for 10 mins or some limited window. This helps limit the
window of opportunity. Anyway, this solution is not perfect but perhaps
better than passwords in the clear or calling people we don't know. Key
fobs, other hardware solutions, or client side certs are likely out since
it's a cloud based solution.
Do you have any interesting thoughts or suggestions for how you approached
The Web Security Mailing List
WebSecurity RSS Feed
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
websecurity at lists.webappsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the websecurity