Authentication

1. https://paragonie.com/blog/2015/04/secur...ersistence <- read it and learn from it.
2. Printing the mysql error is very bad and very dangerous.
3. https://stackoverflow.com/questions/5741...ape-string <- do you mean this?

I read the article you gave me and it covers the following things.

• Use acceptable password storage systems (I do, I use bcrypt)
  
• When using bcrypt the password limit is 72 bytes (Nobody ever has a password that is 72 characters long)
  
• When using bcrypt the password is truncated when there's a null byte (I use server-side validation to check if the submitted password is blank or not.)
  
• Do not pepper a bcrypt hash (I already don't do this.)
  
• Passwords must be 12 characters in length (This is untrue. I could use bcrypt to encrypt one byte, one ascii letter, and no computer network will be able to decrypt it as there is an incremental cost in decrypting bcrypt passwords and encrypting the same plaintext gives a different ciphertext each time. In the olden days this suggestion made md5 passwords unable to be decrypted with a rainbow table, but as rainbow tables have advanced, this advice is useless.)
  
• A password must be on level 3 (This is untrue. See above.)
  
• Password can contain any characters. (I don't limit what characters can be in a password.)
  
• Use a password manager (What a stupid idea! What if you forget your password manager password or you get a virus or your hard drive fails? Then you've lost all your passwords.)
  
• Don't just store user credentials in a cookie (What the article is referring to is putting a user id as a value of a cookie which allows someone to login, but someone can use Inspector to change their cookie value to whatever number they want to login as someone else. Of course I have not done this approach. I store the bcrypt encrypted password as a cookie which of which the password cannot be decoded and anyone doing cookie spoofing to login to other accounts is subject to brute force prevention.)
  
• Don't use persistent authentication tokens (I don't use this and never have.)
  
• Don't use insufficient randomness (No randomness is needed for my authentication system.)
  
• Beware of timing attacks (My authentication system has brute force protection to prevent timing attacks. I'm not vulnerable to cache timing attacks or branching based timing attacks but I was vulnerable to comparison attacks so I've improved my code to get rid of that vulnerability.)
  
• Resetting a password through an answer to a security question is bad security (only email providers generally do this, I send a password reset link to the user's email address)
  
• Use PGP keys for password resets (My users aren't technologically savvy.)
  

Out of 17 tips, I was vulnerable to only one of them, which I've now fixed.

I did mean that Stack Overflow thread. By the way, I can find over 5 or more ways from the internet which allow me to exploit mysqli_real_escape_string for sql queries which are not listed on the Stack Overflow website.

I have lost count of the amount of times I have seen technical error messages printed on websites and programs. Printing these messages serves the purpose of allowing the user to email the admin (me) that there was an error when they tried to do something and tell me what error message they saw so I can fix it. As not all errors are exceptions, if I use Sentry to automatically send php exceptions to my email address, there will be errors that Sentry does not catch that I will miss out on if I don't show the error, so it's best to show it.

Even youtube shows errors. When youtube has an error, you're given a bunch of words to contact Google with about it.