- 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?
You must log in or register to comment.
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn’t great, if contents of the website are behind a paywall maybe copy them into the post
- Don’t promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
Chat rooms
-
[Matrix/Element]Dead
much thanks to @gary_host_laptop for the logo design :)
- 0 users online
- 84 users / day
- 537 users / week
- 1.5K users / month
- 6.58K users / 6 months
- 1 subscriber
- 2.3K Posts
- 53.3K Comments
- Modlog
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.
Is hCAPTCHA not acceptable? There are other privacy-respecting CAPTCHA solutions available as well.
https://github.com/ndbiaw/haproxy-protection
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.
Try CloudFlare Turnstile - a lot cleaner than recaptcha.
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.
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.
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.
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.
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
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
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.
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:
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.
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.
could this cause accessibility issues for screen readers?
I’m sure it will, it may also break a few password managers.
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.
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.
Password managers hate this trick
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?”
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.
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.
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.
It was Proton
https://proton.me/blog/proton-captcha
It’s sad they haven’t made it so anyone can use it