DEV Community: Gál Péter

Encryption without passwords

Gál Péter — Sun, 11 Jul 2021 14:16:30 +0000

In modern encryption, you need a key/password/secret to be able to securely encrypt/decrypt data. This is the idea behind symmetric encryption. In this article, I'm going to drive you through how is the security provided without ever needing to remember a password.

How can we encrypt something in the first place?

There are lots of ways to encrypt something. When it comes to storing your information on a Safe, we are using an asymmetric encryption method, called AES-256 (Advanced Encryption Standard).

When we create a new safe, we generate a new secret key with them. This will be then used to encrypt all of our data in that particular safe. We are using a 128-character long hex string as our secret (512 bits), which is much more secure, than any password that we could remember.

Then this encryption key is stored in the device's secure storage.

Here is how this works out in code:

// Generating a new secret
const secret = generateSecret();

// Storing it in the device's secure storage
await SecureStorage.store(secret);

// This is the data, that we want to store
const user = {
    platform: "dev.to",
    email: "john@doe.com",
    password: "secret123",
};

// Then we encrypt the data
const encrypted = AES.encrypt(JSON.stringify(user), secret);

// Sending the user to the database
// The safe is an object, where we want to store the item inside
await API.item.create(safe, encrypted);

// And finally, on a remote device, when we want to access the data, we use the secret to decrypt
const decrypted = AES.decrypt(encrypted, secret);

// It would print the original user object ({ platform: "dev.to", username.... })
console.log(decrypted);

Note: this is just a presentation of how things work... you should just consider it as a pseudo-code, instead of an actual working example

How can we transfer this key from one device to another safely?

This is a tricky one. If we would just send the encryption key through our database unencrypted, it would mean that there is no point of encryption as we would store the secret key next to the encrypted data. It would mean that you can just use that key to decrypt the data that is stored in the database.

Instead, we use an asymmetric encryption method, called RSA-2048. When you generate a new RSA key, then it is generating a keypair. A public one and a private one.

The public one can be only used to encrypt data. It can be safely shared on the network, as it provides no way for a potential attacker to retrieve data from the hash, as it is not eligible for that.

The private one will stay on the original device without ever sharing it with another device. Then when we get data from the server, we can use this key to decrypt the hash, that we received.

Let's see, how does it work out in practice:

When a device is added to the network, we generate this key pair and send the public key to the database. It will be stored in the future.
We create a new safe on one of our devices and generate a secret, that is stored locally.
We query all of our devices from the database with their RSA public keys.
Then we encrypt the secret, that we generated at the #2 step with this key.
Then we add an entry called KeyExchange, which contains information about which device and safe is the key meant for and the encrypted secret.
Finally when we refresh our data on another device, we query all of our key exchanges and decrypt them with our private RSA key.
After the device received the encryption key, we can safely delete the key from our database as it will be no longer needed.

How can I log in from another device?

Compared to ordinary systems, when we log in, we also exchange a lot of data between the Authenticator and the Authenticated device.

Authenticator: The device, that is already logged in.
Authenticated: The device, that we want to log in, but is not yet authenticated.

The Authenticated device generates an RSA key pair and sends a signal to the remote server to start the authentication process with the public key.
The remote server then generate an authentication id (e.g.: ckqz9n52r000001la810jfjee) and a secret (e.g.: 11879182178653d376fc6b129d1d315b).
Then the server stores the id with the bcrypt hashed version of the secret in the database and sends back the secret and the id to the Authenticated device.
The Authenticated device, then generates a QR code, that stores only the ID, that it got from the server.
Now on the Authenticator device, we scan this QR code. This will send a signal to the remote server about who scanned the QR code (first).
On the Authenticated device, we will see the username of the user, who scanned this QR code.
On the Authenticator device, the user presses a Verify button. This will send the encryption keys from that device to the Authenticated one (as described above) and this will also send a signal, to allow the remote server, to generate an access token and a refresh token for the user.
While these things happen, the Authenticated device pings the server, if the state has changed. If the auth process went through successfully, then it will just download all data, that has been sent to this device.
On the Authenticated device, we use the private RSA key, to decrypt the keys.
Profit! We have successfully gained an access_token, a refresh_token, generated and exchanged the RSA keys, and also received all of the keys necessary, to decrypt the safes associated with this device.

