[Owasp-leaders] [OWASP ASVS] Password Reuse Attacks

Jim Manico jim.manico at owasp.org
Thu Jul 7 00:48:43 UTC 2016


Andrew,

I would both code defensively and test for 2.18, 2.20 and 2.27 very
differently. These seem - discrete items to me. But do need a cleanup.
Maybe...

2.18 seems like username harvesting protection (if your username is
private). Maybe clarify it?  /*Verify that username or email address
enumeration is not possible via login, password reset, or forgot account
functionality.*/

2.20 Trim this up maybe? /*Verify that request throttling is in place to
prevent automated attacks such as brute force attacks or denial of
service attacks.*/

2.27 Love it as is/*
*/


On 6/23/16 2:04 PM, Andrew van der Stock wrote:
> 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. 
>
> V2.18 Verify that information enumeration is not possible via login,
> password reset, or forgot account functionality.
> 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.
> V2.27 Verify that measures are in place to block the use of commonly
> chosen passwords and weak passphrases.
>  
> 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:
>
> "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."
>
> 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.
>
> Andrew
>
>
>
>
> On Fri, Jun 24, 2016 at 9:30 AM, Michael Coates
> <michael.coates at owasp.org <mailto:michael.coates at owasp.org>> wrote:
>
>     Really like this idea Milton. 
>
>     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. 
>
>     Top x
>     ...Organizational commitments for secure software
>     ...business decisions to drive secure software
>
>     Etc
>
>     On Thursday, June 23, 2016, Milton Smith <milton.smith at owasp.org
>     <mailto:milton.smith at owasp.org>> wrote:
>
>         All,
>
>         +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,
>
>         1, Appoint a CISO w/board level visibility
>         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.
>
>         2, Don't starve security
>         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)
>
>         3, Compliance is not security
>         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)
>
>         4, Security is a way of life not a band-aid
>         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.
>
>         5, You trained to be an engineer, don't forsake your training
>         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)
>
>         (you insert your ideas here 6-9)
>
>         10, Educate, educate, educate
>         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)
>
>         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.
>
>         Regards,
>         Milton
>
>
>         On 23 Jun 2016, at 9:41, Michael Coates wrote:
>
>             Leaders,
>
>             I just sent a related note to the top 10 list, but thought
>             it was warranted
>             for discussion here too.
>
>             I feel like we have a major gap in our discussion of
>             application risks.
>             Specifically we think about implementation bugs and often
>             forget design
>             flaws.
>
>             The main example here is password reuse attacks. From my
>             vantage point in
>             my day job (and just watching the news of my peers) this
>             is a major concern.
>
>             Here are 3 recent stories on this issue
>             http://www.csoonline.com/article/3086942/security/linkedin-data-breach-blamed-for-multiple-secondary-compromises.html
>             http://krebsonsecurity.com/2016/06/password-re-user-get-to-get-busy/
>             https://blog.twitter.com/2011/keeping-your-account-safe
>
>             What do others think? Is this getting the focus,
>             discussion and attention
>             it deserves? Are you talking about it at your companies or
>             with your
>             clients?
>
>
>             Quick note on the technical side of the password reuse attack
>
>                - With password reuse attacks a breach anywhere on the
>             web can mean a
>                breach of millions of users who reuse passwords
>                - These attacks are always done with automation
>             100million breached in
>                site A with a reusue rate on site B of 1% means
>             1million breached on site B
>                - There aren't "easy" answers here - The attacks always
>             come from a
>                variety of IP addresses. Rate limiting isn't effective
>             because it's 1
>                attempt per account from a new ip
>                - You have to rely on additional authentication
>             information or
>                anti-automation (tradeoffs to both)
>                - Making this a "user problem" and walking away is not
>             realistic
>
>
>
>             --
>             Michael Coates | @_mwc
>             <https://twitter.com/intent/user?screen_name=_mwc>
>             _______________________________________________
>             OWASP-Leaders mailing list
>             OWASP-Leaders at lists.owasp.org
>             https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
>
>     -- 
>
>     --
>     Michael Coates | @_mwc
>     <https://twitter.com/intent/user?screen_name=_mwc>
>     OWASP Global Board
>
>
>
>
>
>
>     _______________________________________________
>     OWASP-Leaders mailing list
>     OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
>
>
> _______________________________________________
> Owasp-application-security-verification-standard mailing list
> Owasp-application-security-verification-standard at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-application-security-verification-standard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160706/45f0113f/attachment-0001.html>


More information about the OWASP-Leaders mailing list