Aarav Hattangadi

The Enigma Machine’s Ingenious Encryption

2023-08-19T00:00:00+00:00

During the Second World War, once the Germans started using wireless communication systems, the need for encryption emerged. The encryption technique of choice for Nazi Germany was the Enigma Machine — one believed to be uncrackable. Quite ironically, the Enigma machine, one of the hardest ciphers to crack was based upon the weakest cipher, the Caesar cipher.

Understanding the machine

While there were many versions of the Enigma machine, I’ll be focusing on the first few — all the others just expanded upon their concepts while the core remained the same. The machine was made up of 5 main components: a keyboard, plugboard, 3 interchangeable rotors, a reflector, and a lamp board.

When a key was pressed on the keyboard, an electric signal passed through the plugboard, through the 3 rotors, through the reflector, back through the 3 rotors, plugboard, and finally the enciphered letter would illuminate on the lapboard.

The plugboard allowed up to 10 pairs of letters to be swapped with one another. Swapping an A –> K for example, would lead to all ‘K’s being made into ‘A’s (before and after encryption) for example.

Each machine had 3/more rotors, each having a distinct wiring configuration - which could be interchanged in the 3 rotor slots. Each rotor spun at different intervals. The third rotor spinning on each keypress, the second after 26 rotations of the third rotor, and the first spinning every 26 rotations of the second rotor ( = 26*26 = 676 rotations). Each rotor had a turnover notch on which the next rotor would be turned. This meant that a letter would always be encrypted into a different letter, never repeated, and never itself. Older models included only 1 turnover notch, but with the introduction of newer models, rotors VI, VII, and VIII had two turnover notches.

The rotors also had offsets, which would change their starting positions. If the starting position of a rotor was a B, the letter A would get encoded as a B, and then passed on as a B to the next rotor.

While the wiring of the rotors couldn’t be changed, you could change the order of the rotors and their starting positions. Those settings were changed each day during the war, generating an enormous number of possible encryption paths for a letter.

Here’s an example of how the signal would pass through the rotors:

Once the signals passed through all the three rotors, it would be passed into a reflector. A reflector is quite similar to the rotor, however, it wouldn’t rotate or change position—it had a fixed position which couldn’t be changed. However, there were 3 reflectors - A, B, and C. Once the reflector encoded the letter, the signal would be again passed through the rotors, this time in the backwards direction.

This new signal was passed through the plugboard and the letter would be swapped once again, and then finally, the letter would be illuminated on the plugboard.

While the core principles of Enigma weren’t so complicated, the sheer number of possibilities, settings, and randomness led to it being considered an unbreakable device for a long time.

My Ad-blocking adventure with NextDNS

2023-06-25T00:00:00+00:00

A few months ago, I was on the lookout for a customizable DNS server, which would let me block ads, monitor traffic, and redirect custom domains to local IP addresses; akin to that of a PiHole, but without needing to run a DNS server 24x7.

On my search, I stumbled upon NextDNS, which is a DNS service that lets you do all of the above, and more. It has a very generous free tier (300k requests p/m¹ ²), offering both DNS and DoH (DNS-over-HTTPS). I’ve been using it for a few months now, and I’m very happy with it.

The setup process was a breeze—I just had to create an account, and create a profile with my required settings. Afterwhich, I just had to configure my devices to use the NextDNS servers, and I was good to go.

Ad-blocking works fine as well, and I haven’t noticed any issues with it. You can mix-and-match various blocklists, I’ve found AdGuard’s ones to be the best. They can also block trackers, and affiliate links if you wish. Custom blocklists/allowlists are also supported, but I haven’t tried them out yet. I’ve also set up a few custom rules to redirect some domains to local IP addresses, and that works fine as well.

The logging features are good, and you can choose where you’d like to have the logs stored (US/UK/EU/Switzerland) and for how long (1 hour -> 2 days). You can choose what to log as well, which seems like a plus point to me.

The speed is decent as well, and I haven’t noticed any issues with it. A bulldozher test shows that’s its faster than Cloudflare’s, and marginally slower (+- 1ms) than Google’s.

█ Cloudflare DNS
  1.1.1.1
   22.1 ms  32.6 ms 809.4 ms
  ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▆▆▆▆▆▆█████████████████

█ Quad9 DNS
  9.9.9.9
  272.4 ms 288.8 ms 293.5 ms
  ██████████████████████████████████████████████████

█ Google DNS
  8.8.8.8
    4.6 ms 380.0 ms 389.5 ms
       ▁▁▁▁▁▁▁▁▁▁▁▃▃▃▃▃▃████████████████████████████

█ Verisign DNS
  64.6.64.6
   60.6 ms  64.0 ms 197.0 ms
  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇███████████████████████

█ 45.90.28.60 DNS
  45.90.28.60
    5.0 ms   5.7 ms 308.5 ms
  ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂▂▂▂▂▂▂▂▂▂▂▃▃▃▃▃▃██████

█ Mozilla DoH
  https://mozilla.cloudflare-dns.com/dns-query
   23.3 ms  24.8 ms 482.6 ms
  ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▅▅▅▅▅▅██████

