2FA is a good defence against it, but lockouts are less as they attacker will be going broad and not deep (could be a single request per user account)
Even as a newcomer without the right contacts on the black market you can get started with very little upfront investment, using services like https://luminati.io/ (they pay software developers to bundle their proxy endpoints within their apps).
We always used to laugh at people who did website security with javascript, the whole idea was that security processing had to be done server-side.
But with security at this level nowadays every added layer helps. Even if it is not even used in the initial authentication step. Think of classifying certain patterns in the attacks and retroactive de-authorizing after login, increasing the time-cost for the attacker.
1. Preventing interception of passwords on the wire
2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective
3. Requiring that brute-force attackers either run a Javascript interpreter (dangerous, because the web site chooses what they do and could make them mine Bitcoins) or rewrite their brute-forcer each time the JS-driven network communication channel is altered
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...
Isn't this solved by https? I have no idea, but I hope at least that https protects my passwords.
>2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective
I don't want to wait for a login more than a second. Actually, I don't want to wait at all.
>3. ... or rewrite their brute-forcer each time the JS-driven network communication channel is altered
How is this different from altered HTML/CSS? An attacker has to adapt to the altered login page. It is not an argument for javascript.
>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...
You say it: a protocol! not a piece of javascript.
Neither do I. But I also accept that, given the sheer volume of stolen creds and bots out there, sites that damage their bang/buck performance, even at the cost of very minor inconvenience to users, are likely to be targeted less frequently and in lower volume. Even if I wasn't begrudgingly willing to pay that price, I'd at least admit to the logic of making the process more time-consuming as a deterrent.
Do you log in that often?
"Think you are clever, eh, try this for size..." -- some attackers in response to being affected by your counter measures.
> 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.
Have the server side not know the password
And be secure against replay attacks given attacker access to plain text.
The scheme is something like:
Setup
Server generates key (x, xG) where G is some elliptic curve base point. It stores x and sends xG to the client.
The client computes y = H(password) and sends yG to the server.
The server stores the shared secret. x (yG)
Authentication:
Server generates nonce r and sends r xG.
Client computes y = H(password) and responds with y r xG
Server verifies that the response equals r (x yG).
End
In this protocol, an attacker with access to plain text, even during setup, still can't do anything.
This method is weak against MitM, but that can be solved on auth by doing a fully ephemeral diffie helman there.
I concocted this scheme on like 10 minutes, so there might be mistakes, and it os probably suboptimal.
Client-side js will always be readable, even if you obfuscate it, you can't trust it to never being decompiled.
But server-side js never has to reach the client, it can be used to dynamically generate basically anything.