• 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?

  • TCB13@lemmy.worldEnglish
    0·
    7 months ago

    Assuming your issue is bots bruteforcing things and not bots creating fake accounts: 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”.

    • steersman2484@sh.itjust.works
      0·
      7 months ago

      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

      • ReveredOxygen@sh.itjust.worksEnglish
        0·
        7 months ago

        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

        • Zagorath@aussie.zoneEnglish
          0·
          7 months ago

          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?”

    • xxd@discuss.tchncs.de
      0·
      7 months ago

      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!

    • RenardDesMers@lemmy.ml
      0·
      7 months ago

      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.

    • jeffhykin@lemm.eeOP
      0·
      7 months ago

      [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.

      • TCB13@lemmy.worldEnglish
        0·
        7 months ago

        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.

    • TCB13@lemmy.worldEnglish
      0·
      7 months ago

      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 does sha512( 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.

    • RobotToaster@mander.xyz
      0·
      7 months ago

      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?