They also claim to offer malware and phishing protection, but I haven’t gotten around to testing that out yet.

NextDNS Pricing ↩
At the time of writing, once the 300k requests are exhausted, the service will only work as a normal DNS resolver (i.e., no ad-blocking/rewrites/logging/analytics) until the next month. ↩

Implementing JWT authentication in ASP.NET Core

2023-06-04T00:00:00+00:00

In my previous article, I explored the fundamentals of JWT authentication. We delved into the structure of a token, and its benefits. In this post, we will dive deeper into the practical implementation of JWT tokens. We’ll be using ASP.NET Core 7 along with a controller-based API.

Throughout this article, I’ll guide you through the necessary steps to integrate JWT authentication into your ASP.NET Core API. We’ll explore how to generate and validate tokens, store user claims, and implement middle ware for token-based authentication. Additionally, we will highlight some best practices and considerations to ensure the security and integrity of your authentication system.

Note: For the purpose of this post, I’ll be using the project template ASP.NET Core Web API and .NET 7

NuGet Package - JwtBearer

First and foremost, we’ll need to install the JwtBearer package from NuGet to be able to work with JWT tokens. The package Microsoft.AspNetCore.Authentication.JwtBearer fulfills our requirements. You can install this either by using the GUI NuGet package manager in Visual Studio (right click your project in the solution explorer, and click on manage NuGet packages) or by using the NuGet Package Manager Console and entering the following command:

Install-Package Microsoft.AspNetCore.Authentication.JwtBearer

Setting secrets

Though secrets shouldn’t be set in an easy-to-access location, for the purpose simplicity, we’ll be using appsettings.json as an example.

We’ll create a section in our appsettings.json file which will store our secrets: namely, the issuer, audience, and a secret key. These values will be used later on to generate our JWT token.

  "Jwt": {
    "Issuer": "https://example.com/",
    "Audience": "https://example.com/",
    "Key": "A secret key - please don't use this in the production environment"
  }

Specifying authentication settings

In our program.cs file, we’ll use the AddAuthentication method to configure our JWT authentication at runtime. We’ll specify the authentication scheme as JwtBearer.

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
})

Then, we’ll use the AddJwtBearer method to configure the token parameters.

builder.Services.AddAuthentication(options =>
{
    // ...
}).AddJwtBearer(o =>
{
    o.TokenValidationParameters = new TokenValidationParameters
    {
        ValidIssuer = builder.Configuration["Jwt:Issuer"],
        ValidAudience = builder.Configuration["Jwt:Audience"],
        IssuerSigningKey = new SymmetricSecurityKey
        (Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"])),
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = false,
        ValidateIssuerSigningKey = true
    };
});

We set the ValidIssuer, ValidAudience, and IssuerSigningKey properties with the values specified in our appsettings.json. Furthermore, we let our API know that it should only validate the Issuer, Audience, and Signing Key; it shouldn’t validate the time-based validity of the key.

Now, we need to tell the builder to add the authorization service at runtime:

builder.Services.AddAuthorization();

as well as the authentication and authorization middle ware:

app.UseAuthentication();
app.UseAuthorization();

User Model

Now that we’ve set up our project, we need a model for our user credentials. We’ll have a User class with 2 properties: a username, and password. Feel free to modify this class with more properties.

public class User
{
    public string UserName { get; set; }
    public string Password { get; set; }
}

Generating the tokens

To let users generate the tokens, we’ll need an endpoint. This endpoint will take in the credentials from the user and return a token if the credentials are valid.

Create a new controller. I’ve named it JwtController. We’ll add a HTTP Post endpoint to this.

[HttpPost]
public IResult Post([FromBody] User jwtUser)
{
    // ...
}

We take in a object from the body of the request, and map it to the model of User - which we’re calling jwtUser.

Our endpoint checks if the username and password match (though, it’s best practice to store credentials in a database; or you could use ASP.NET Core’s Identity Manager). The issuer, audience, and key are set to those we specified in the appsettings.json file. A new TokenDescriptor is created which will add our claims to the token. The claim Id is a GUID, the subject and email are set to the provided username, and a Jti claim is also set to a GUID. The Jti claim is an id for the JWT which can be used to enhance the security of our token. The expiration of the token is then set to 5 minutes, and the signing algorithm is set to HmacSha512. We then use the JwtSecurityTokenHandler to create the token, and return it along with a HTTP Code of 200.

If the username and password isn’t valid, a HTTP Code of 401 for unauthorized is sent.

    if (user.UserName == "admin" && user.Password == "password")
    {
        var issuer = builder.Configuration["Jwt:Issuer"];
        var audience = builder.Configuration["Jwt:Audience"];
        var key = Encoding.ASCII.GetBytes
        (builder.Configuration["Jwt:Key"]);
        var tokenDescriptor = new SecurityTokenDescriptor
        {
            Subject = new ClaimsIdentity(new[]
            {
                new Claim("Id", Guid.NewGuid().ToString()),
                new Claim(JwtRegisteredClaimNames.Sub, user.UserName),
                new Claim(JwtRegisteredClaimNames.Email, user.UserName),
                new Claim(JwtRegisteredClaimNames.Jti,
                Guid.NewGuid().ToString())
             }),
            Expires = DateTime.UtcNow.AddMinutes(5),
            Issuer = issuer,
            Audience = audience,
            SigningCredentials = new SigningCredentials
            (new SymmetricSecurityKey(key),
            SecurityAlgorithms.HmacSha512Signature)
        };
        var tokenHandler = new JwtSecurityTokenHandler();
        var token = tokenHandler.CreateToken(tokenDescriptor);
        var jwtToken = tokenHandler.WriteToken(token);
        return Results.Ok(jwtToken);
    }
    return Results.Unauthorized();

Making endpoints require authentication

To make controllers require a token for authorization, we need to add a decorator of [Authorize(AuthenticationSchemes = "Bearer")] to the desired controller. If the token is considered valid, the request will pass through, else a 401 response would be returned.

In this article, we covered the key steps involved in implementing JWT authentication in an ASP.NET Core API. We installed the required NuGet package, configured secrets and authentication settings. To allow users to generate tokens, we create an endpoint and added essential claims to the token. We applied the [Authorize] attribute to a controller to make it accessible only to users with valid tokens. We’ve just implemented a part of token-based authentication — security is an ongoing concern, and you should think about implementing additional measures like refresh tokens, and token revocation.

Stay up to date with security best practices to ensure the long-term resilience of your application. Happy coding!

Understanding JWT-Based Authentication

2023-05-30T00:00:00+00:00

Today, we’ll delve into the intricacies of JWT based authentication, a powerful method to secure your applications.

The JWT “Passport”

Think of JWT Tokens like digital passports, similar to those you use while travelling. It consists of 3 essential components: the header, the payload, and the signature.

The header is like the cover of our passport, providing necessary information. It contains metadata about the token, such as the hashing algorithm used and the type of token it represents.

Next, we have the payload, which is the core of our JWT passport. This section carries the actual data, much like the personal information page of your passport. This includes details about the user, such as their name, email, role, or any other relevant information, which are known as claims.

Last but not least, we have the signature, the security seal of our JWT passport. This signature is generated using a secret key known only to the server. It ensures the integrity of the token, just like the anti-counterfeiting measures in your passport that prevent any tampering or forgery.

Authenticating with your token

Now, let’s see how JWT tokens work in practice. When a user logs in to a web application, the server generates a JWT token and sends it to the application.

Once you have your JWT token, you present it with every subsequent request to prove your identity. The server can then verify the authenticity and integrity of the token by validating the signature using the secret key and verifying that the necessary claim requirements are met (think: user role). If everything checks out, you’re granted access to the requested resources.

Stateless tokens

One of the benefits of JWT authentication is statelessness. Unlike traditional session-based authentication, where the server needs to keep track of session data, JWT tokens are self-contained. They carry all the necessary information within themselves, making the authentication process lightweight and scalable.

The server can focus on processing requests efficiently. This also allows for easy horizontal scaling, as any server in a cluster can handle a request without relying on shared session data.

Practical Example

To experience JWT authentication in action, you can check out the JWT generator at jwt.io. This tool allows you to create JWT tokens by specifying the header, payload, and secret key. It also provides a simple way to decode and verify tokens, giving you a hands-on understanding of how JWT works.

A token looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiZW1haWwiOiJqb2huQGRyaWZ0bmV0d29ya3MubmV0IiwiaWF0IjoxNTE2MjM5MDIyfQ.eSxXOKmuJVnan8fM2fvj65Dq5SjtI-kx_qXDzdshDc4

In this token, the . is used as a separator between the different parts. Let’s break down the token into its components and explore their significance:

Header: The first part of the token is the header. When decoded, it results in the following JSON output:

{
  "alg": "HS256",
  "typ": "JWT"
}

The header provides essential metadata about the token. In this example, the alg (algorithm) indicates that the HS256 algorithm was used to hash the token, and the typ (type) indicates that this is a JWT token.

Payload: The second part of the token is the payload. When decoded, it results in the following JSON output:

{
  "sub": "1234567890",
  "name": "John Doe",
  "email": "john@driftnetworks.net",
  "iat": 1516239022
}

The payload contains the actual data about the user who is requesting the resource. In this example, the payload includes the following information:

sub (subject): It refers to the subject whom the token represents, identified by the value 1234567890.
name: It specifies the name of the requesting user as “John Doe”.
email: It provides the email address of the user as “john@driftnetworks.net”.
iat (issued at): It indicates the time at which the token was issued, represented as the number of seconds since the UNIX epoch (January 1, 1970, 00:00:00 UTC). In this case, the value is 1516239022.

The payload can contain additional claims based on the specific requirements of your application, such as user roles, permissions, or any custom data you need to associate with the token.

While this is an example of a generic JWT token, they may also include other parameters, like expiry times (exp), audience (aud), issuer (iss), and many others, which provide further control.