Basic cookie based login system
This type of login would usually be implemented in public places like schools or coffee shops because it uses client based ban, which in itself is a weakness as cookie can be reset after each ban. It would require extra scripting but this means that the login form can potentially be brute-forced. But why this is an advantage in public places is because it prevents from internal abuse of banning the real admin from accessing the backend. For example, if done with MYSQL and ban the external IP address after certain amount of attempts, then the admin would also be banned even if someone else inside LAN but with the same external IP address played with login form before. And just for clarification, unless the website is hosted on the same IP address, banning the internal IP addresses won't work and is completely pointless. The code is explained here.
Download:
File: cookie_login.zip
Licence: MIT
Last update: 30.11.2017
Checksum(SHA256):
a9b81fdc18b96b8b728714373579573e80e399cf1802fe7fe0e2b2ddd8657e5e
Security aspect to consider
The use of script as is, there are potential dangers on how the system can still be compromised. Only thing that you don't have to worry about is SQL injection since no database was used. Everything else still applies but the most straightforward attack, that doesn't include social engineering, here is eavesdroping on an unecrypted traffic to steal either login credentials or session id. Another obvious but less popular choice is brute-forcing the password online. So to tighten up things a bit, here are things to consider:
Access restriction
One thing you can do and should do is to restrict file access using .htaccess. The files in this case are admin.php and logout.php. Restricting it to personal phone or home IP address should be the obvious choice but not always satisfying. Restricting it to local coffee shop network that has free wifi for its customers would enable anyone connected to it access these files. Though, still better than global access.
Implement TLS/SSL encryption
Someone listening on unencrypted HTTP traffic, especially in case of coffee shop free wifi network, could get the login credentials or session id in plain text and use it to gain unauthorized access to admin system. A solution is to use secure socket layers (SSL) that would guarantee that all the traffic between server and user is encrypted.
Make Dictionary attacks and Brute-forcing costly
One way to defend against such attacks is to make sure your username and password are long and unique and cannot be found in dictionary lists. Another is to increase the iteration rounds used in hashing methods to make computing time costly. But the best way is to use both.