[148566] in cryptography@c2.net mail archive
Re: [Cryptography] Why don't we protect passwords properly?
daemon@ATHENA.MIT.EDU (Patrick Mylund Nielsen)
Sun Dec 22 01:39:35 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAOLP8p7LFthi=ABTQMWgh=jkNwta6Hui0d_+JQBgM5iPpgg-=g@mail.gmail.com>
Date: Sun, 22 Dec 2013 00:16:49 -0500
From: Patrick Mylund Nielsen <cryptography@patrickmylund.com>
To: Bill Cox <waywardgeek@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7528805305442790668==
Content-Type: multipart/alternative; boundary=047d7bf0d10454176504ee189e06
--047d7bf0d10454176504ee189e06
Content-Type: text/plain; charset=UTF-8
On Sat, Dec 21, 2013 at 11:46 PM, Bill Cox <waywardgeek@gmail.com> wrote:
> On Sat, Dec 21, 2013 at 6:07 PM, Patrick Mylund Nielsen <
> cryptography@patrickmylund.com> wrote:
>
>> The most popular argument against something like scrypt seems to be that
>> using an expensive function makes you susceptible to DDoS attacks. This is
>> true, but it's also completely beside the point.
>>
>
> I don't understand why servers do the KDF rather than the client. The
> current system requires that the password be transmitted to the server, and
> users have to trust the service provider to be honest.
>
The biggest reason has been that web services can't expect clients to run
something like scrypt in JavaScript. If it's e.g. a native application,
there is no reason why you shouldn't offload this to the client.
There is some hope: PBKDF2 made it into the WebCrypto API spec, so you will
at least be able to run e.g. PBKDF2-SHA256 in browsers as native code.
There are also asm.js implementations of scrypt which seem reasonably fast.
As far as "simply replacing with scrypt" goes, I think it's unfortunate
that most packages that implement it do so very confusingly, either with
misleading terms such as "Password encryption", or solely as a KDF, with no
instructions or API available to do something similar to bcrypt, which
retains the parameter configuration in the digests it produces. The
Password Hashing Competition (https://password-hashing.net/) will hopefully
choose something with a simple API.
But yes -- you're singing my song, and probably that of many people on this
list. It's a messy situation, and there's no good reason for it.
If the TrueCrypt authors were paid off to not implement something stronger,
which I think is unlikely but can't reject is a possibility, there are
other projects to support--FreeOTFE for example. But you're right that it
seems awareness needs to be raised across the board.
--047d7bf0d10454176504ee189e06
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Dec 21, 2013 at 11:46 PM, Bill Cox <span dir=3D"ltr"><<a href=3D"mai=
lto:waywardgeek@gmail.com" target=3D"_blank">waywardgeek@gmail.com</a>><=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<div class=3D"im">On Sat, Dec 21, 2013 at 6:07 PM, Patrick Mylund Nielsen <=
span dir=3D"ltr"><<a href=3D"mailto:cryptography@patrickmylund.com" targ=
et=3D"_blank">cryptography@patrickmylund.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<div><span style=3D"color:rgb(34,34,34)">The most popular argument against =
something like scrypt seems to be that using an expensive function makes yo=
u susceptible to DDoS attacks. This is true, but it's also completely b=
eside the point.</span><br>
</div></div></div></div></blockquote><div><br></div></div><div>I don't =
understand why servers do the KDF rather than the client. =C2=A0The current=
system requires that the password be transmitted to the server, and users =
have to trust the service provider to be honest.=C2=A0</div>
</div></div></div></blockquote><div><br></div><div>The biggest reason has b=
een that web services can't expect clients to run something like scrypt=
in JavaScript. If it's e.g. a native application, there is no reason w=
hy you shouldn't offload this to the client.</div>
<div><br></div><div>There is some hope: PBKDF2 made it into the WebCrypto A=
PI spec, so you will at least be able to run e.g. PBKDF2-SHA256 in browsers=
as native code. There are also asm.js implementations of scrypt which seem=
reasonably fast.</div>
<div><br></div><div>As far as "simply replacing with scrypt" goes=
, I think it's unfortunate that most packages that implement it do so v=
ery confusingly, either with misleading terms such as "Password encryp=
tion", or solely as a KDF, with no instructions or API available to do=
something similar to bcrypt, which retains the parameter configuration in =
the digests it produces. The Password Hashing Competition (<a href=3D"https=
://password-hashing.net/">https://password-hashing.net/</a>)=C2=A0will hope=
fully choose something with a simple API.</div>
<div><br></div><div>But yes -- you're singing my song, and probably tha=
t of many people on this list. It's a messy situation, and there's =
no good reason for it.</div><div><br></div><div>If the TrueCrypt authors we=
re paid off to not implement something stronger, which I think is unlikely =
but can't reject is a possibility, there are other projects to support-=
-FreeOTFE for example. But you're right that it seems awareness needs t=
o be raised across the board.</div>
</div></div></div>
--047d7bf0d10454176504ee189e06--
--===============7528805305442790668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============7528805305442790668==--
