Designing Inline Login Systems

Introduction

This article talks about key design and login systems for applications. I will be going into a smaller depth about how login systems are made, why they are made the way they are and what makes it easier for management. This article will be super short or shorter than usual but it will make for a nice little quick post.

What is a internal and external login system

Well the term internal and external login systems are quite obvious one is embedded into the application and one is embedded outside of the application. An internal login system is a type of login system that is embedded directly into the source code of the program which means the system key and other forms of data are not directly set by a server. A external login system is a login system that exists outside but inside of the application at the same time. This type of login system is hosted on a web server where the application may make a HTTP(s) request to a server with a given query to check if that user is logged in or is a valid user and has a valid licenses. Before we can distinguish the different types of login systems how about we first get into how a login system really works?

Login systems work in multiple ways and have many different designs and forms of authentication. Some login systems may use giant long strings or encoded lines of text separated with pads such as = or $ and even @ while others might be direct username and password authentication. Well authentication systems go much deeper than this, some may use servers to authenticate or have software keys and licenses directly embedded into their code. But how exactly is this determined and what is so bad about having a internal login system? The basics of a login system is to just authenticate a user we know that but what about software keys? Well software keys are a major part of license based software so there must be time and date systems to where and when this key expires. Well here are the two type of design layouts for license based software and why one is more used over the other.

• Internal Date based: Internal login systems are mostly used for smaller programs, programs that do not have thousands of users or buyers. This is because every time the user buys a new key they must re buy a new system set by a server. For example say you have a text editor that has a 30 day license from the day the person buys it till those 30 days are up. Well given this is an internal login system the developers will need to create a system to calculate the days and extension date then build a template and compile the file with the generated inline license with a login system that verifies this data. There are a few reasons why this is not used.

→ 1: It can at times become tedious when a program gets larger and more popular. As the program grows so will customer usage and a system constantly being able to manage all that will be super tedious.

→ 2: It can sometimes lead to certain vulnerabilities if it is not implemented correctly. Unlike a web server if someone was to reverse engineer the data of the code and able to locate and exploit the login system this means they could extend the date of the key. Given a date in a internal login system is stored and possibly formatted in certain cases then it can be abused and bypassed.

• External Data based: External login systems are a thousand times safer and more manageable to both big and small programs. If you have a application that requires authentication you can tell the program to make a request to the server and test for authentication on the server. This makes it easier and more manageable because there is no system that needs to generate the data, all it is is just a giant database storing values of a given username, password key and start then end date of that key. All the program has to do is create or load conditional statements which allow the program to verify the data is safe. However this can also lead to systematic bypass if the web server is not built correctly and is not protected well with protection services.

With a simple understanding of how login systems generally work and the difference between internal and external login systems lets dig deeper into how they are exactly designed.

How A login system is designed

Most login systems depend on the design of the over all project. However most general login systems are either key based or password and username based. But where exactly are login systems implemented? To be honest even in applications that may be paid for that you paid money for but do not have a license may also use login systems to API’s the application itself may use. For example say you are developing a cloud application that needs to interact with PayPal’s API. That API key you get from PayPal as a developers license or key may need to be authenticated by your app by PayPal in order for your app to process information from PayPal. This means the user that uses your app may not require to login but the application itself will have to. In a sense and smaller world login systems are implemented everywhere even in applications that are free. However in terms of external and internal login systems most of them have the general base. Seen below is a list of core items to a login system that may be implemented.

• Date and time management system: In almost all use cases a license to an application will expire. But how exactly do applications know when and how to cancel a key? Well this depends for the variation of login system. In a case of external login systems there may be a key system in place to help the application find values on the key stored in a json response. For example the below code is JSON code that is a concept or example of what would be sent back from a request made to the server as authorization from a application that uses an external login system.

{
    "ServerKey:dfhgdsfhgQEHJGWEUYGFUWYFGYUEGFUYGF": [
        "User": "Username",
        "Email": "Email.com",
        "Start": "12/2/2022",
        "End": "12/2/2023"
    ]
}

→ This data eventually will be parsed by the application and determine the end dates. Additional features on these applications may have warning indicators in the JSON data or in the application to whether or not the key is close or far from expiring. Ideally this is the type of system you want to make ( more secure ofc ) in a more professional and corperate environment because it makes managing data so much more better on the consumer and on the developers end. In terms of external applications this is where things get wacky. Some people will just manually fill the application with static data and just have a conditional to check the systems HW clock and compare it in a simple conditional to whether or not the key is invalid. Now in other more extreme cases they may implement a system like the below program to get the difference in dates and days between the licenses start and end date to determine when its bad.

