[WEB SECURITY] First time login and password resets...

Calderon, Juan Carlos (GE, Corporate, consultant) juan.calderon at ge.com
Mon Jan 31 11:31:26 EST 2011

>From my point of view you have it pretty much all covered. my personal
process is
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
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 password.
Juan C Calderon



From: websecurity-bounces at lists.webappsec.org
[mailto:websecurity-bounces at lists.webappsec.org] On Behalf Of Milton
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 these challenges?

Kind Regards,
Milton Smith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110131/4ce78035/attachment-0003.html>

More information about the websecurity mailing list