[Owasp-leaders] Password Reuse Attacks
michael.coates at owasp.org
Fri Jun 24 03:25:36 UTC 2016
So here's the tough thing, none of those defenses stop this variation of
V2.18 - Information enumeration isn't relevant. The attacker has a list of
10million emails & passwords from site A and they're going to try them all
against site B. They don't have to enumerate anything
V2.20 - Request throttling is only helpful if the attacker is either coming
from a single IP address (which is easy to avoid) or the attacker is trying
multiple passwords against a single account
V2.27 - The strength of the password is actually irrelevant. The issue is
the password is *reused* at Site A and Site B
Here's the breakdown of the attacker activity
IPAddress1 targeting Username:joe at email.com w/Password hello123
IPAddress2 targeting Username:sue at otheremail.com w/Password
$trong3rP at ssword789
IPAddress3 targeting Username:10million at automation.com w/Password foobar
As you see the IP addresses rotates with each attempt so v2.20 is bypassed
The username and password is coming from the data dump of site A breach
some v2.18 is bypassed
Lastly the passwords are already known from site A breach, so strength
doesn't matter either.
*What can we do?*
I only see 2 options:
1. Stop the ability for automated logins. The very rough approach is via
captcha all logins (you shouldn't do this though). The more elegant
approach is anti-automation from various startup vendors in this space.
2. Monitor all breaches - grab all breached credentials & flag any
accounts/passwords that are breached anywhere on the web. These accounts
then need to provide additional authentication data (think challenge
questions). The idea isn't to stop a targeted attack against 1 account, but
instead disrupt massive automation against millions of accounts by adding
another piece of information to the authentication puzzle.
3. Or, migrate all users to 2FA :) That's hard, but every user you get on
Andrew - in terms of updating the guide I'd recommend a specific section
that calls out this type of attack (and it's massive prevalence). We need
to clarify for everyone how this differs from the traditional brute force
attack and what can be done.
Michael Coates | @_mwc <https://twitter.com/intent/user?screen_name=_mwc>
OWASP Global Board
On Thu, Jun 23, 2016 at 5:04 PM, Andrew van der Stock <vanderaj at owasp.org>
> 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
> 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
>>>> 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
>>>> 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
>>>> 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 <
>>>> 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