<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 23, 2014 at 5:23 PM, Lorenzo <span dir="ltr"><<a href="mailto:lorenzo@usucapio.net" target="_blank">lorenzo@usucapio.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 15. 06. 14 17:18, Sandy Harris wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"  Bcrypt is the default for NetBSD. It is available in the<br>
"  Ubuntu repositories, so I presume also in Debian. I'd<br>
"  say it should be the default for the box, and we could<br>
"  ask the Debian folks to look at whether it might<br>
"  become the default for Debian.<br>
<br>
</blockquote>
<br></div>
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.<br>
</blockquote></div><br></div><div class="gmail_extra">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.<br>
<br></div><div class="gmail_extra">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.<br>
<br></div><div class="gmail_extra">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...<br>
<br></div><div class="gmail_extra">Bill<br></div></div>