<div dir="ltr">How all these handles OAUTH?<div><br></div><div>I mean many apps implement OAUTH (google, yahoo, gmail, Facebook)</div><div>Is not exactly reusing passwords but one credential (email login) once hacked, will open the door for the all the apps.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 23, 2016 at 8:04 PM, Andrew van der Stock <span dir="ltr"><<a href="mailto:vanderaj@owasp.org" target="_blank">vanderaj@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><font face="arial, helvetica, sans-serif">In the ASVS, we have several related requirements but not quite - that asks that systems don't become an oracle for testing credentials. I think we can adjust one of them to cover this risk off whilst not trying to be World Password Police. </font><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">V2.18 Verify that information enumeration is not
possible via login, password reset, or forgot account functionality.</font></div>














<font face="arial, helvetica, sans-serif">V2.20 Verify that request throttling is in place to
prevent automated attacks against common authentication attacks such as brute
force attacks or denial of service attacks.</font><div><font face="arial, helvetica, sans-serif">V2.27 Verify that measures are in place to block the
use of commonly chosen passwords and weak passphrases.</font></div>














<font face="arial, helvetica, sans-serif"> <br></font><div><font face="arial, helvetica, sans-serif">We are going to issue 3.0.1 at AppSec EU training next week. Which of these items should we include more detail on preventing being an oracle? I feel that raising this issue specifically in V2.20, such that:</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">"V2.20 Verify that request throttling is in place to prevent automated attacks against common authentication attacks, such as password re-use oracle attacks, password brute force attacks, or denial of service attacks. This could be done by limiting the number of attempts by a single IP per API per day to around 5 or so failed attempts, or a linear back off algorithm."</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Thoughts? Really need to do this in the next 72 hours, because the students get it next Monday in Rome. Would love to have feedback from the community before I make the change.</font></div><span class="HOEnZb"><font color="#888888"><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Andrew</font></div><div><font face="Calibri"><span style="font-size:16px"><br></span></font></div><div><font face="Calibri"><span style="font-size:16px"><br></span></font></div><div><font face="Calibri"><span style="font-size:16px"><br></span></font></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 24, 2016 at 9:30 AM, Michael Coates <span dir="ltr"><<a href="mailto:michael.coates@owasp.org" target="_blank">michael.coates@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Really like this idea Milton. <div><br></div><div>The "top x lists" seem to be pithy and get people's attention. I wonder if this is a new list that's needed. Not sure the right name. </div><div><br></div><div>Top x</div><div>...Organizational commitments for secure software</div><div>...business decisions to drive secure software</div><div><br></div><div>Etc</div><div><div><div><br>On Thursday, June 23, 2016, Milton Smith <<a href="mailto:milton.smith@owasp.org" target="_blank">milton.smith@owasp.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
+1 for Michael.  There is too much focus on the vulns and not enough focus on avoiding writing crappy software.  We need a OWASP 10 list for secure product (or similar).  Focus on the positive, building great software.  Manico comes the closes with top 10 proactive controls.  However, even this focuses on -the code-.  We need code approaches but we also need something outside of a pure code focus.  Maybe a top 10 secure product list like,<br>
<br>
1, Appoint a CISO w/board level visibility<br>
You wouldn't dare diagnose your own medical condition.  What makes you think you can make good decisions in security?  Hire an appsec expert with proven experience in the appsec space with hands on coding experience - a must.  It's hard enough to change the minds of developers as it is.  If you don't have the code chops you will never gain respect.  Equally important you need exec that can frame technical security problems in terms of business risk to boards, smart business leaders, or the public/press, in a way they can understand and appreciate.  The bar is high.<br>
<br>
2, Don't starve security<br>
The quickest way to kill any security program is starvation.  To be good at anything takes investment in resources.  Security budget should be 15%+ of the overall IT budget when starting a program and taper off as the program mature.  Compliance is a separate budget.  (or whatever OWASP thinks the best trend is among successful companies)<br>
<br>
3, Compliance is not security<br>
The first words out of the Target CEO's mouth was that they passed their audit.  Compliances is what you must do.  Security is the love you show your customers over and above compliance requirements.  In fact, your security leader should not have compliance responsibilities since this is a conflict of interest.  The chief of compliance should report to the board as well.  (well, we should soften the message slightly but you understand my point.  ;o)<br>
<br>
4, Security is a way of life not a band-aid<br>
Poor security is more than a code problem - it's a software quality problem.  You would be shocked if a doctor didn't wash his hands before your surgery.  Security is the same.  Every person and process that contributes to the code of your solution is a part of the problem and also a part of the solution.  Security must be applied throughout the entire software development lifecycle.<br>
<br>
5, You trained to be an engineer, don't forsake your training<br>
Software development is a like train careening out of control at many companies.  Yes, work quickly, Agile, and be competitive in business but not so quickly you forsake your training and common sense.  Put the skills you were taught to use.  Many business are constantly commenting on success of companies like Google.  If you want to enjoy the type of success Google has at your company you must do the things Google does.  Start building better software, security will follow, and you will take your company to amazing places.  Invest in yourself you would be amazed what you can do!  (Imagine being an early Blizzard employee trying to convince investors World of Warcraft is a good idea.  Someone was able to do this and look at the level of success)<br>
<br>
(you insert your ideas here 6-9)<br>
<br>
10, Educate, educate, educate<br>
Each role at an organization involved in project creation, development, and delivery requires ongoing security training.  Training should be role appropriate.  Managers need security training also.  Security is always changing and requires constant education.  (I have taken some managers with me to BH/DEFCON and their views on security are not the same as well we started)<br>
<br>
Anyway, I'm not strong on all these points but raising them as ideas for your consideration.  I do think there are some concerns larger than coding.  Elevating attention in these areas could be helpful to industry.<br>
<br>
Regards,<br>
Milton<br>
<br>
<br>
On 23 Jun 2016, at 9:41, Michael Coates wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Leaders,<br>
<br>
I just sent a related note to the top 10 list, but thought it was warranted<br>
for discussion here too.<br>
<br>
I feel like we have a major gap in our discussion of application risks.<br>
Specifically we think about implementation bugs and often forget design<br>
flaws.<br>
<br>
The main example here is password reuse attacks. From my vantage point in<br>
my day job (and just watching the news of my peers) this is a major concern.<br>
<br>
Here are 3 recent stories on this issue<br>
<a href="http://www.csoonline.com/article/3086942/security/linkedin-data-breach-blamed-for-multiple-secondary-compromises.html" target="_blank">http://www.csoonline.com/article/3086942/security/linkedin-data-breach-blamed-for-multiple-secondary-compromises.html</a><br>
<a href="http://krebsonsecurity.com/2016/06/password-re-user-get-to-get-busy/" target="_blank">http://krebsonsecurity.com/2016/06/password-re-user-get-to-get-busy/</a><br>
<a href="https://blog.twitter.com/2011/keeping-your-account-safe" target="_blank">https://blog.twitter.com/2011/keeping-your-account-safe</a><br>
<br>
What do others think? Is this getting the focus, discussion and attention<br>
it deserves? Are you talking about it at your companies or with your<br>
clients?<br>
<br>
<br>
Quick note on the technical side of the password reuse attack<br>
<br>
   - With password reuse attacks a breach anywhere on the web can mean a<br>
   breach of millions of users who reuse passwords<br>
   - These attacks are always done with automation 100million breached in<br>
   site A with a reusue rate on site B of 1% means 1million breached on site B<br>
   - There aren't "easy" answers here - The attacks always come from a<br>
   variety of IP addresses. Rate limiting isn't effective because it's 1<br>
   attempt per account from a new ip<br>
   - You have to rely on additional authentication information or<br>
   anti-automation (tradeoffs to both)<br>
   - Making this a "user problem" and walking away is not realistic<br>
<br>
<br>
<br>
--<br>
Michael Coates | @_mwc <<a href="https://twitter.com/intent/user?screen_name=_mwc" target="_blank">https://twitter.com/intent/user?screen_name=_mwc</a>><br>
_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a>OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
</blockquote>
</blockquote></div><br><br></div></div><span><font color="#888888">-- <br><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br>--<br>Michael Coates | <a href="https://twitter.com/intent/user?screen_name=_mwc" target="_blank">@_mwc</a><br></div><div>OWASP Global Board<br></div><div dir="ltr"><div><br></div><div><br></div><div><br><br></div></div></div></div></div></div></div><br>
</font></span><br>_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Owasp-application-security-verification-standard mailing list<br>
<a href="mailto:Owasp-application-security-verification-standard@lists.owasp.org">Owasp-application-security-verification-standard@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-application-security-verification-standard" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-application-security-verification-standard</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Johanna Curiel </div>OWASP Volunteer</div></div>
</div>