Why Protect a Password When You Can Get Rid of It?

A problem we’ve come to accept as normal

Almost every web application has an admin panel. And an admin panel usually has a login address, an authentication form, a username, and a password.

We’ve grown so accustomed to this setup that we’ve nearly stopped asking whether it really has to work this way.

When you have one website, the problem doesn’t seem significant. You create a strong password, enable two-factor authentication, set limits on login attempts—and get on with your work.

But what happens when you have ten, twenty, or thirty projects?

In my case, I’m talking about the DigiMeld ecosystem, which brings together more than thirty independent software projects. Each has its own architecture, server-side logic, and administrative interface.

So each one needs a mechanism for administrative access.

For a long time, I used a familiar approach: separate administrative credentials, strong passwords, and saved passwords in the browser.

It worked.

But at some point, I started wondering: why should I have to store so many administrative passwords at all? Why do I have to protect not only my servers, but also the means of accessing them?

And is there a way to get rid of that need?

I arrived at an idea that later became the foundation of my solution:

Perhaps what needs protecting isn’t a permanent login, but the right to gain access temporarily.

Strong passwords don’t solve the underlying problem

Modern tools can generate passwords with very high entropy. A properly generated, long, random password is practically impossible to guess through brute force.

But no matter how strong a password is, it still has to be stored somewhere and then used.

You can use password managers, hardware keys, multifactor authentication, and additional restrictions. All of these really do improve security.

But the underlying architectural setup remains: there’s an interface through which users present their credentials.

It can receive requests. It can be scanned. It can become a target for automated attacks.

You can hide the admin panel’s address, replace the standard path with a long, random string, or restrict access by IP.

But then a new question arises: where do you store that address, and how do you use it?

And most importantly, why keep a permanent entry point if you only need administrative access at certain times?

I arrived at an idea that later became the foundation of my solution:

Perhaps what needs protecting isn’t a permanent login, but the right to gain access temporarily.

What if there were no familiar login page at all?

I decided to move away from the traditional model of administrative authentication in my projects.

Not just hide the login form.

Not rename the address.

Not replace the password with an even more complex one.

But eliminate the need for a permanently available password-based login.

Of course, the administrative interfaces didn’t disappear. They’re still necessary for managing applications.

What changed was how you get access to them.

Now, logging in to the admin panels of connected projects doesn’t require entering a saved username and password.

Instead, I use my own identity and access management system, MeldID.

The idea is simple enough: administrative access is granted only when it’s actually needed, to a specific user, and for a specific project.

And simply having an account doesn’t automatically mean you have the right to open an admin panel.

That right has to be granted separately.

Access that didn’t exist a minute ago

This is probably the most interesting part of the whole concept.

In the traditional model, administrators always have the means to log in. They can use them today, tomorrow, or a month from now, as long as those credentials remain valid.

I decided to change that principle.

Instead of permanent administrative credentials, the system provides a temporary way to initiate a login.

It’s created on request through a trusted mobile device, includes a cryptographically strong random component, and is valid for a limited time.

But even possessing this temporary link doesn’t, by itself, grant access.

This is a fundamental point.

Suppose someone obtains the link somehow. In a conventional system that relies solely on keeping the address secret, such a leak could be a serious problem.

In my model, the link only lets you start the verification process.

To proceed, you need separate approval through a trusted MeldID mobile device.

Without that approval, no administrative session is created.

That’s why I see a temporary link not as a replacement for a password, but as one part of the process for granting access.

Knowing where to go and having the right to get in are two entirely different things.

Your phone becomes an access management tool

In this model, a mobile device plays a much more important role than that of a standard one-time code generator.

It’s used to approve actions related to administrative access.

When I want to open an admin panel, the system requests approval through MeldID.

I see the request on my trusted device and approve the action.

Only after verification succeeds does the system let me continue the login process.

The approval is tied to a specific action, not simply to the fact that the phone has been unlocked.

Mobile biometrics verify the user locally, while the server checks a cryptographic confirmation from the registered device.

This approach means we don’t have to rely solely on a password or on a message claiming that the user approved the login.

And there’s another advantage: trusted devices can be managed.

If a device should no longer be used to approve access, its trusted status can be revoked.

After that, it’s no longer a valid means of authorizing those operations.

One system, many independent projects

When I started developing this mechanism, one of my main goals was to preserve each project’s independence.

I didn’t want to combine all the admin panels into one enormous application.

Every DigiMeld service should still manage its own logic, settings, users, and data.

So I separated the two responsibilities.

MeldID handles identity and grants administrative access.

Each project handles its own administrative functions and verifies that the user’s permissions are valid.

The result is a centralized access management model that doesn’t require centralizing the applications themselves.

Permissions are also granted separately.

An administrator of one project doesn’t automatically get access to the others just because they have a MeldID account.

You can define a separate group of authorized users for each administrative area.

At the same time, regular user permissions and administrative privileges remain separate.

This has proved especially convenient for an ecosystem of dozens of services.

Why I prefer temporary access to permanent access

There’s another principle I deliberately built into the system.

Administrative access shouldn’t last forever.

Permission is valid for a limited time and expires whether or not the user is still working in the browser.

