Multi-layer cryptographic security
LoginMaster protects your organization's identities with a separated Tenant-Cloud architecture: dual-signature tokens, split-salt credentials, cryptographic isolation between tenants, and exclusive user control over every sensitive operation.
The pillars of LoginMaster security
The architecture separates the Tenant and the LoginMaster Cloud, protecting every level of communication with dedicated and independent cryptographic keys.
Separated Tenant-Cloud architecture
In LoginMaster, the Tenant is the customer entity that contains users and credentials, while the LoginMaster Cloud is the central verification service. This architectural separation ensures that customer data remains isolated from the centralized authentication logic.
The Tenant and Cloud communicate through dedicated cryptographic keys for each tenant. Each project also has its own specific key to communicate only with its tenant. This means that no key is shared between different entities.
- Clear separation between customer data and verification service
- Dedicated cryptographic keys for each tenant
- Specific key for each project
- No keys shared between different entities
Dual-signature tokens
When a user authenticates, the LoginMaster Cloud verifies the credentials and generates the resulting token. This token is signed by both the Tenant and the Cloud, creating a dual signature that guarantees authenticity from both parties.
The client receives the dual-signature token, but the communication between client and API uses a separate cryptographic certificate. This means that every step of the authentication flow is protected with different and independent keys.
- Token signed by both the Tenant and the Cloud
- Separate certificate for client-API communication
- Different keys at every level of the flow
- The compromise of one key does not expose the others
Opaque Cloud and split-salt
Users' personal data resides exclusively on the customer's Tenant. The LoginMaster Cloud never contains readable information: it operates only on encrypted data and references. Credentials are protected with a cryptographic separation mechanism that distributes components across multiple entities: no single component possesses sufficient information to reconstruct the original data.
Not even the provider can access your users' data. This is not a matter of policy, but a technical impossibility: the Cloud does not possess the information needed to reconstruct any personal data.
- Personal data only on the Tenant, never copied to the Cloud
- The Cloud operates exclusively on encrypted data and references
- Not even the provider can access users' data
- Technical impossibility, not just corporate policy
Cryptographic isolation between tenants
Each tenant in LoginMaster operates with its own unique cryptographic keys, generated at creation time. These keys are neither shared nor derived from a common key: each tenant is a cryptographically independent entity.
Furthermore, each project within the tenant has its own keys for communication with the tenant. The complete compromise of a tenant -- including all its keys -- provides no advantage for attacking another tenant.
- Unique cryptographic keys for each tenant
- Dedicated keys for each project
- No shared or derived keys between tenants
- Compromise of one tenant = zero impact on others
Full user autonomy
In LoginMaster, no administrator can reset passwords, change emails, or disable 2FA on behalf of a user. Only the user themselves can perform these operations, through secure procedures designed to prevent identity theft.
This principle eliminates one of the most common vulnerabilities in traditional IAM systems: the abuse of administrative privileges. Not even the provider has the ability to intervene on users' credentials.
- No admin can reset passwords
- No admin can change emails
- No admin can disable 2FA
- Secure procedures against identity theft
Multi-layer security architecture
Overview of the defense layers that protect every authentication request in LoginMaster.
Built-in security features
Every component of LoginMaster is built with security as a fundamental requirement, not as an afterthought.
Multi-Layer Encrypted Communication
Each layer of the architecture uses different and independent cryptographic keys. The client communicates with a dedicated certificate, the project has its own key, the tenant has separate keys, and the Cloud operates with its own. No key is shared between layers.
Dual-Signature Tokens
Every authentication token is signed by both the Tenant and the LoginMaster Cloud. This dual signature guarantees that the token was generated and validated by both parties, making it impossible to create fraudulent tokens from a single component.
Cryptographic credential separation
Credentials are protected with advanced hashing and a cryptographic separation mechanism that distributes components across multiple entities. No single component possesses the information to reconstruct the original data. The Cloud never contains readable personal data and not even the provider can access users' information.
Cryptographic Isolation Between Tenants
Each tenant and each project have unique and independent cryptographic keys. The compromise of one tenant does not impact the others in any way. No shared or derived keys exist between different tenants.
Full User Autonomy
No administrator can reset passwords, change emails, or disable 2FA. Only the user can perform these operations through secure procedures designed to prevent identity theft.
Access Tracking
Every login attempt is recorded, whether successful or failed. The system tracks access attempts, enabling the identification of suspicious patterns and proactive protection of user accounts.
Per-project configurable 2FA
2FA in LoginMaster is configurable at the individual project level. Each project can set it as disabled, optional, or mandatory. The user enables 2FA only when at least one project they are associated with requires it. The mechanism is based on TOTP codes, compatible with apps like Google Authenticator.
Learn MoreFrequently Asked Questions About Security
When a user authenticates, the LoginMaster Cloud verifies the credentials and generates a token. This token is signed by both the Tenant (the customer entity) and the central Cloud. The client then receives a dual-signature token. For API communication, a separate cryptographic certificate is used, which means that every step of the flow is protected with different keys.
Split-Salt is the mechanism by which LoginMaster separates credentials between the Tenant and the Cloud. The local salt is stored on the Tenant, while the Cloud receives only encrypted data for verification. The Cloud never contains personal data in readable form: it operates exclusively on encrypted data and references. Users' data resides only on the Tenant, under the customer's control. Not even the provider can access it.
Each tenant in LoginMaster has its own unique cryptographic keys, generated at creation time. Furthermore, each project within the tenant has its own specific keys for communication with the tenant itself. The compromise of one tenant has no impact on the others, since no shared or derived keys exist between different tenants.
No. In LoginMaster, no administrator can reset passwords, change emails, or disable 2FA on behalf of a user. Only the user themselves can perform these operations through secure procedures designed to prevent identity theft. This principle of full user autonomy is a foundational pillar of the security architecture.
2FA in LoginMaster is configurable per individual project: it can be disabled, optional, or mandatory. The user enables 2FA only if at least one of the projects they are associated with requires it. The mechanism is based on TOTP codes, compatible with apps like Google Authenticator.
The Tenant and LoginMaster Cloud communicate through dedicated cryptographic keys for each tenant. Each project also has its own specific key to communicate exclusively with its tenant. The communication between the client and the APIs uses a separate cryptographic certificate. In this way, each level of the flow uses different keys, creating multi-layer protection.
Yes, LoginMaster records every login attempt, whether successful or failed, with useful information for security monitoring. This enables the identification of suspicious patterns such as repeated access attempts from unrecognized sources, contributing to proactive account protection.
Protect your organization's
Request a personalized demo to discover how LoginMaster protects your organization's identities with a multi-layer security architecture.
Guaranteed response within 24 business hours.