[Freedombox-discuss] Block brute force login attacks?

[Bill Cox]

On Mon, Jun 23, 2014 at 5:23 PM, Lorenzo <lorenzo at usucapio.net> wrote:

> On 15. 06. 14 17:18, Sandy Harris wrote:
>
>> "  Bcrypt is the default for NetBSD. It is available in the
>> "  Ubuntu repositories, so I presume also in Debian. I'd
>> "  say it should be the default for the box, and we could
>> "  ask the Debian folks to look at whether it might
>> "  become the default for Debian.
>>
>>
> Using bcrypt to block bruteforce password logins should be done in a
> careful way. If the box has to compute the hash then the attacker has an
> easy way launch a DoS: It just has to initiate a lot of connection attempts
> and the box would use all the CPU time computing bcrypt hashes. If it would
> be possible to make the client compute the bcrypt hash of a challenge then
> that would be nice, but I don't think support for this is widely available.
>

Such support is not widely available, but it would be the right way to go!
I would prefer using Script over Bcrypt.  Bcrypt is not easily attacked on
current GPUs, but that may change in the near future.  Also, Bcrypt is not
nearly as secure as Script against custom ASIC attacks, for memory sizes >>
4MiB.  Even mobile phones now come with >= 256 MiB, so requiring a 16 or
even 32MiB hash should be no biggie.

Protocols that send the password without any key derivation to the server
are dumb, IMO.  They require that the user trust the server 100%.  A
minimal key derivation such as 16-ish MiB of Script on the client avoids
the DoS problem while improving security in several ways.  First, even if
the server is actually a MITM, or is PWN-ed, having a Script hash rather
than the password protects the user's other accounts where he may use the
same password.  Second, off-line brute-force attacks against password file
hashes are roughly 20,000 times more expensive per password guess when
using Script vs PBKDF2-SHA256(2000) according to Script docs (I might have
the details wrong here, but it's something like that).  Simply introducing
a 1-ish second delay between incorrect password guesses at the login prompt
does nothing to prevent off-line brute-force attacks with GPU farms, as is
done today when sites like LinkedIn lose their hashed password data.
Third, it protects the user's plain-text password against bugs in OpenSSL
and such.  Fourth, it enables the user to choose security parameters for
his needs.  If he's always logging in from the same machine, he could tune
memory, runtime, and number of parallel threads optimally for defense.  If
this is an account that the user takes very seriously, he could introduce a
1 minute Script hash for another several bits of security.

Both the client and the server should be responsible for password
security.  These protocols that assume the client is dumb and that the
server is 100% trustworthy are lame.  Simply having a server delay timer is
also lame.  Just my opinion...

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20140624/e9076184/attachment.html>