- I make websites
- If someone is banned twice (two accounts) I want it to take them more than 5min and a VPN to make a 3rd account
- I’m okay with extreme solutions, like requiring everyone to have a Yubikey-or-similar physical key
- I really hate the trend of relying on a phone number or Google capcha as a not-a-bot detection. Both have tons of problems
- but spam (automated account creation) is a real problem
What kind of auth should I use for my websites?
2fa can be handled by a cycling number like authenticator apps
Try CloudFlare Turnstile - a lot cleaner than recaptcha.
I do this for part of my reg forms. I split the reg process into two parts. First, supply email only. This element uses an obfuscated id. Once they do that, the link sent to their email leads to the rest of the process, using no obfuscation. This should keep from breaking password managers.
Regarding login bruteforcing. I give them 3 shots then a cooling down period.
This process has resulted in a 0% success rate for bots so far. We will see how it holds as the domain sees more traffic.
mCaptcha is a proof of work pseudo-captcha, it won’t block bots completely, but it heavily rate limits them and makes them computationally expensive to run.
If I remember correctly I saw that Proton mail (or was it Yandex translate ?) created their own reCAPTCHA, where you’d have to slide one piece outside of a puzzle into the gap of the puzzle. Neat.
Tor browser user here, btw.
Yeah, I find the puzzle sliding JavaScript captchas the best as a user. Cognitively better than “training neural networks to recognise protestors”, and still fast enough that it doesn’t feel like a forced ad. Reliability might however vary a lot between implementations.
Yandex one is correctly recognizing different symbols and tapping them in order. It was rather violent when it showed at any other click when I used it with adblocks and denied tracking while searching for images.
Issue #1 - bots bruteforcing login forms: add a 2FA in form of a TOTP? Simple to setup / create, doesn’t depend on 3rd party services and it is less extreme than a Yubikey while providing the same level of security. If you can enable that for all users you can add it straight to the login form after the password, this way bots won’t even know if a password they try is correct or not, you can refuse them all with a simple “email, password or 2FA code incorrect”.
Issue #2 - bots creating fake accounts: decoy email and password fields on your registration form helps reducing the number of fake accounts. Create your input for email and password with the id / name “email” and “password” and hide them with CSS. Then you create the real inputs with an id like “zipcode” or some other thing that would throw bots off. Server side you set that if the email and password inputs are submitted with anything else than an empty value it should return 401 and/or block the IP address. You can play a lot with this and add checks both client side and server side. To step up the game you can create all those fields dynamically in JS with random IDs based on some algorithm so the backend knows how to identify the real ones.
There are also a few self-hosted captcha options that can be as full featured as google’s or simply add a few font awesome icons and ask people to pick the right one.
Updates:
- As many said messing with the input type, name and ID may break password managers and kill accessibility. Depending in your use-case you may or may not want to use those techniques - note they’re very effective either way;
- You can also leverage 2FA to avoid fake accounts. Require users to setup 2FA when they’re creating an account - bots won’t be able to handle that and accounts won’t get created. You can also delay the process, like allow people to register as usual and on the first login force the 2FA setup, accounts who don’t set it up in, let’s say, 5 days get automatically deleted;
- Use the “yahoo trick” to render bots unable to login.
Create your input for email and password with the id / name “email” and “password” and hide them with CSS. Then you create the real inputs with an id like “zipcode” or some other thing that would throw bots off.
Password managers hate this trick
I suspect screen readers and a11y tools hate this as well.
Trust me, as a screen reader user, things like this make our lives absolute hell.
bots creating fake accounts: decoy email and password fields on your registration form helps reducing the number of fake accounts.
could this cause accessibility issues for screen readers?
I’m sure it will, it may also break a few password managers.
Please be wary of accessibility with #2. Password managers can also fail with this solution. Every time you mess up with the basic web, you have to think about password managers and people with disabilities.