• 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

    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.