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

Hi, It's for corporate app Thanks Junior On Wed, Feb 2, 2011 at 10:31 AM, James Manico <jim@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@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@manico.net> > jim@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@ge.com>juan.calderon@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@lists.webappsec.org> >> websecurity-bounces@lists.webappsec.org [mailto:<websecurity-bounces@lists.webappsec.org> >> websecurity-bounces@lists.webappsec.org] *On Behalf Of *Milton Smith >> *Sent:* Monday, January 31, 2011 10:00 AM >> *To:* <websecurity@lists.webappsec.org> <websecurity@lists.webappsec.org> >> websecurity@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@lists.webappsec.org>websecurity@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@lists.webappsec.org>websecurity@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@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

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

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@gmail.com> wrote: Hi, It's for corporate app Thanks Junior On Wed, Feb 2, 2011 at 10:31 AM, James Manico <jim@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@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@manico.net> > jim@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@ge.com>juan.calderon@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@lists.webappsec.org> >> websecurity-bounces@lists.webappsec.org [mailto:<websecurity-bounces@lists.webappsec.org> >> websecurity-bounces@lists.webappsec.org] *On Behalf Of *Milton Smith >> *Sent:* Monday, January 31, 2011 10:00 AM >> *To:* <websecurity@lists.webappsec.org> <websecurity@lists.webappsec.org> >> websecurity@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@lists.webappsec.org>websecurity@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@lists.webappsec.org>websecurity@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@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@lists.webappsec.org http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

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@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@gmail.com> wrote: > >> Hi, It's for corporate app >> >> Thanks >> >> Junior >> >> On Wed, Feb 2, 2011 at 10:31 AM, James Manico <jim@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@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@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@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@lists.webappsec.org [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Milton Smith >>>> Sent: Monday, January 31, 2011 10:00 AM >>>> To: websecurity@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@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@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@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@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@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org