Codeminer42 Hackathon: a lesson on experimentation

On November 23rd, Codeminer42 organized its first Hackathon. The goal was quite simple: to encourage the experimentation of new technologies in problems that are a little beyond the ordinary.

In this post, I will discuss how the event went, the proposed challenge, and the technologies used, helping us better understand the overall takeaway from the experience.

Requirements

The most basic requirement involves a developing a CRUD for vaults. The CRUD has an additional feature, which is the possibility of adding tags to each vault – useful for users in organizing and searching for vaults.

I will be using the term vault as the entity that the application deals with. The most generic vault has the following structure:

vault (id, name, username, password, tags)

The application itself is a password manager. Security is a crucial point. It must be able to securely encrypt and decrypt passwords. In addition, it must be able to generate TOTP codes.

Participants

A total of 20 participants were divided into groups of two, resulting in 10 pairs. The challenge was to create a password manager while limiting the use of specific technologies, which included:

Backend
- Python
- Rust
- Go
Frontend
- Svelte
- Flutter Web

For the front end, everyone chose Svelte, while for the back end, there was a greater variety of choices. The distribution is shown below.

Many teams preferred Python due to its ease of use and its similarity to Ruby, which was the most popular programming language among the participants. The decision to use Go was based on the team’s prior experience with the language, while two-thirds of those who chose Rust did so out of curiosity.

Organization of the pairs

Most of the pairs followed the standard organization. One member was responsible for the front end and the other for the back end. One pair, however, chose to alternate tasks as a multidisciplinary team in a software project; dealing with the next task to be done regardless of the technology.

Approaches

As one of the participants, I found the challenge very interesting. It took us to a place beyond the ordinary. It’s not common for us to work with cryptography in our daily jobs. We usually use frameworks that already solved this problem for us. Still, having these concepts in your toolbox makes you more complete.

Most pairs used the standard approach of letting the backend handle the encryption using salts and hashes in the vaults. In pseudocode it would be something like this:

salt = get_random_salt()
encrypted_password = encrypt(SOME_SYMETRIC_KEY, password_plain_text + salt)

vault = {
password: encrypted_password,
salt: salt
}

Let’s say you have a password 123456 and a salt abc. The encrypted password would be encrypt(123456abc). The salt is generated randomly and stored in the database.

Zero-Knowledge Encryption

A minority has opted for a more secure approach, although more complex to implement. The Zero-Knowledge Encryption approach is more secure because the back end can’t decrypt vaults without the front end.

The back end only stores the encrypted passwords and the front end is responsible for decrypting the passwords.

This process is complex enough to deserve its post. But here is a summary of how it works:

The front end generates a symmetric key from the user’s password
- this key itself has a random salt
This symmetric key is then used to encrypt the sensitive contents of the vault

Thus, each vault has a unique symmetric key and the backend does not have access to it. Only the front end can decrypt the passwords since the user’s password (aka master password) is necessary to generate the symmetric key. Below is an illustration of the process:

Please note that the process in the frontend is similar to that in the backend, but it involves generating a unique symmetric key for each vault.

This means that the user’s password cannot be accessed in the backend under any circumstances, and it cannot be recovered.

During registration, the frontend salts and hashes the password before sending it to the server. The server then receives this hash, hashes it again, and stores the result in the database.

"Regrets" and Results

All the teams that attempted to implement the Zero-Knowledge Encryption approach were unable to complete their work on time. The application did not meet the minimum requirements. Additionally, those who attempted to experiment with Rust faced a longer adaptation period and could not finish within the deadline.

As a participant who attempted to implement Zero-Knowledge encryption, I can confidently say that I flew too close to the sun…

The Podium

The top 3 pairs were:

SecureMiner using Python and Svelte 🥇 (see the winner’s journey)
42Passwords using Go and Svelte 🥈
Open Sesame using Python and Svelte 🥉

Each member of the winning pair won a Macbook Air M2 13". The second-place pair won an Echo Show 8.

A Note on Usefulness

"Give him a coin because he needs to profit from what he learns"

This is what Euclid said when one of his students asked what they would gain from learning his teachings.

After all, apart from the top two performers, what did the others gain from all of this? Why should one learn Zero-Knowledge Encryption? Why learn Rust? Why learn Go? Especially if next week you’ll be using a framework that already solves these problems for you?

The answer is simple: NOTHING. Most participants engaged in this for the sheer purpose of learning something new. They value knowledge as an end in itself, not merely as a means to an end. The true benefit lies in the knowledge gained.

This does not mean that it will never be helpful to you. The connections between events can only be made in hindsight. However, this understanding can certainly be valuable in the future.

The significance of this nothing is what contributes to your growth. Science operates in a similar way. When Maxwell discovered his equations, he had no idea that they would later prove essential for wireless communication, for instance.

This nothing is about experimenting. Whether it’s a new concept, a new technology, or something else entirely.

Especially if you can’t see its immediate usefulness, just write some code and discard it. That’s perfectly fine.

Conclusion

It was a great experience and everyone truly learned something new, which made it worthwhile. From the company’s perspective, it was an excellent way to foster experimentation and curiosity. Even the most curious people have difficulty organizing themselves to try new things. An event like this is a great way to do that.

I hope to see another exciting challenge in the next edition and, ideally, more people interested in participating.