[Owasp-leaders] Password Reuse Attacks
Andrew van der Stock
vanderaj at owasp.org
Fri Jun 24 00:04:42 UTC 2016
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
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
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>
> 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> 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
>> 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
>>> 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
>>> 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 realistic
>>> Michael Coates | @_mwc <https://twitter.com/intent/user?screen_name=_mwc
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
> Michael Coates | @_mwc <https://twitter.com/intent/user?screen_name=_mwc>
> OWASP Global Board
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders