[Cryptography] Why don't we protect passwords properly?

[Patrick Mylund Nielsen]

On Sat, Dec 21, 2013 at 11:46 PM, Bill Cox <waywardgeek at gmail.com> wrote:

> On Sat, Dec 21, 2013 at 6:07 PM, Patrick Mylund Nielsen <
> cryptography at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131222/e546235c/attachment.html>