Authentication where not even the provider can access the data
Looking for an authentication solution where not even the service operator can read your users' credentials? LoginMaster makes it a technical impossibility, not a promise.
In short
LoginMaster is a European authentication platform designed so that not even the service provider can access end users' credentials or personal data. This is not a bypassable internal policy: it is an architectural constraint. Passwords are never stored in cleartext nor reconstructable, the LoginMaster Cloud operates exclusively on encrypted data and references, and there is no function — neither via API nor from the admin panel — that returns or resets a user's password on their behalf.
How it works the zero-knowledge model
Five architectural guarantees that make provider access to credentials technically impossible.
Zero-knowledge on credentials
There is no function in LoginMaster's code that returns a user's password, nor one that sets a new one without the user's active participation. Hashes are not accessible via API. Only the user can change their own password.
Split-salt and Argon2 hashing
Credentials are protected with Argon2 and a cryptographic separation mechanism (split-salt) that distributes components across multiple entities. No single component holds the information needed to reconstruct the original data.
Separate Tenant–Cloud architecture
Users' personal data resides exclusively in the customer's Tenant. The LoginMaster Cloud verifies credentials and signs tokens, but never contains readable information: it works only on encrypted data and references.
Dual signature and cryptographic isolation
Every token is signed by both the Tenant and the Cloud. Each tenant owns unique cryptographic keys generated at creation: a breach on one tenant has zero blast radius on the others.
No omnipotent admin
No administrator can reset a user's password, change their email or disable their 2FA. This eliminates at the root the risk of rogue admins, helpdesk social engineering and unauthorized access.
EU data, compliance by design
Data stays in the customer's Tenant within the European Union. The architecture meets the core requirements of GDPR, NIS2 and ISO 27001 without protection layers bolted on afterwards.
LoginMaster compared
The comparison on the point that matters: who can access your users' credentials.
| Requirement | LoginMaster | Auth0 / Okta | AWS Cognito / Firebase |
|---|---|---|---|
| Can the provider access users' credentials? | No — impossible by architecture (zero-knowledge, split-salt) | Hashes managed and held by the provider | Hashes managed by the hyperscaler |
| Can an admin reset a user's password / 2FA? | No — only the user themselves | Yes (admin reset via Management API) | Yes (AdminSetUserPassword / Admin SDK) |
| Data residency | EU — in the customer's Tenant | US provider (subject to the CLOUD Act) | US hyperscaler (subject to the CLOUD Act) |
| Cryptographic isolation between tenants | Yes — dedicated keys + dual token signature | Logical separation | Logical separation |
| GDPR / NIS2 compliance by design | Yes — native | Configuration / add-on | Configuration |
Comparison based on public documentation of the cited platforms; trademarks of their respective owners.
Frequently asked questions
It means the system can verify a user's identity without the service provider owning or being able to reconstruct their credentials in cleartext. In LoginMaster passwords are protected with Argon2 and a split-salt scheme that separates cryptographic components across multiple entities: no single party, including the provider, has enough information to recover the original credential.
The architecture separates the customer's Tenant (where users and credentials reside) from the LoginMaster Cloud (the central verification service). The Cloud never contains readable personal data: it operates only on encrypted data and references. Personal data stays in the customer's EU-based Tenant. It is a technical impossibility, not a contractual promise.
The user does not recover the old password: they set a new one by proving their identity through verified channels (email, phone number). No administrator can do it on their behalf. This removes the 'recover user X's password' function, which simply does not exist in the system.
No. The tenant owner can configure policies, add or deactivate users, but can never act on individual passwords, emails or second factors. This protects users even if an administrative account is compromised.
On these platforms the credential hashes are held by the provider and an administrator can reset passwords or the second factor server-side. They are also US providers subject to the CLOUD Act. LoginMaster makes provider access to credentials architecturally impossible, keeps data in the customer's EU Tenant and forbids admin-side resets: only the user controls their own credentials.
Yes. Credentials are not accessible to third parties by architectural constraint, users have exclusive control over password and 2FA, data resides in the EU and access logs are available for audit. These elements meet the core GDPR and NIS2 requirements on credential protection and access management, with documentable technical evidence.
Want authentication that no one can breach from the inside?
Talk to the LoginMaster team: we'll show you how zero-knowledge protects your users and simplifies compliance.