Authentication

A good framework is KISS. Keep It Simple Stupid. There's no point in having software being bloated because it's full of features people won't use. That's how software fails then nobody uses it.

It takes me 5 minutes to write an authentication system, (1 minute if I copy and paste), so why do I need a framework to do what I can do in less than 5 minutes?

And besides, it's very easy to create your own authentication system. Here's one I got from Techtuts that I improved myself.
https://gist.github.com/desbest/4cc0046a...5e74cbc4ff

If you are too lazy to code your own authentication system, you can use a company's authentication system and integrate it onto your own website or use php classes or Pixel2Life [2]

A good framework is KISS. Keep It Simple Stupid. There's no point in having software being bloated because it's full of features people won't use. That's how software fails then nobody uses it.

It takes me 5 minutes to write an authentication system, (1 minute if I copy and paste), so why do I need a framework to do what I can do in less than 5 minutes?

And besides, it's very easy to create your own authentication system. Here's one I got from Techtuts that I improved myself.
https://gist.github.com/desbest/4cc0046a...5e74cbc4ff

If you are too lazy to code your own authentication system, you can use a company's authentication system and integrate it onto your own website or use php classes or Pixel2Life [2]

You code is unsecure. Pls learn about sql injection

A good framework is KISS. Keep It Simple Stupid. There's no point in having software being bloated because it's full of features people won't use. That's how software fails then nobody uses it.

It takes me 5 minutes to write an authentication system, (1 minute if I copy and paste), so why do I need a framework to do what I can do in less than 5 minutes?

And besides, it's very easy to create your own authentication system. Here's one I got from Techtuts that I improved myself.
https://gist.github.com/desbest/4cc0046a...5e74cbc4ff

If you are too lazy to code your own authentication system, you can use a company's authentication system and integrate it onto your own website or use php classes or Pixel2Life [2]

I took a look at your github page and I would like to note that writing a auth app can be very easy as you say indeed, but writing a secure login system is a whole lot of work...

Passing $_POST varIables straight into your sql queries makes you vulnerable to sql injection. You should read up on some basic php security issues.

I took a look at your github page and I would like to note that writing a auth app can be very easy as you say indeed, but writing a secure login system is a whole lot of work...

Passing $_POST varIables straight into your sql queries makes you vulnerable to sql injection. You should read up on some basic php security issues.

That's why you use a server firewall like mod_security or Suhosin and pay for Comodo Firewall to add rules to mod_security. The server firewall escapes ALL the sql queries for you so you don't have to worry about remembering to escape every string individually.

The php functions that php gives you for escaping strings can easily be bypassed by hackers, so a server firewall provides much better protection from hackers.

I don't trust the php functions for escaping strings, and neither should you. Even Stack Overflow had answers about how to bypass the php sql escaping functions.

I took a look at your github page and I would like to note that writing a auth app can be very easy as you say indeed, but writing a secure login system is a whole lot of work...

Passing $_POST varIables straight into your sql queries makes you vulnerable to sql injection. You should read up on some basic php security issues.

That's why you use a server firewall like mod_security or Suhosin and pay for Comodo Firewall to add rules to mod_security. The server firewall escapes ALL the sql queries for you so you don't have to worry about remembering to escape every string individually.

The php functions that php gives you for escaping strings can easily be bypassed by hackers, so a server firewall provides much better protection from hackers.

I don't trust the php functions for escaping strings, and neither should you. Even Stack Overflow had answers about how to bypass the php sql escaping functions.

Censored! Playing nice! Censored!

You code is garbage:
- saveing pw in cookie
- no sql protection
- printing error message
- missing password_needs_rehash

Drat! Darn! Bejeebers!

You code is garbage:
- saveing pw in cookie
- no sql protection
- printing error message
- missing password_needs_rehash

Something has to be stored on the user's computer so the website can recognise whether the user is logged in or not. You can't authenticate a user using just sessions. And whatever is stored on the computer has to MATCH what is on the server that is assigned to the user. It doesn't matter if it's a password or a random string that's not a password, because it has to match up to what's on the server assigned to the user anyway.

You might want me to validate ip addresses for in case cookies are stolen, but if someone has a dynamic ip address, they'll experience the bother of being repeatedly logged out. For extra security, when logging in, the user's ip address can be checked against other ip addresses's that have logged in for that user in the past. It should be easy to add that feature into the code I shared.

I'll repeat again, the sql escaping functions that php provides programmers in their programming language, such as mysqli_real_escape_string, has been broken and can be exploited very easily by doing a quick search on Stack Overflow, so you should rely on a server firewall to protect against sql injections. Having faith in using php to escape sql is like having a front door to your house made of paper if you rely on php's sql escaping functions.

