[Owasp-leaders] [OWASP ASVS] Password Reuse Attacks
jim.manico at owasp.org
Thu Jul 7 00:48:43 UTC 2016
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.
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
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
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.
> 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
> On Thursday, June 23, 2016, Milton Smith <milton.smith at owasp.org
> <mailto:milton.smith at owasp.org>> wrote:
> +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.
> On 23 Jun 2016, at 9:41, Michael Coates wrote:
> 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
> 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
> 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
> 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
> Michael Coates | @_mwc
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> Michael Coates | @_mwc
> OWASP Global Board
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
> Owasp-application-security-verification-standard mailing list
> Owasp-application-security-verification-standard at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders