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

Prasad N Shenoy prasad.shenoy at gmail.com
Wed Feb 2 12:34:34 EST 2011


SMS temporary password to the cell phone  number on account (verified in the past) which is good for 10 mins only. 

Now, if the phone is stolen/compromised at the same time someone knowing your user name making a password reset attempt on your bank account, it's better you not worry about the password and call 911.

Sent from my iPhone

On Feb 2, 2011, at 11:00 AM, James Manico <jim at manico.net> wrote:

> 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> 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
>>> 
>>> ... 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
>>> 
>>> 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 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 [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...
>>>> 
>>>> Hello,
>>>> 
>>>> Wondering what everyone does to communicate first time credentials or password resets to users.  There are two challenges.
>>>> 
>>>> Ensure person we communicate credentials to is the correct person (e.g., owner of credentials)
>>>> 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
>>>> 
>>>> 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
>>> 
>>> _______________________________________________
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> 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
>>> 
>>> 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
> 
> _______________________________________________
> 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/5920bc3f/attachment-0003.html>


More information about the websecurity mailing list