[omribahumi]

I have an interesting idea.

How about make the login process more resource intensive on the browser side, by running some intensive javascript code before sending it to the server?

The trick would be to make this much more intensive on the client side (say 1s of CPU time), while keeping this relatively easy for the server (say 1ms). We're trying to waste their resources, not ours.

One way I can think of:

1. server sends a random seed to the client

2. client calculates 1000 hashes based an random numbers generated from the seed, something like hash(rand() + password) and sends them to the server

3. server picks a one of those and validates it. In case the hash isn't valid, you'll respond with an invalid password, so the client won't be able to distinguish between a failed authentication because of hash validation or because of a wrong password.

[jimmies]

That's doable but you have to process a lot of traffic from the clients because the client would have to send all the answers it has calculated.

Do exactly what bitcoin does: You send a random prefix and require the client to find a random suffix so that hash(prefix+suffix) ends with, say 4 zeros.

[salawat]

So. Someone is wasting your time, so you want to start wasting everyone's time and natural resources playing games with a script?

Stay away from trying to increase computational overhead. Everyone thinks computation is "free", but it isn't. There is a turbine somewhere cranking out annoyed pixies to drive your computation war with this botnet. The fact some actor has decided to distribute the energy cost to someone else doesn't mean you have to double down on the waste by multiplying the botnet operator's energy expenditure being dealt with by oblivious user's a thousandfold.

It's a bit like global thermonuclear warfare. The only winning mover is not to play.

The least resource intensive way of dealing with it is just detection and either preemptive drop (no more useful info) or if you want to get creative, start doing some whois digging with IP's and start blowing up some operator's inboxes with questions as to why you are getting malicious login traffic from their IP block so they can start running down the source from their end.

This is the Internet. We don't know everything going through it, but most operator's are generally open to trying to keep transits clean if they are made aware of a problem in a way that doesn't seem like a DDoS aimed at their time.

[omribahumi]

That's cool. Didn't know that bitcoin does this. It sounds like a much better approach.

I guess you can fine tune how complex you want this to be by changing the number of zeros you require.

A friend suggested something else - make the client bruteforce a short RSA key (of say, 100 bits)

[est]

proof of work. used a lot in email anti-spam.

[omribahumi]

Wasn't familiar with the term.

Thanks!

[sschueller]

Or add https://coinhive.com which will put a load on the client and make you a bit of money.

Can be used like a captcha or placed in between a process. You just specify how many hashes need to be completed before proceeding.

[foepys]

Very bad idea. This might get your page flagged by anti virus scanners or even search engines.

[zerostar07]

If you manage to do it for only suspicious-looking login attempts, thats actually a great way to both stall them and benefit. it just feels so much win

but are these scripts sophisticated enough to run JS etc?

[foepys]

If you fail to detect a bad botnet once and show the mining script to an important crawler (like a search engine), and then land on a blacklist, it could potentially require a huge effort to get off it again. It's simply not worth the risk.

[x0]

Some of them can run Javascript, I'm thinking specifically of people who write scrapers in things like PhantomJS (headless browser, very very cool software).