- 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?
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.
It’s not as bad if it’s only on sign up, because you’re normally not autofilling there. But it’s still bad for accessibility
It’s definitely not as bad for sign up, but it’s still a problem because usually after hitting “submit”, the password manager will detect what you just did and pop up something like “want me to save that?”
The only thing I’d note is to be careful with your issue #2, because this sounds like it could break with autofill. Some autofill implementations may fill invisible fields (this has actually been an attack vector to steal personal info), so blocking the IP because an invisible field labeled “email” has been filled could hit users too. Otherwise, 100% agree!
Yes, it may come at a price. But some people are okay with that.
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.
For the first issue you may as well add the “yahoo trick” (from before SSL) and pre-hash your user’s password with a random string (provided by the back-end) once the before sending them.
The ideia is that once the person opens the login page your backend will generate a random string and save it for the session, also sends it to the frontend. Then when the user clicks login your frontend does
sha512( sha512(password) + random_string )and sends the results to the backend. Then the backend knows who’s session that is, retrieves the previously generated string from the database and doessha512( stored_password_hash + random_string ). This can be further improved by adding a TTL to the random string, make sure you delete them once the login is successful, force the frontend to refresh the login page on error and issue a new string (just don’t sent a refresh over XHR as it will can be picked by bots / make an attacker life easier.Note 1: that the frontend first hashes the password and THEN concatenates the random string and hashed again - this has to be made this way because your server should only store hashed versions of your password.
Note 2: consider the implications of just doing SHA512, stronger algos like bcrypt, PBKDF2, and scrypt should always be used, I was just explaining what can be done and the process.
Note 3: consider the usability / accessibility / password managers when creating fields dynamically and with random IDs.
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.
[TOTP] Simple to setup / create, doesn’t depend on 3rd party …
Actually I’m worried its a bit TOO easy to create. I don’t need a bulletproof/airtight system but what’s stopping highschooler from installing bluestacks, downloading the AUTH app, and then handling 10,000 TOTP requests for different bot accounts.
First, that would be a very targeted attack and the typical bots won’t have provisions for a forced TOTP on the first login + account deletion after 5 days if no TOTP is setup.
Second you can make things harder, TOTP should be combines with other anti-burteforce measures, restrict the number of registration on an IP address, add delays here and there to make it annoying etc.
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.
Benefits - costs: If your benefits from having less spam and the work they are doing by solving the task are greater than your costs this is acceptable.
Doesn’t work on Mull browser (hardened Firefox for android) :(
Interesting, does it block js or something?
It uses the arkenfox thingie. It doesn’t block JS, but it does block a lot of things and possibly certain JS features.
While I’m really glad to hear about it, I think it would work great for DDOS detection, I don’t know that it works for preventing spam accounts. I’m pretty sure puppeteer with GPT4 could check that box no problem.
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.
It was Proton
It’s sad they haven’t made it so anyone can use it
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.
“training neural networks to recognise protestors”
Good one
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.
User created invites and admin approved application texts work fine.
Plus, that way, you have a trail of invites. If something goes wrong, you can prune entire branches and mitigate most abuse.
Is hCAPTCHA not acceptable? There are other privacy-respecting CAPTCHA solutions available as well.
PoW? The client need to do some computation before the server takes the like signup or signin or something. Not 100% foolproof but can thwart some bot attempts I guess.
PoW sure, but like what’s the tool name. Rolling my own PoW sounds not-smart. I’ve messed with metamask a bit but last I check isn’t real practical for mobile.
2fa can be handled by a cycling number like authenticator apps
Just some mild hoops to jump through will prevent spam. On my email service, Port87, I use a waitlist. I don’t use it specifically to prevent spam, but it does do that very well. Then you email invite codes to the people who join the waitlist for them to create an actual account. If you start seeing spam entries in the waitlist, just delete them.
I mean, manual approval technically does work. I kinda wanted something that would scale.
Can you do some sort of proof of work? That doesn’t cut down all the bots, for sure. But it cuts down mass creation of accounts.
Edit: Have a look at how the Tor Project has managed distributed denial of service or mini-cryptocurrencies such as Monero
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.
Try CloudFlare Turnstile - a lot cleaner than recaptcha.