To continue working after it expires, the user has to go through the approval process again.

This prevents one successful login from turning into a right that remains active indefinitely.

But a time limit alone isn’t enough.

It’s important to be able to end access early.

That’s why MeldID supports centralized revocation of administrative permissions.

When a permission is revoked, connected projects receive the corresponding event and invalidate the related administrative sessions.

In other words, access management doesn’t end when the user successfully logs in.

To me, the ability to revoke privileges is just as important as the ability to grant them.

A distributed system also has to account for delays in event delivery, temporary unavailability of individual components, and other operational circumstances. Session expiration provides an additional safeguard.

So what changed in day-to-day work?

First of all, I no longer need to keep reaching for saved administrative passwords.

I don’t need to keep a set of credentials in my browser for logging in to every connected admin panel.

Instead, I manage permissions through a single mechanism.

I choose the project I need, approve access, and get to work.

When I no longer need administrative access, I can revoke it.

It’s especially convenient that adding a new project doesn’t mean redesigning the entire administrative authentication system from scratch.

All I have to do is connect it to the existing model and define the permissions it needs.

Of course, that doesn’t mean all security risks have disappeared.

Temporary permissions, trusted devices, server sessions, and central infrastructure all need protection too.

But I no longer have to solve the same administrative password management problem separately for every application.

And that was one of my original goals.

Don’t technologies like this already exist?

Of course they do.

Passwordless authentication, privileged access management, temporary permissions, and approval through trusted devices have all been well known in the information security industry for a long time.

These approaches can be found in Identity and Access Management and Privileged Access Management systems, as well as in Zero Trust concepts.

I’m not claiming to have invented these principles.

My goal was different.

I needed to build an integrated system of my own that would address the specific needs of DigiMeld’s infrastructure and let me manage administrative access across many independent projects.

As a result, I brought several established approaches together in one architecture that meets my requirements.

And I believe the value of engineering work doesn’t necessarily lie in inventing a completely new technology.

Sometimes it lies in defining the problem correctly and finding the right solution for it.

MeldID isn’t just for admin panels

There’s one important clarification to make here.

MeldID wasn’t created solely as a tool for my own administrative access.

It also provides developers with an SDK for integrating identity and login approval mechanisms into their own applications.

And that SDK is available for free.

For example, a third-party developer can use MeldID as an additional layer of approval for user authentication.

Even if an application retains traditional username-and-password login, entering those credentials successfully doesn’t have to be enough to complete authentication.

The user receives a request on a trusted mobile device, where they can approve or reject the login attempt.

This helps reduce the risk of unauthorized access if credentials are compromised.

It’s important to distinguish this generally available MeldID feature from the administrative access model I developed for DigiMeld projects.

They share principles of trust and action approval, but they solve different problems.

Security isn’t only about protecting what already exists

Working on this system made me look at familiar authentication mechanisms differently.

We often try to protect things that exist for historical reasons.

We add new checks, restrictions, extra passwords, and layers of protection.

Sometimes that really is necessary.

But sometimes it’s more useful to ask a different question:

Does the mechanism we’re protecting really have to exist in its current form?

In my case, the answer was no.

I didn’t need an administrative login form that was always available.

I needed a way to gain administrative privileges securely, exactly when they were needed.

Those are two different problems.

And shifting from the first to the second changed not only the technical architecture, but also my day-to-day work with the projects.

Not a final destination, but a direction we’ve chosen

Today, this architecture is already running across a significant part of the DigiMeld ecosystem.

The remaining projects are gradually being moved to the new administrative access model.

I’m migrating them one by one, checking each application as I go. Once the transition is complete, I plan to conduct an additional audit of the entire system.

Some interface elements and session management rules may still change.

But the core idea is already settled.

I don’t want to go back to a model where managing dozens of my own projects means constantly storing and using dozens of administrative passwords.

At the same time, I don’t consider my implementation a universal solution for everyone.

Different organizations have different requirements, infrastructure, threat models, and administrative practices.

What’s convenient and appropriate for the DigiMeld ecosystem won’t necessarily be the best choice for another developer.

However, the principle of granting privileges temporarily is worth considering.

In closing

I decided to share this experience not because I consider myself the inventor of a new authentication method.

And not because I want to present yet another system as completely secure.

Absolute security doesn’t exist.

I simply find the question itself interesting.

Instead of endlessly protecting a permanent administrative login, we can reconsider whether it needs to exist at all.

Instead of storing lots of passwords, we can use temporary permissions.

Instead of granting automatic trust after the first login, we can approve the granting of specific privileges.

Instead of waiting for a session to expire, we can make it possible to revoke access centrally.

And finally, instead of a separate login mechanism for every project, we can build one system for managing administrative access while keeping the applications independent.

I’m not claiming that this approach eliminates the possibility of a compromise.

It simply shifts the focus from protecting credentials that exist permanently to granting and revoking privileges in a controlled way.

Perhaps, sometimes the most effective way to reduce the attack surface isn’t to add yet another layer of protection, but to get rid of something the system can work perfectly well without.

That idea was the starting point for the story of MeldID Admin Gateway.