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

James Manico jim at manico.net
Wed Feb 2 11:00:05 EST 2011


If you are using S/MIME or PGP email in a corporate setting (closed network)
then I think email is acceptable for sending initial password creation
links. I would still not send the actual password over any communication
channel, it often implies weak email storage or weak password handling.

-Jim Manico
http://manico.net

On Feb 2, 2011, at 12:50 AM, Paulus Junior Lazuardi <paulusjrlz at gmail.com>
wrote:

Hi, It's for corporate app

Thanks

Junior

On Wed, Feb 2, 2011 at 10:31 AM, James Manico <jim at manico.net> wrote:

> Good question - is this a consumer app or a corporate app?
>
>
> -Jim Manico
> http://manico.net
>
> On Feb 1, 2011, at 9:18 PM, Paulus Junior Lazuardi <paulusjrlz at gmail.com>
> wrote:
>
>
>
> Hi,
>
> do you have recommendations for first time credentials of a newly migrated
> system?
>
> Thanks and Regards,
>
> Junior
>
>
> On Tue, Feb 1, 2011 at 1:59 AM, James Manico < <jim at manico.net>
> jim at manico.net> wrote:
>
>> Juan is expressing current best practice. A very reasonable risk posture.
>>
>> I was also impressed with some of the ideas in :
>>
>>
>> <http://www.fishnetsecurity.com/Resource_/PageResource/White_Papers/FishNetSecurity_SecureForgotPassword.pdf>
>> http://www.fishnetsecurity.com/Resource_/PageResource/White_Papers/FishNetSecurity_SecureForgotPassword.pdf
>>
>> ... 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.
>>
>> -Jim Manico
>> <http://manico.net>http://manico.net
>>
>> On Jan 31, 2011, at 11:19 AM, "Calderon, Juan Carlos (GE, Corporate,
>> consultant)" < <juan.calderon at ge.com>juan.calderon at ge.com> wrote:
>>
>> 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 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
>> password.
>>
>> Regards,
>> *Juan C Calderon*
>>
>>
>>  ------------------------------
>> *From:* <websecurity-bounces at lists.webappsec.org>
>> websecurity-bounces at lists.webappsec.org [mailto:<websecurity-bounces at lists.webappsec.org>
>> 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> <websecurity at lists.webappsec.org>
>> websecurity at lists.webappsec.org
>> *Subject:* [WEB SECURITY] First time login and password resets...
>>
>>  Hello,
>>
>> 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
>>
>> _______________________________________________
>> The Web Security Mailing List
>>
>> WebSecurity RSS Feed
>>  <http://www.webappsec.org/rss/websecurity.rss>
>> http://www.webappsec.org/rss/websecurity.rss
>>
>> Join WASC on LinkedIn <http://www.linkedin.com/e/gis/83336/4B20E4374DBA><http://www.linkedin.com/e/gis/83336/4B20E4374DBA>
>> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>
>> WASC on Twitter
>> <http://twitter.com/wascupdates>http://twitter.com/wascupdates
>>
>>  <websecurity at lists.webappsec.org>websecurity at lists.webappsec.org
>> <http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org>
>> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>>
>>
>> _______________________________________________
>> The Web Security Mailing List
>>
>> WebSecurity RSS Feed
>>  <http://www.webappsec.org/rss/websecurity.rss>
>> http://www.webappsec.org/rss/websecurity.rss
>>
>> Join WASC on LinkedIn <http://www.linkedin.com/e/gis/83336/4B20E4374DBA>
>> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>
>> WASC on Twitter
>>  <http://twitter.com/wascupdates>http://twitter.com/wascupdates
>>
>>  <websecurity at lists.webappsec.org>websecurity at lists.webappsec.org
>> <http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org>
>> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>>
>>
>
>
> --
> Look and smile to the world and let the world smile to you
>
>
>
> --
> Look and smile to the world and let the world smile to you
>
> _______________________________________________
> The Web Security Mailing List
>
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
>
> Join WASC on LinkedIn <http://www.linkedin.com/e/gis/83336/4B20E4374DBA>
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> WASC on Twitter
> http://twitter.com/wascupdates
>
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>
>


-- 
Look and smile to the world and let the world smile to you

_______________________________________________
The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity at lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110202/74acb549/attachment-0003.html>


More information about the websecurity mailing list