// C++ program two find number of
// days between two given dates
//https://www.geeksforgeeks.org/find-number-of-days-between-two-given-dates/
#include <iostream>
using namespace std;
 
// A date has day 'd', month 'm' and year 'y'
struct Date {
    int d, m, y;
};
 
// To store number of days in
// all months from January to Dec.
const int monthDays[12]
    = { 31, 28, 31, 30, 31, 30,
       31, 31, 30, 31, 30, 31 };
 
// This function counts number of
// leap years before the given date
int countLeapYears(Date d)
{
    int years = d.y;
 
    // Check if the current year needs to be
    //  considered for the count of leap years
    // or not
    if (d.m <= 2)
        years--;
 
    // An year is a leap year if it
    // is a multiple of 4,
    // multiple of 400 and not a
     // multiple of 100.
    return years / 4
           - years / 100
           + years / 400;
}
 
// This function returns number of
// days between two given dates
int getDifference(Date dt1, Date dt2)
{
    // COUNT TOTAL NUMBER OF DAYS
    // BEFORE FIRST DATE 'dt1'
 
    // initialize count using years and day
    long int n1 = dt1.y * 365 + dt1.d;
 
    // Add days for months in given date
    for (int i = 0; i < dt1.m - 1; i++)
        n1 += monthDays[i];
 
    // Since every leap year is of 366 days,
    // Add a day for every leap year
    n1 += countLeapYears(dt1);
 
    // SIMILARLY, COUNT TOTAL NUMBER OF
    // DAYS BEFORE 'dt2'
 
    long int n2 = dt2.y * 365 + dt2.d;
    for (int i = 0; i < dt2.m - 1; i++)
        n2 += monthDays[i];
    n2 += countLeapYears(dt2);
 
    // return difference between two counts
    return (n2 - n1);
}
 
// Driver code
int main()
{
    Date dt1 = { 14, 5, 2022 };
    Date dt2 = { 18, 5, 2022 };
 
    // Function call
    cout << "Difference between two dates is "
         << getDifference(dt1, dt2);
 
    return 0;
}

In a larger more complex example the developers would add conditionals to first verify the key then check if the key is directly equal to the time. If the system date which in an example would be dt1 is greater than or over the limit of variable dt2 the devs will tell the application to quit and warn the user of an invalid key and license. These systems are much more complex and tedious to manage while also posing some security risk if you do not implement them correctly for more lower end but less popular programs.

• Logging system data: Some applications such as exploits and even general private applications may log system information such as your CPU(ID) to ensure you are not using the same program over and over and over on different computers with the same key. This also ensures that you are not scamming or mining the same exact application over and over and over for keys where instead of selling enterprise licenses someone will buy one license that is say a year long for one person but use it amongst many computers and avoid paying thousands of dollars for an enterprise license kit. This not only helps protecting the login system of the application but the application itself. In some more advanced scenarios such as games, games can attempt to hardware ban you for trying to bypass login systems external or internal which will result in your license becoming voided and no matter how hard you try even with a new license that application will not work on that computer because of the HWID ban ( Hardware Identification Ban ).
• Authentication Types: Different applications have different authentication types and forms. Every variable matters in this design whether your application is offline or online, connects to servers or not, uses tor or not etc. Authentication types are the prime part of a login system as they make a login system well- a login system. You can not develop a login system without it. Authentication comes in many forms such as Text encoding, Text hashing, Text manipulation, Cipher text, Text Encryption, Key algorithms, Key sequences and what not. For the most part if you are not connecting to a server and have a internal login system most likely the part of authentication form is up to you however if it connects to a server you would have to understand how that server or database may handle certain data strings or data sections of a key such as ‘, /,, <> etc. from then on. Some keys and even algorithms use Unicode so understanding and being able to predict the length of each key would be hard without creating some sort of overflow.
• Security: A major part of login systems is the cyber security implementation that may go into a log in system. If you are developing external or internal cyber security is a must for login systems. Even if you do not see your average joe reverse engineering your program there are still glitches, bugs or sometimes security flaws someone may come across that even with 0 hacking knowledge could still take advantage of. After all most login systems are just a bunch of heavily backed conditional statements. A great example of this is key files! Some applications require you to load a key file such as keyname.txt or keyname.auth or keyname.encrypted into an application where the application will decode/decipher/decrypt/unlock/reverse whatever data is in that file. Something people often miss with authentication systems and key files is that if that program is loaded incorrectly and the file integrity such as its magic bytes ( The first few bytes of a file such as an image, text file, source file etc that may define its type and validate its file extension ) and if the file is real or not is not implemented people can inject or load files designed to crash the program. So there are many security checks that may be required as far as user input, user output, file input, file checking, system checking, process checking and much more along those lines.

