Introduction

This article is dedicated to confidentiality, one of the three pillars of cybersecurity: confidentiality, integrity, availability. Let’s dig right in, into the best practices of creating a secure application.

Use a key-derivation-function like Argon2id

Hashing a password with Sha256 is not recommended, because Sha256 is fast and can be parallelized with GPUs. Because of this, an attacker’s most likely angle of attack on your system would be to bruteforce the user’s password with a tool like Jack-the-Ripper to crack the user’s password.

This problem gets worse, because of the user’s tendency to share passwords across apps: If just any of these use a key-derivation-function that is ‘too fast’ that is the most likely app to get attacked.

Key Derivation Functions like Argon2id are designed to be slow and resistant to parallelization. An attacker now has to slowly and grindily try to bruteforce your passwords. According to this test, it would take roughly 0.04$ to break a 4-digit-password that is encrypted with just one round of Sha256, but roughly 486.5 million USD to break the same password derived with Argon2id.

That is the power of key-derivation-functions: They make your password resistant to offline cracking attacks, in case an attacker got hold of the database somehow.

Use OAuth2 for delegating access scopes

OAuth2 is a privilege delegation framework. Not only is it a good practice to secure your own applications using OAuth2, but also, it allows an application to exchange security scopes with other applications. This is particularly useful in distributed systems.

It works like this: The user exchanges his ID and password on a secure source for an access-token. An Access-Token has a life-time, a string that represents the actual token, and an amount of scopes. Scopes are privileged granted to the bearer of an Access-Token.

In case an attacker steals an Access-Token, he will have limited-time access to your API. But he will not have the password, which is good.

This way, a user can grant limited access to a 3rd-party-API. That is the classic ‘OAuth2 consent screen’ you see when you can log in with Google somewhere and the app requests things like ‘read my public email address’ and ‘get my profile image’.

In the background the 3rd-party-app opens up a specific OAuth2-page from Google. For that, the 3rd-party-developer has to register at Google and provide a redirect API after the user has logged in. This will prompt the google page to open the redirect page with the Access-Token with the limited scopes, so that the token can be transferred to the 3rd-party-App.

The 3rd-part-app now has limited time and access to access the API of Google on behalf of the user.

Use ChaCha20 for symmetric encryption

ChaCha20 is faster on AES-256 on devices without AES-specific acceleration. AES256 comes with several problems; It can be configured in different modes such as ECB, CBC or GCM. None of these modes are particularly good. AES-256 with ECB encrypts the same plaintext as always the same output, which causes ‘encrypted’ data to leak entropy. AES-256 with CBC mode is vulnerable to an observer who is able to observe multiple encryption results for plaintexts he chooses. AES-256 with GCM, which is considered the best mode, is vulnerable to reusing initialization vectors. Thus, too much can go wrong when configuring AES-256 and it is advised to use a more dummy-proof symmetric encryption algorithm like ChaCha20.

ChaCha20 is a modern and fast encryption that takes in a 96-bit-nonce, a 192-bit-password and produces a pseudo-random cryptographically secure number-stream, which can then be used as pseudo-One-Time-Pad-Input, that is: You just XOR the plaintext with the resulting cipherstream.

In this article we deep-dive into the implementation details of ChaCha20.

Use a secure random stream

Various encryption and decryption techniques need an entropy-source. The best entropy sources contain unpredictable real-world information. There is the popular case of Cloudflare: They use lavalamps as entropy-source. A particularly strong random-number generator would be based on physical measurable chaotic systems, like Chua’s circuit.

Timestamp messages and sign them with Falcon

In this article we explored different quantum resistant signatures and selected Falcon as the best option. Unlike hash-based alternatives, Falcon maintains small signature sizes and rapid verification, making it ideal for constrained environments. The problem isn’t just signing messages securely today—it’s ensuring they remain valid in a post-quantum world.