This is good advice but just a note - the point is to be as simple as possible. With SSL and a good password there is no hacking that I know of. If I started doing a lot of this the file would get bloated and the readability and extensibility of the code would go drastically down IMO.
- You're using md5, which is trivial to compute in bulk. Rainbow tables are a thing that exist.
- You're exposing the hash that you generated over the wire, in a cookie.
- You're doing fail-fast comparisons, which has the potential (particularly when combined with the ease of pre-generated md5 hashes) for timing attacks.
That's just a few off the top of my head, that could be fixed in minutes, at a guess, and add near-zero complexity to your code.
Doing things better doesn't inherently add complexity, particularly as you're using php. The primitives are already there for you to use.
The one change I'd suggest that requires a little bit of adaption rather than just swapping a function call, is to not store the password in clear text. Provide the user a way to generate a hash (not using fucking md5), and have them store that. Given that you're already using an sqlite db, ideally you'd store the credentials in that, thus allowing the user to change their password if required, without needing to deploy/upload a new file.
Use `password_hash` rather than md5.
Use `password_verify` rather than regular string comparison - it's resistant to timing attacks.
You're already using the built in session system apparently, so let it worry about tracking the logged in user. In something as simple as this there's no reason you should need to write a cookie directly.
Store something (e.g. username, or even just a boolean true) in the session data. Check for that value when you need to check if the user is logged in (after the session has started). If it's found, they have a session and are logged in, if it's not found, there's no active session, thus they're not logged in.