As you can see there is alot that may go into a login system especially if it external but which one is worse and which one is best?

The pros and cons of both types

Since we already are finishing up this article lets sum up with the pros and the cons of both types of authentication systems. While both have their use cases lets just go through and try as hard as we can to solve the question of which one is safer ( 3 reasons each ) .

• Pros of a external system

→ 1: They are easy to create and alot more reliable and work offline meaning the user may not need to wait 40 minutes for a server to respond and the app to decode data just to login.

→ 2: They are much more practical for smaller projects and start up examples especially if you need a very fast and performant application

→ 3: They are much more reliable in terms of how much control you can have over the vulnerabilities that may exist within the login systems checking and validation

• Cons of a external system

-> 1: They can sometimes be very confusing and tedious to create. This can pose a negative affect on bug changes that may happen, bug fixes that may happen or any patches that may happen within that program no matter how big or small your clientele is. If you have 10 clients that means if there is 1 vulnerability that you find, patch and release you will now need to recompile back down every single application and tell clients to re use data.

→ 2: They can cause much more panic and havoc amongst a user who does not understand what is going on if a dev error pops up. When developing a login system you also want your clients to be happy. The issue with this is if the login system is not developed well and has alot of bugs there is a high chance it is more than likely harder to patch and fix than a web server would be.

→ 3: They can lead to more confusing development times. This happens mostly when you start using custom key algorithms and 30 days later you may sit back down and not understand what is wrong with your login system especially if it uses a custom key algorithm. This falls under implementation.

• Pros of an internal system

→ 1: Internal systems are much more practical for larger projects because they are easier to setup an automated system to both patch and download updates. Instead of the individual having to go back to the website or the devs having to release a version of it on their website the server can auto download it and have a system that will auto update the login system if there is a bug or vulnerability or even bug.

→ 2: Bugs are more than likely server based rather than application based. Given the server will do all the work to query, structure, output and spit back data most bugs in the authentication system will be due to the server acting up in its response which is totally fixable quickly without having clients remake and having to re install the application.

→ 3: Systems are much easier to manage in terms of payments, key systems, algorithms etc. This may also make it faster on the developers end if an issue comes to the surface.

• Cons of an internal system

→ 1: They can become super slow in terms of response time: If your server is not setup correctly there is a high chance that login system may fail to connect to the server or the server may fail to send a appropriate response. In the end clientele will be most likely mad that the server is taking 10 minutes or even 5 to respond.

→ 2: They can purpose much more complex vulnerabilities which will allow a user or hacker to bypass them. If the system and server is not safely implementing or querying data then this means the vulnerability will most likely be due to the server which finally in turn means the hacker will be able to bypass the security system.

→ 3: Internal systems are more susceptible to crashes in the program. If the server sends back a un wanted response or a response from the output of the backend scripts that may be of a certain length that the end program does not like this may cause the application to seg fault which also means the application is now vulnerable and probably exploitable.

Wow okay that was a short list, so what is the answer? Well the truth being told both have their bad side and both have their good side but it mainly depends on your project and complexity of the login system. Anyone can develop an application then a login system for it but the base of the project determines not only how safe but also how performant, well written and sometimes even “smart” the login system is in terms of data encryption and manipulation.

Conclusion

Authentication systems can be sometimes tedious and most times worrying to develop. If you are developing a login system it most likely means you are selling your program. Which means that authentication system must be built to perfection because if not people will abuse your application and crack it faster than your mom cracked that belt. So the end goal really being -> Please ensure your login systems are secure and you choose the right methods. If it is a web server that you are using to authenticate ensure you know what you are doing before just developing a random authentication system.

~ Totally_Not_A_Haxxer out!

If you like and enjoy more content like this don't forget to shoot me a follow or check my Instagram page! The support goes a long way

Development organization

Scare-Security

Development page

ArkAngeL43 — Overview

Instagram page

https://www.instagram.com/Totally_Not_A_Haxxer

Cash APP

Pay me on Cash App

Venmo

Venmo | Totally Not A Haxxer hacker