JavaScript is now required to sign in to Google

> 1. Preventing interception of passwords on the wire

It can, but challenge-response that isn't PKI based requires the remote side to have the secret stored or the local side to know how to generate the value that is stored instead, which goes against other recommended practise (with PKI the remote side can store the public key and ask for something to be signed with the private key).

Protecting passwords on the wire is better done with good encryption and key exchange protocols - in the case of web-based systems that is provided by HTTPS assuming it is well configured.

> 2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective

Could you give an example of that? If you are tuning difficulty based on the computation power of the other side, surely the other side could lie about being low powered and get an easier challenge?

> 3. Requiring that brute-force attackers either run a Javascript interpreter (dangerous, because...)

A knowledgable attacker doing this would be safe: they'd make sure the interpreter was properly sandboxed (to avoid reverse hacking) and given execution resource limits (to avoid resource waste). Then if the site/app is important enough that they really want in, they modify their approach if the resource limits are hit.

> or rewrite their brute-forcer each time the JS-driven network communication channel is altered

If your method is only used by you (and you aren't a Google or similar so you are big enough to be a juicy target on your own) and you enter into this arms race you might find it takes so much resource that it gets in the way of your other work. You are only you, the attackers are legion: put one off and another will come along later. Also there is the danger in rolling your own scheme that you make a naive mistake rendering it far less useful (potentially negatively useful: helpful to the attacker!) than your intention.

If the method is more globally used then it is worth the attackers being more persistent.

> It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification.

It can, though often only against simple fully automated attacks. Cleverer automated attacks may still succeed, as may more manual ones, and targetted manual attacks will win by inspection & replication.

Or they get in through an XSS, injection, or session hijacking bug elsewhere (bypassing the authentication mechanisms completely) that you missed because you spent so much time writing an evolving custom authentication mechanism.

"Think you are clever, eh, try this for size..." -- some attackers in response to being affected by your counter measures.

Why would you want to see actual user password if you can just not see it?

If you see a password you can leak it by screwing up in numbers of ways. If you never see a password you just can't leak it.

E.g. Twitter recently discovered that they were storing passwords in plaintext in logs, GitHub had similar issue.

Take a look here: https://arstechnica.com/information-technology/2018/05/twitt....

Of course, a hash that you will receive from client should be treated as a normal password including all good practices.

Why would you want to see actual user password if you can just not see it?

If you see a password you can leak it by screwing up in numbers of ways. If you never see a password you just can't leak it.

E.g. Twitter recently discovered that they were storing passwords in plaintext in logs, GitHub had similar issue.

Take a look here: https://arstechnica.com/information-technology/2018/05/twitt....

Of course, a hash that you will receive from client should be treated as a normal password including all good practices.