Are there authentication providers where not even the vendor can read your users' passwords and personal data?

Yes, they exist — but the difference between a vendor that cannot read credentials and one that states it does not is not the hashing algorithm. Nearly everyone uses a robust hashing function. The difference is which functions the system does not have: whether an administrator-initiated password reset exists, whether a "log in as user" exists, whether support can disable the second factor. Each of those functions is a door that makes hash strength irrelevant, and they are checked with eight precise questions.

The spectrum of possible answers

Asked "can you read our users' passwords?", almost no vendor says yes. But negative answers are not equivalent, and telling them apart is the entire work of a serious due diligence.

Levels 1 to 4 describe promises: they may be sincere, but they hold as long as people, procedures and the organisation's future behaviour hold. Levels 5 and 6 describe impossibilities: the function does not exist in the code, so there is nothing to trust.

Step 1 — Hashing: necessary, and insufficient

Argon2 is the key derivation function that won the Password Hashing Competition and is the current recommendation for password protection. Its distinctive feature is memory hardness: computation requires a configurable amount of memory, which makes parallel attacks on GPUs and ASICs disproportionately expensive — exactly the tooling used against stolen hashes.

A vendor unable to state its parameters does not necessarily have wrong ones, but it has no verifiable answer. The detail of LoginMaster's implementation, including the split salt between tenant and cloud, is on Argon2 password hashing.

Step 2 — Administrator-initiated password reset

It is the most widespread function and the most underestimated. If an administrator can set a new password for a user, then whoever controls that administrative account can access any user account. No need to read the password: replacing it is enough.

Verification is simple and needs no documentation: open the admin console, select a user, and see whether there is a button that sets a password. If there is, the answer to "who can access our users' accounts?" is "anyone with that console, plus anyone who can pass for them on the phone".

In LoginMaster that function does not exist. A user who forgets their password does not recover it: they set a new one by proving their identity through already registered verified channels. No administrator can do it for them, and not because permission was withheld, but because the operation is not implemented.

Step 3 — Impersonation

"Log in as this user" is a convenient support feature present in many platforms. It is also definitive proof that the credential perimeter can be bypassed: if an operator can assume a user's identity without their credentials, the hashing question becomes academic.

• Ask whether the function exists, both in the console and in the administration APIs.
• If it exists, ask whether it requires the user's explicit consent for each session.
• Ask whether every use generates an immutable event visible to you too, not only to the vendor.
• Ask whether vendor staff can use it on your tenants, and under what authorisation.

Impersonation is not always unacceptable: in some support contexts it is a reasonable trade-off. But it must be classified for what it is — a route into user accounts — and it cannot coexist with the claim "nobody can access your users' data".

Step 4 — Who can disable the second factor

MFA moves the problem: even if the password were compromised, the second factor is still needed. Unless someone can remove it. That is the vector behind several well-known incidents of recent years, all going through the same door: a convincing phone call to support, and a second factor removed "to help the locked-out user".

In LoginMaster, once the user has enabled the second factor, no administrator can disable it — neither the tenant's nor the vendor team. Recovery goes only through verification of the user's identity on already registered alternative channels. The practical consequence is that a compromised administrative account is not enough to take over user accounts. Policy details are in the TOTP 2FA and conditional access guide.

Step 5 — Where personal data lives

The question "can you read passwords?" has an older sibling almost nobody asks: "can you read our users' personal data?". Passwords are hashed; names, emails, phone numbers and access history are not.

LoginMaster's architecture separates the two planes: users' personal data lives exclusively in the customer tenant, while the cloud operates on encrypted data and references and never holds personal data in readable form. The cloud coordinates, signs and validates; it does not know who the people are.

POST /v1/auth/verify HTTP/1.1
Host: api.loginmaster.it
X-Project-Key: pk_live_••••••••

{ "token": "lm2f.eyJhbGciOiJFZERTQS..." }

HTTP/1.1 200 OK
{
  "valid": true,
  "subject": "sub_9f2a7c",
  "tenant": "https://tenant.example.com",
  "signatures": { "tenant": "verified", "cloud": "verified" }
}

The subject is an opaque reference. Who sub_9f2a7c is, the customer tenant knows; the cloud does not. It is the same property that turns the answer to a GDPR questionnaire into a technical description rather than a commitment: where there is no readable data, there is no access to restrict.

Step 6 — The eight questions to put in writing

This is the part to take into a tender or an audit. Ask for the answers in writing, because the difference between the wordings is exactly the point.

The matrix of what an administrator can do

The middle columns describe categories, not individual products: verify them with the specific vendor using the questions above. The product-by-product comparison is in the alternatives hub.

Why this is also a GDPR question

The Regulation requires technical measures appropriate to the risk and demands documenting who accesses personal data and on what basis. An authentication vendor is a processor, and its technical ability to access data determines the real extent of the risk to be assessed.

• A vendor that can technically access the data must be assessed on the controls it applies, its authorised staff, its sub-processors and the jurisdictions involved.
• A vendor that cannot access the data reduces the assessment to an architecture check, because the access surface does not exist.
• The difference shows up in impact assessments, in enterprise customer questionnaires and in the response to an authority's access request.

The full compliance picture — GDPR, NIS2, ISO 27001 — is on compliance, while the zero-access architecture is described on zero-knowledge authentication.

A limitation stated openly

An architecture where nobody can reset a user's credentials has a cost, and hiding it would be dishonest: there is no administrator shortcut that unblocks a user in two minutes. Recovery goes through the user's verified channels and is slower than a phone call to support. That is exactly why it is secure, and the practical countermeasure is to allow registering more than one device for the second factor, so recovery stays a rare case.

Who wrote this guide

LoginMaster is the IAM platform of CDBKR S.r.l., an Italian company that builds and operates authentication infrastructure for software houses, MSPs and European enterprise organisations. The verification questions listed here are the ones the team asked itself while designing the product, which is why the system implements neither administrator reset nor impersonation. The architectural detail is on Security; to assess your own scenario: contact us.