No. Actually we would not want the hashing technique to be exposed in the source code.

That turns out not to be the whole story.

Hiding the technique to compute the hash is relying on security by obscurity. Ideally you want a system that is secure even if potential attackers know what methods you're using.

If you do the hashing on the client side, then the hash itself effectively becomes the password.

That would assume your users have JS enabled. I've seen something like that done before, but always with a fallback in case user has JS disabled.

If you're not sending 20 megs of data, you're not getting 20 megs of security. So why allow it if it doesn't add anything?

It doesn't add to the security, but I might find it easier to remember 20 MB of redundant and meaningful stuff than to remember 384 bits of literally random stuff. The entropy might be the same, but my memory is not a computer. I can remember vast amounts of material that is meaningful and use it as a password. I can't remember 384 bits that have no meaning.

The benefit isn't in the entropy, it's in the abilities of your users to remember their passwords/passphrases in the first place.

Maybe 1 or 2 KB, max. 20 million characters is a ridiculous password to remember.

That's not the point - the difference between 2 KB and 20 MB is purely a detail. You said:

  > If you're not sending 20 megs of data,
  > you're not getting 20 megs of security.
  > So why allow it if it doesn't add anything?

You could just as equally say:

  > If you're not sending 2 KB of data,
  > you're not getting 2 KB of security.
  > So why allow it if it doesn't add anything?

Your point is the same, and it's still wrong. What you're getting is not the security - that's only half the story. My point is that is does add something, it's just that the something it adds isn't the entropy for the purpose of security.