Yeah I would love to find a way to support non-JS browsers. For now I considered it out of scope. I could very easily make a browser extension or companion app for it though!
My suggestion is that if the script fails (for whatever reason, including non-JS browsers), then in addition to doing what they said (spits out some token), should also link to documentation about how to compute the response. If the user has a program to do it, they can use that one. If not, they might be able to write their own (by following the documentation).
It sounds really scary at first, but once you start using it in practice, it's not so bad. As the developer, you simply locate your lowest common denominator device (older cell phone) and test it out a few times, adjusting the difficulty as you go until it generally happens fast enough for the UX to be unaffected. Usually after 10 or so tries you get a good idea for the feel of it.
There are tons of things in nature that are like this, for example how long it takes a spinning quarter to topple over on the table and land heads or tails. Its theoretically possible it could balance perfectly and never fall, but how many times have you seen that IRL???
Yes, unfortunately I don't know anyone who uses a screen reader personally and I've never spent the time to learn how to use one myself.
So I don't really have a great way to make it accessible to blind users at the moment, but it's only a couple code changes away, while most other "Captcha" solutions might require a redesign before they could be considered accessible.
yes, but they cant create 1000s of fake users on EVERY website, unless they wanna shell out millions of dollars per year for the compute power required.
In short, the Scrypt hash function was designed for this. With SHA256, the "toaster" you were refferring to is called an ASIC and you can buy one for $200 that plugs into a USB port and it would hash faster than 2 million CPUs.
However that's not possible with Scrypt, especially with the relatively large memory cost and block size parameters that this software uses. Even GPUs choke on scrypt at these levels. See: https://www.mobsec.ruhr-uni-bochum.de/media/mobsec/arbeiten/...
You misses the point. It does not matter what kind of technical implementation or algorithm is used. If the average user hardware can solve the "captcha" in a meaningful time on average hardware then an attacker with optimized hardware and on scale can always solve millions of these "captcha" relatively cheap. If you increase hardware demand to slow down an attacker you just exclude more and more legitimate people. Sure the attacker maybe can only spam 500k messages instead of 1MM in the same time but you also reduced the legitimate user by 50%.
Even in the absolute worst case where no optimization is possible at all the attacker can still run a device 24/7 so if a normal user has to wait 20 second on a smartphone an attacker can spam at least 4320 messages per day with the same device. And it scale at least perfectly linear. 2 such devices would double the spam capacity.Aand if the block sizes are increased to slow the attacker down it is exactly as much as it slows down the real user. But the real user actually cares and gets annoyed the attacker does not, he keep the same spam/legit message ratio.
Hi, developer here, there is a table showing hashes per second on various devices at the bottom of the readme. My laptop (thinkpad t480s) = 70h/s, my phone (motorolla g7) = 12h/s. Its not so bad on the phone. The site owner can tweak the difficulty for whatever lowest common denominator they want.