On the Authenticated device:

// Generate a public and a private RSA key
const { publicKey, privateKey } = RSA.generate(2048);

// Send this publicKey to the server and receive the id and the secret
const { id, secret } = await API.authentication.start({
    publicKey,
});

// Store the private RSA key for future use
await SecureStorage.store("rsa_private_key", privateKey);

// Check the server periodically for response
setInterval(async () => {
    const response = await API.authentication.check({
        id,
        secret,
    });

    if(response.state === "not_yet_scanned") {
        // If noone scanned the code yet do nothing
    } else if(response.state === "scanned_but_not_verified") {
        // If the code has been scanned, but the code has not been verified just show the username for the user, to be able to verify, that they are allowing the right device in
        displayUsername(response.user.username);
    } else {
        // Finally, if everything has been sent and verified, we can do the real job
        for(const exchange of response.keyExchanges) {
            EncryptionKey.save(exchange.safeid, RSA.decrypt(exchange.content));
        }

        AccessToken.save(response.access_token);
        RefreshToken.save(response.refresh_token);
    }
}, 1000);

On the Authenticator device:

// Initialize a new QR code scanner instance
const scanner = new QRCodeScanner();

// Add an event listener for scan
scanner.on("scan", async (id) => {
    // Tell the remote server, that the QR code has been scanned on this device
    const { rsaPublicKey } = await API.authentication.onScan(id);

    // Show the username for the user
    await waitForVerification();

    // Get all the encryption keys
    const keys = await EncryptionKeys.getAll();

    // Iterate over all keys and encrypt them with the RSA key
    const enrypted = [];

    for(const key of keys) {
        encrypted.push({
            safeid: key.safeid,
            content: RSA.encrypt(key.content, publicKey),
        }
    }

    // Send the keys to the device
    await API.authentication.send({
        // The ID, that we scanned with the QR code
        id,
        encryptedKeys: encrypted,
    });

    // Show success screen!
    showSuccessScreen();
});

// Show the QRCode scanner for the user
scanner.start();

Note: This code is also just serves the purpose of demonstration, implementation may vary from platform to platform

What if I lose my device? Will I lose access to my data?

By design, that would be the case. But we can create a backup key, that can be used in the future, to regain access to our data after we lost our phones.

This backup works just like an ordinary device because it is technically a device. It will have a refresh token, to gain access to our vault and it will have an RSA private key, to decrypt the key exchanges sent to it. Ohh... and also, when we create a new vault, we will send a key exchange to this backup key.

With this backup, we can provide the ability, to gain access after you lost your phone.

Thank you for reading!
If you have any questions, feel free to ask them below.

Github organization: github.com/wault-app
Discord: discord.gg/NxhdAf4azz

Wault: The future of password managers

Gál Péter — Thu, 08 Jul 2021 21:05:03 +0000

Password managers are becoming more common these days as we are using an increasing number of sites each day. I have used several password managers for about 4 years, but I've never found the one that fits me. Everyone had some major flaws like it felt outdated or it was too expensive. Then it hit me... why shouldn't I create the next Facebook of password storage?

What were the main goals of the project?

1. The app must have a generous free tier. I wanted a personal plan, where you can store your passwords safely across multiple devices without hassle.

2. The app must feel new and responsive. When I used Lastpass and Bitwarden I felt like I was using a slightly outdated piece of software. I think the best and easiest way to achieve this is by

3. Be open-source. I think this one is obvious. If you make an application open source, then it means that there is nothing to hide.

How can this app compete? What can it give to users, that other managers can't?

1. The password manager without passwords. The most common security threat for an application is user exploitation. You can easily create a clone of the original website and start phishing for passwords. But when you have no you don't have a way to gain access to a user's account.

2. Free for the people, paid for organizations. I have been using WinRAR and I love the idea behind it. My take on this idea is to give the free plan the ability to create 2 people teams (I haven't seen any other password manager do this) and when you want to add more users, then you must pay for the excess number of people.

3. The ability to store crypto wallets. I must admit: the crypto hype train got me too, but when you consider it, then it will look like a good idea. You can store crypto wallets in the application, check your balance, send and receive money. It is easy to implement and also it is unique for this application.

4. Rich customization for secure notes. I have been using Google Keep through my entire high school years, so I got used to it. But when I want to write a note in my Bitwarden Vault, I cannot format my text, nor can I create a checklist, so it is not convenient enough for everyday use.

5. Zero trackings. A password manager must be a private space. You don't want to be tracked when you are managing confidential information.

Want to help?

The project is already in a very early stage of development (as the application is only good enough to log in on the web interface), but any contribution is welcome.

Github organization: github.com/wault-app
Discord: discord.gg/NxhdAf4azz

4 reasons to use NextJS

Gál Péter — Fri, 18 Sep 2020 22:30:09 +0000

At first I was scared to use JavaScript libraries, but then I tried them out and it kinda felt right. I was drawn by this world. It really made my days a lot simpler and me a better developer.

But before I begin. What is NextJS?

NextJS is a javascript library that uses React to help you develop better applications. It manages both your API endpoints and your static or server-sde rendered pages. So it's kind of neat.

vercel / next.js

The React Framework

Next.js

Getting Started

Used by some of the world's largest companies, Next.js enables you to create full-stack web applications by extending the latest React features, and integrating powerful Rust-based JavaScript tooling for the fastest builds.

Visit our Learn Next.js course to get started with Next.js.
Visit the Next.js Showcase to see more sites built with Next.js.

Documentation

Visit https://nextjs.org/docs to view the full documentation.

Community

The Next.js community can be found on GitHub Discussions where you can ask questions, voice ideas, and share your projects with other people.

To chat with other community members you can join the Next.js Discord server.

Do note that our Code of Conduct applies to all Next.js community channels. Users are highly encouraged to read and adhere to them to avoid repercussions.

Contributing

Contributions to Next.js are welcome and highly appreciated. However, before you jump right into it, we would like you to review our…

View on GitHub

1. It will create a faster and lighter website

When it comes to creating a website, writing it only in HTML is not just hard and time consuming, but you probably can't write a better code than what a computer can generate (at least in terms of package size).

The framework will handle bundling better than anything else. If you have funcntions/classes that you don't use it will just simply
leave it out.

If you were to write a basic site with HTML/CSS/JS you would have to remove every unused code to not bloat the users' networks.

2. You can use almost any NPM package

For sure there is browserify and webpack by themselves that can handle this task, but they will generate files that are going to include things that you don't need. If you have multiple packages, you will know that your node_modules folder is weighing several mb of data. If you want to send them every time someone wants to access your site you are going to face slow loading times.

Contary to the NextJS, it will handle everything and you can use any NPM package, that can run in a browser, let's just say it is timsort or material-ui.

3. You're going to have clean developement envoriments

You have imports and the support of typescript (which means that you will have typings and classes thanks God).

I can't stress this enough. You're not really writing pages, but rather you're writing independent Components, that look much cleaner that their predecessor.

Also being able to tell if your variable is a string or a number or if it has username component or not will make your everyday life much better. Trust me.

Shortly, you're going to have typings, which means autocomplete for your code and code splitting, which is good if you're building large applications

4. You're going to have a large community, that can help you

When I first started to use React, I felt that it was so easy, because there were so good documentations. And not just that, you don't even have to worry about creating every single UI components. You have multiple implementations of Material Design Principles. If you don't trust me than just think about that the largest JS framework is React. We can use React components, so I think we kind of have a head start, compared to other frameworks.

Great! How can I jump in?

With the release of create-next-app, it is easier to start creating a project than ever. If you want to jump right in, then after you've installed NodeJS, you just have to run the npx create-next-app command and your project is ready to edit it.

Can you give me some advice?

Use TypeScript!
Use material-ui to create User Interfeces
Have a folder structure that has (/pages, /public, /components) folders.
If you're developing an API use Prisma. It is a database driver, that will generate a type-safe JS module for you to use it in your project.

Thank you for your attention!
Gál Péter (pepyta)