Re: Hash functions

On Tue, Dec 21, 2010 at 2:58 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> Notice that all three of the OP's use-cases were based on checksumming
> files.  I don't know how reading in a Blob and then hashing it would
> compare to just hashing an equivalent string, but I suspect it would
> have a decent perf hit.  This seems like a pretty useful ability in
> general, enough so that it's probably worthwhile to build it in
> directly as a Blob.checksum() function or something.

I wouldn't expect a big performance hit from that.  Start reading the
next block (say, 1MB at a time) asynchronously, run the SHA1 for the
previous block while that's running, and repeat.  (I'd do the whole
thing in a worker thread, so the synchronous SHA1 call itself wouldn't
bog down the UI.)  I'm not up on the internals of the file API
implementations, but it seems like that should be pretty efficient.

(Even the async requests should be unnecessary, since the OS should be
doing read-ahead anyway.)

> I still think it may be useful for the security use-case as well,
> where you explicitly want a slow hash to begin with.  If JS imposes a
> slowdown on top of that, it could render a good hash too slow to
> actually use in practice.  Plus, you have to depend on the hash
> implementation you pulled off the web or hacked together yourself,
> which you probably didn't manually verify before starting to use.

I had to think pretty hard to come up with a use case for something
like bcrypt in Javascript, and the only one I've come up with seems
somewhat flimsy:

Sites could avoid ever sending passwords from the client to the
server.  Instead of sending a password directly, the server sends the
salt for the user's password (or a random salt for a new password);
the client sends the password hashed with that salt.  This means that
sniffing the traffic--even on the server itself where you might in
underneith HTTPS--couldn't record a large log of user passwords to be
used elsewhere; the server would never know the password to begin
with, not even when the user first sets his password.

The flimsy part is it depends on the Javascript doing the hashing
being secure; if the server is compromised, the script itself could
just be replaced.  That's still potentially a win, because that's
harder to hide--the backdoored authentication code now has to stash
the unencrypted password in the request somewhere, rather than being
done in the server where it's completely invisible to users.

Did you have any particular uses in mind?

-- 
Glenn Maynard

Received on Tuesday, 21 December 2010 23:39:20 UTC