Are there any other account system attacks I should be aware about?

Question

Not fully sure if these types of questions are allowed here, but don't see anything against it in the help centre so I'm assuming it is. Please point me to a better place to ask if it's not!

I'm making an account system for my website and trying to do my best to protect accounts from several types of attacks but a bit worried, possibly paranoid, that I'm going to miss some. I've not completed the sign-in page yet, but this is the code that allows users to sign up https://hastebin.com/isuhiwavex.php. Currently, I'm trying to:

• Protect it from bots, brute-forcing and other similar suspicious activity using ReCAPTCHA v3 (allowing scores higher than 0.5)
• Requiring passwords be more than 8 characters and contain both upper and lower case characters
• Encrypting passwords with Argon2id with paramaters that take ~0.5 seconds for my server to process (memory cost 20000, time_cost 17, threads 2)
• Making sure emails are in a valid format for XSS and general validity
• Formatting HTML special chars in the username, also for XSS
• Making sure accounts can't be created with usernames/emails that already exist

When I make the login page, the only extra I plan on adding is that only 3 login attempts can be made per minute per IP. I realise an IP isn't the best way of identifying people, but wasn't sure what else I could get that could be stored in my database easily.

Answer 1

I'll assume that you've asked for another set of eyes to pass over your logic and its code impl that you linked to in your question. (If you edit your question with more detail then I might update this answer.)

The use of ReCaptcha has the potential to leak PII depending on what's included in your signup form. TODO: link to terms. You might consider the use of hCaptcha or review which fields are exposed.

The requirement for upper- and lower-case characters is unnecessary if the user is providing a high-entropy password. In my opinion you'd get more mileage imposing a longer minimum length, however, this may frustrate some users further.

There are a couple of things worth noting in the implementation ...

  if (strlen($_POST["username"]) < 4 ||
      strlen($_POST["username"]) > 32 ||
      strlen($_POST["pass"]) < 8 ||
      preg_match("/^(?=.*?[a-z])(?=.*?[A-Z]).*$/",$_POST["pass"]) == 0 ||
      preg_match("/^.{1,128}@.{1,63}\..{2,24}$/",$_POST["email"]) == 0) {

and

  $_POST["pass"] = password_hash(
    $_POST["pass"]
    , PASSWORD_ARGON2ID
    , ['memory_cost' => 20000
        , 'time_cost' => 17
        , 'threads' => 2 ]
  );

Prob here is password length is unbounded, and will wind up at the maximum length that php.ini or other config will allow a POST to be (depending on what type of <form> you've presented your user/s). I propose limiting this maximum to some sensible upper limit (eg. 4096, ie, 4k) to reduce opportunity for resource depletion attacks. (This gets fed into the password hashing routine.)

Also that regex match on the password doesn't seem right to me, but I'm a bit rusty with PHP and regex. It seems that the password must have a lower-case followed by a upper-case char, or it's not valid. (Assuming (?= is a positive look ahead, but happy to be corrected.)

(caveat: I'm not certain exactly if PHP uses the Libsodium impl that I've linked to - I might follow this up at some point when i have more time...)

I checked the Libsodium function that (probably) underlies password_hash() and it does indeed limit Argon2id to a single lane and thread. I haven't been able to find much on this Libsodium design decision, however, on reflection there's a "risk management" argument for this: an errant process won't leave your system unresponsive. (You can also see it takes bytes as input and converts to kB, which was the source of my earlier confusion in my comment.)

(Btw I was confused about PHP throwing an error for specifying more than one thread: it seems to me that it only does that if you use the sodium_password_hashX() functions. My prior experience has been using sodium_crypto_pwhash(), which is a more direct route to the Argon2id hashing function, and the best option if you need compatibility between Python- viz. Pysodium- and PHP.)