lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Mar 2014 13:31:23 -0700
From: Tony Arcieri <>
To: "" <>
Subject: Re: [PHC] "Why I Don't Recommend Scrypt"

On Thu, Mar 13, 2014 at 1:09 PM, Patrick Mylund Nielsen <> wrote:

> What I'm saying is you have exactly the same problems with any other kind
> of request a user can make. You can DDoS a website simply by doing regular
> login requests but with random (and non-existing) usernames, too.

If you can leverage a slow PHF, the attack becomes far more asymmetrical in
terms of what it costs the attacker versus the resulting impact on your

I am honestly curious: Has the compute overhead ever actually impacted
> anyone who had more general DDoS protections?

There's no such thing as a "general DDoS protection" any more than there is
a general solution to someone taking down your power grid. You must
consider every aspect of the request pipeline from your upstream PoPs to
your backend applications, and the solutions you implement at each step of
the way apply to every part of your application. Every part of the request
pipeline is vulnerable in different ways.

You need to armor your upstream PoPs via automated BGP flowspec directives,
ensure an attacker can't exhaust the capacity of your HTTP routing mesh,
and ensure that your backend apps can't spin indefinitely on slow
endpoints. There are no general solutions to this. None.

Tony Arcieri

Content of type "text/html" skipped

Powered by blists - more mailing lists