[Owasp-leaders] Password Reuse Attacks
sherif.mansour at owasp.org
Sat Oct 8 10:06:50 UTC 2016
An attacker with control of a bot net can easily circumvent traditional
bruteforce controls because they do not need more than one (or two) guesses
against each account due to password reuse.
There are a few other things that aid attackers for this:
- Tools which mimic user behaviour to limit the effectiveness of anomaly
detection e.g. www.sentry.mba
- SaaS services which solve CAPTCHAs e.g. death by captcha
- Use of headless browsers as agents because these will load and run JS
and the full DOM e.g. Phantom.js
One approach to limit the effectiveness of these attacks, is for
organisations to tests these credentials against their own users internally
and take the necessary steps to protect them.
This ranges from disabling the account and notifying the user for password
recent, to just adding additional "soft challenges"
On Fri, Sep 23, 2016 at 11:04 PM, Michael Coates <michael.coates at owasp.org>
> Here's a way to put the data breaches in perspective for your company.
> Imagine if 2% of those 500M Yahoo Users have an account on your site.
> That's 10M of your users that are potentially impacted. Now ask yourself
> how many users reuse passwords across multiple websites (it could be a
> strong password or a weak one, doesn't matter, is it reused?). Let's say
> 10% reuse passwords. 10% of 10M is 1M users that have passwords that are
> now exposed, just waiting to be abused by an attacker. How will your site
> handle 1 million compromised accounts?
> You can change the numbers as you see fit. But the take away is that a
> breach of an unrelated website can lead to millions of your users at risk
> through automated reuse password attacks.
> Michael Coates | @_mwc <https://twitter.com/intent/user?screen_name=_mwc>
> OWASP Global Board
> On Thu, Sep 22, 2016 at 12:04 PM, Dave Wichers <dave.wichers at owasp.org>
>> Hey: http://money.cnn.com/2016/09/22/technology/yahoo-data-breach
>> /index.html - 500M Yahoo User Accounts compromised. Wonder how many new
>> valid username/password pairs are floating around the interweb. All the
>> more reason why Michael's post is important/timely.
>> The breach is said to have occurred in late 2014. "The account
>> information may have included names, email addresses, telephone numbers,
>> dates of birth, hashed passwords (the vast majority with bcrypt) and, in
>> some cases, encrypted or unencrypted security questions and answers,"
>> On Thu, Jun 23, 2016 at 12:41 PM, Michael Coates <
>> michael.coates at owasp.org> 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
>>> 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 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
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders