Forem: Luis Bastidas

Hackers don't have to be too smart unless you use this

Luis Bastidas — Tue, 03 Mar 2026 23:24:08 +0000

I wanted to share a cool and easy system to make your applications safer.

This tutorial is focused on WebSocket-like systems, but you can apply the same concept elsewhere. The idea is universal.

The Main Issue

If you have a WebSocket server, you've probably asked yourself:

How does the server know if a client is from your application and not some wacky person who just spun up a WebSocket client at 3 am and is now knocking on your door? (knock knock, twin)

Good news: there are several ways to handle this. Let me introduce nonce signature verification.

The Solution

You define a secret key that only your application and your server know. Think of it as a shared password that never actually travels through the wire.

Secret key: XDDCC

When a client connects to the server, the server generates and sends a nonce, which is a random blob of bytes that's only valid once (hence the name).

Nonce: emEdkZ

The client must then sign the nonce using the secret key via HMAC-SHA256:

Key	Nonce	Signature
XDDC	emEdkZ	`89sWB9akORcl41J0Xh6jNFvawiA8io2s64Cc0NYn1Rs=`
hello world	emEdkZ	`Mgv5AF+1EdyU2OfzDfyF+63lyWPxdy8iBPNVbGiYJ6U=`
XDDC	Supa secret nonce	`L/3PcSXooCr6PwmD2exX+xGbMCZB2vyDuKAaMOIxHIc=`
twin ts is tuff	Supa secret nonce	`UHmxTyntKFu6ADo3HwbQ+4QMTzjZJXgNps9O5YxurIk=`

Notice how every change, whether in the key or in the nonce, produces a completely different signature. You can try it yourself here.

The server then verifies that the received signature matches what it would have computed with its own copy of the secret.

When does the server kick someone out?

The client takes too long to respond with the signature (timeout = suspicious).
The signature doesn't match what the server expected.

In those cases, the server closes the connection. If the client insists on being sketchy, it can escalate with rate limiting or a temporary restriction.

Why not just send the secret key directly?

Because if the key travels over the network, it can be intercepted via a Man-in-the-Middle attack. Someone sitting between your client and server could just read it.

By the way twin, this does not replace TLS. Always use WSS in production.

With nonce-based signing, the secret never leaves the application. Only the derived signature does — and without the original key, that signature is useless to an attacker.

Vulnerabilities

The secret key isn't secret (Wth twin?)

If you implement this in a public application or a video game client, a determined person could extract the secret key from your files. Reverse engineering tools exist and people will use them.

Fixes

Don't hardcode the secret key in plain text.
Cipher and obfuscate your application's binaries and assets.

Brute Force Attacks

An attacker could intercept a valid signature produced by your application and try every possible key combination until they find one that reproduces it. Of course this is almost impossible, but it's not impossible.

Fix

Rotate the secret key weekly or monthly. This limits how long a cracked key remains useful, turning a catastrophic breach into a minor inconvenience.

Summary: Never transmit your secret. Have the server challenge clients with a random nonce, verify the HMAC signature, and rotate keys regularly. It's simple, battle-tested, and keeps the riffraff out.

Now this is how you create video games

Luis Bastidas — Mon, 16 Feb 2026 19:35:24 +0000

I started creating an educational video game about numeric sets with Godot Engine.

The idea is this: the more specific the set you place the number in, the more points you get.

Adding some references

I wanted to show memes when the player placed special numbers such as 67, 69, or 87, which have certain meanings in this cultural context.

7: The most likely number to appear when you roll two dice and sum their results.
67: Viral absurd meme.
87: Five Nights at Freddy's lore key date (1987).
Many more.

The problem? I was doing it manually. It was something like this:

Convert the video into separate frames.
Copy the frames into the project folder.
Put all the frames inside an animation named after the special number.
Optionally put the audio of the meme in another folder and the file must be named after the special number.

So as you can see, this workflow was inefficient, especially because I had to repeat myself a lot and programming is about avoiding these bottlenecks. But even worse, all the animations were inside a single SpriteFrames resource which severely affects performance.

Solution

Fixing the workflow

Instead of having frames and audio in different folders, I made a special folder in the project where all the subfolders must follow a specific schema:

/multimedia/special_numbers_animations/
└─ <animation_name>
   ├─ frames (optional folder)
   ├─ audio.ogg (optional)
   ├─ image.{png, jpg} (mandatory if there is no frames folder)
   └─ meta.json - I save the URL sources of the content here.

Now instead of having to specify the special number every time, the special number itself determines which animation will play.

const SPECIAL_NUMBERS : Dictionary = {

    308: { # Breaking Bad Reference
        "folder": "waltuh", # This is the <animation_name> folder of the code above.
        "volume_db": 0.0,
        "message": "waltuh" # This is the message which display the green label you can see in the GIFs
    },

    69: {
        "folder":"ts_you",
        "message": "you freak..."
    },

    64: {
        "folder": "homer64",
        "message": "PEAK!",
        "fps":30.0,
        "duration": 187.0 / 30.0
    },

    67: {
        "folder": "six_seven",
        "message": "ABSOLUTE\nSIX-SEVEN! +{score}"
    },

    57: {
        "folder": "peruan_caine",
        "volume_db": -10.0,
        "fps": 6.0,
        "message": "AMAZING! +{score}"
    },

    7: {
        "folder":"miners",
        "message": "gambling, gambling\ngambling, gambling"
    },

    6: {
        "folder":"gta_vi",
        "message": "son...",
    }
}

Performance optimization

As we have all the animations in different folders, the code only loads the animations that will be played when the number is placed.

if valid_set:

    var _reward = SpecialNumbers.get_reward(number, depth)

    feedback_label.set_color("#00ad00")
    feedback_label.prompt(_reward.text)

    if _reward.is_special:
        special_anims.show_animation(number)

    score += _reward.score

However, loading and releasing animation data every single time can be counterproductive if we want high performance, so I implemented a cache system.

func _load(number):
    var _cached = _loaded_animations.get(number)

    if _cached != null:
        return _cached

    # (A lot of code loading the animation like frames, image and audio here).

    var _loaded = LoadedAnimation.new()

    _loaded.image = _image
    _loaded.frames = _frames
    _loaded.audio = _audio
    _loaded.number_info = _special_number_data
    _loaded.audio_player = _audio_player

    _loaded_animations[number] = _loaded
    return _loaded

Now we have a scalable and easy memes system!

This is an important concept to understand. I used to think you just make the game, but it’s not like that at all. At least if you don’t want your code to become Undertale’s cousin. Before creating the game, you must build workflows that optimize creation itself, so you can modify anything in the future with minimal effort.

Just remeber

If adding content hurts, your pipeline is wrong.