MeldID: From a Single Account to a Digital Access Management System

When I first explored MeldID, I mainly viewed it as an infrastructure for unified digital identification. The user creates a single account, fills out a manageable profile, and then can use it across various applications — for login and transmitting permitted data without repeatedly filling out the same forms.

I anticipated that future development would focus on profiles and connected services. However, the project quickly shifted from an almost invisible server infrastructure to a practical daily tool for access management.

The next step was the introduction of applications for iPhone and Android. What’s particularly interesting here isn’t just the creation of the mobile client but the range of tasks it manages to unify.

Standard TOTP — with a different purpose

The app includes a generator for one-time TOTP codes—the same changing digits used for two-factor authentication.

The standard itself isn’t claimed as an invention; a user adds an account and receives a code that can be used on a third-party service or website.

Most authenticators answer the question: “How to display a six-digit code?” Here, a broader task is addressed: how to securely manage the lifecycle of TOTP secrets—from addition and storage to recovery on another device and deletion of records.

Full offline mode

At first glance, the main advantage seems to be local code generation only. But MeldID’s offline mode offers more.

Already stored entries continue to work without internet access. Codes are generated directly on the phone, so temporary disconnection doesn’t hinder two-factor verification.

New TOTP entries can also be added offline. They are stored locally and immediately used to generate codes. When internet connectivity is restored, the addition automatically uploads to a secure vault and syncs with other devices.

Editing and deleting synchronized records require server connection. This prevents different versions of a vault from appearing on separate phones.

The result is a balance: core actions are available offline, and changes that need to be consistent across devices are applied once back online.

A new phone doesn’t mean a new set of codes

The most inconvenient issue for any authenticator arises after losing, breaking, or replacing a phone. Typically, users have to find backup codes, manually transfer entries, or re-link the app with each service.

In this system, the vault is linked not to a specific device but to the MeldID account. After logging into a new phone and initializing the secured vault, entries are automatically restored.

It doesn’t matter whether the previous device was Android and the new is iPhone, or vice versa. Users can connect a second, third, or multiple devices without a separate transfer process for each platform.

Imagine a scenario where a smartphone unexpectedly breaks during a trip. Instead of restoring access individually for each service, the user logs into MeldID on the new device and completes the vault setup. Afterward, their TOTP records return to the app.

You can use multiple different MeldID accounts on a single device. Their vaults remain separate: one account’s entries do not mix with another’s and only appear on the device after proper authorization.

What is stored on the server

Automatic recovery requires data storage somewhere. However, TOTP secrets aren’t stored in plaintext in the database.

The contents of each record are placed inside an encrypted container. The current architecture uses authenticated AES-256-GCM encryption, and the key of the protected vault is separated from the database itself.

Therefore, a data leak of one database does not translate into an accessible list of secrets for generating codes. An attacker only obtains encrypted blocks, not the plaintext TOTP data.

It’s important to avoid making absolute promises here. More precisely, plaintext TOTP secrets are not stored in the database, and having just one copy of the database isn’t enough to misuse them.

Login confirmation via MeldID

The second important function of the app is Login Approval, a separate confirmation of authorization.

If a website or app supports MeldID, users can start the login process with a single action. When the security is enabled, successful authentication alone isn’t enough: authorization is considered complete only after confirming on a trusted mobile device.

The login request can be approved if it indeed originated from the user, or declined if the operation appears unexpected.

Unlike regular push confirmations, Login Approval is integrated directly into MeldID’s architecture and can be used by all services connected to this identity system.

Push notifications serve only as alerts about a new operation. They contain no password, TOTP code, token, or other authentication data.

TOTP and Login Approval complement each other

TOTP remains a universal standard and works even in services that are unaware of MeldID. Codes are generated locally after the record is loaded.

Login Approval is necessary where the login process itself is through MeldID. It adds a conscious user action to the login process, allowing the user to halt an attempt before the session is established.

Thus, the app can serve as a regular authenticator for external sites and simultaneously as an approval tool for connected systems.

What has changed in MeldID itself

When I first encountered the project, the main idea was managing a single account and portable profile. Now it’s clear that MeldID is gradually transforming into a personal central hub for digital access management.

Its capabilities now include:

• receiving TOTP codes offline;

• adding new records offline;

• automatically restoring records to a new device;

• using multiple phones;

• separating multiple accounts on one device;

• confirming or rejecting new logins.

The value of the app, therefore, isn’t just about displaying the six-digit code. Its broader goal is to preserve access when changing devices, retain data without internet, and provide the owner with the last conscious decision before creating a new session.

Security here is built upon a comprehensive set of solutions: TOTP secrets are not stored openly, access isn’t permanently tied to a single device, multiple accounts remain isolated, and login to supported services only completes after confirmation from a trusted device.