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

Jim Manico jim.manico at owasp.org
Thu Jul 7 00:50:21 UTC 2016


I agree 2.20 should be more generic. Here is my "take 2" on this...
Generic and simplified...

*V2.20 /Verify that //defense//is in place to prevent automated attacks
such as brute force attacks or denial of service attacks/.*


On 6/23/16 2:28 PM, Raoul Endres wrote:
>
> Would not a more generic approach work for 2.20? E.g.:
>
> - determine if automated detection of brute force attacks is in place
> - determine if automatic processes to limit access attempts exists,
> particularly when triggered by the above
>
> (Although worded more eloquently)
>
> I also care about process in case this type of situation were to
> escalate, but that is likely manual incidence response and beyond the
> scope of ASVS...
>
> cheers,
> Raoul.
>
> Raoul Endres
>
> On 24 Jun 2016 10:13 AM, "Andrew van der Stock" <vanderaj at owasp.org
> <mailto:vanderaj at owasp.org>> 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
>     <mailto:Owasp-application-security-verification-standard at lists.owasp.org>
>     https://lists.owasp.org/mailman/listinfo/owasp-application-security-verification-standard
>
>
>
> _______________________________________________
> 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/10d07e54/attachment-0001.html>


More information about the OWASP-Leaders mailing list