The error message is printed because on all my websites there is an email form for the user to email the admin (me), so if for some rare and strange reason they cannot register to the website not only do they see a generic "signing up failed, you could not sign up because of an error" they see the exact error so they can email me the error they saw.

If i used sentry all php errors would go to my email automatically but it is good to print the error for that reason as well just to be safe. There are some errors which sentry cannot catch as they are not exceptions, so it makes sense to print some errors just in case something goes wrong so the user can email you about it, rather than not print the error at all, the user repeats themselves 2-5 times, gets frustrated at the website not working, leaves and never comes back. Printing errors can improve user experience and increase retention. 

Not every error is an exception, so if I used Sentry to automatically send all php errors to my email address, it would not catch all errors, as not all errors are exceptions. It makes sense to print some errors.

The authentication code I provided uses bcrypt to encrypt the passwords. The password already is rehashed using bycrpt as it is using a default strength of 3-5 (I forgot the number). The bcrypt algorithm has not yet been cracked like md5 or sha16. With bcrypt it takes an exponential amount of time to brute force due to the fact that generating a password in bcrypt has a cost unlike mdfive or shathirtytwo where someone can pay for hundreds of amazon ectwo servers to crack passwords at a low price

And by the way, ehasing passwords doesnt make it any less likely to be cracked you can rehash an mdfive hash millions of times with a salt and it will still be cracked in five minutes.

You code is garbage:
- saveing pw in cookie
- no sql protection
- printing error message
- missing password_needs_rehash

Something has to be stored on the user's computer so the website can recognise whether the user is logged in or not. And whatever is stored on the computer has to MATCH what is on the server that is assigned to the user. It doesn't matter if it's a password or a random string that's not a password, because it has to match up to what's on the server assigned to the user anyway.

You might want me to validate ip addresses for in case cookies are stolen, but if someone has a dynamic ip address, they'll experience the bother of being repeatedly logged out. For extra security, when logging in, the user's ip address can be checked against other ip addresses's that have logged in for that user in the past.

I'll repeat again, the sql escaping functions that php provides programmers in their programming language, such as mysqli_real_escape_string, has been broken and can be exploited very easily by doing a quick search on Stack Overflow, so you should rely on a server firewall to protect against sql injections. It's like having a front door to your house made of paper if you rely on php's sql escaping functions.

The error message is printed because on all my websites there is an email form for the user to email the admin (me), so if for some rare and strange reason they cannot register to the website not only do they see a generic you could not sign up because of an error they see the exact error so they can email me the error if i used sentry all php errorts would go to my email automatically but it is good to print the error for that reason as well just to be safe

the password already is rehashed using bycrpt as it is using a default strength of three four or five one of the three the bcrypt algorithm has not been cracked and it takes an exponential time to brute force due to the fact that generating a password in bcrypt has a cost unlike mdfive or shaone and by the wayn rehasing passwords doesnt make it any less likely to be cracked

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?

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. 

Storing the password and username in cookie is bad, because if someone steal the user table, the person has no problem to login. A login token is more secure.
Thhe mysql_error, mysqli_error and the pdo error should not be printed, because it contains sensitive information. Print a custom error message.
You should always print a custom message.

Show us an example how to exploid mysqli_real_escape and pdo/mysqli prepared statements

Storing the password and username in cookie is bad, because if someone steal the user table, the person has no problem to login. A login token is more secure.

A login token is stored on the server too. Something on the user's computer has to MATCH up with what's on the server, to authenticate the user. The only way to bypass this, is to have a PGP system written in javascript, where the authentication is not on the server but instead in the web browser on the user's machine. Mozilla tried to make this by making BrowserID.

If someone steals the user table or the database through an sql injection, they can login anyway, regardless of whether I store the username and password as a cookie or not. Sony didn't store the user id and password as a cookie on their user's computer, but they still got hacked with an sql injection by Lulzsec and got their database leaked online for everyone to download on torrent websites. What credentials they stored on the user's computer was irrelevant, if someone knows how to do an sql injection, they will. It's just a matter of entering a line of code on a computer program to test for a vulnerability.

Here's another thing, mysqli_real_escape and pdo/mysqli prepared statements aren't foolproof, there are ways to bypass them too. It's like countries having border control. The border control gets tougher and tougher, there are more and more rules of what gets caught, but as always, some people or some hackers manage to sneak through because the security people don't know all the rules and techniques. They don't know what the blackhat hackers know. If I knew how to do it, I would know how to hack into 90% or more websites online, so do you think I would tell you how to do it and give away my secrets? Seriously?