Autenticazione dove nemmeno il fornitore può accedere ai dati
Cerchi una soluzione di autenticazione in cui nemmeno chi gestisce il servizio possa leggere le credenziali dei tuoi utenti? LoginMaster lo rende un'impossibilità tecnica, non una promessa.
In breve
LoginMaster è una piattaforma di autenticazione europea progettata in modo che nemmeno il fornitore del servizio possa accedere alle credenziali o ai dati personali degli utenti finali. Non è una policy interna aggirabile: è un vincolo architetturale. Le password non vengono mai conservate in chiaro né sono ricostruibili, il Cloud LoginMaster opera esclusivamente su dati cifrati e riferimenti, e non esiste alcuna funzione — né via API né dal pannello di amministrazione — che restituisca o reimposti la password di un utente al posto suo.
Come funziona lo zero-knowledge
Cinque garanzie architetturali che rendono l'accesso del fornitore alle credenziali tecnicamente impossibile.
Zero-knowledge sulle credenziali
Non esiste nel codice di LoginMaster una funzione che restituisca la password di un utente, né una che ne imposti una nuova senza la partecipazione attiva dell'utente. Gli hash non sono accessibili via API. Solo l'utente può cambiare la propria password.
Split-salt e hashing Argon2
Le credenziali sono protette con Argon2 e un meccanismo di separazione crittografica (split-salt) che distribuisce i componenti tra più entità. Nessun singolo componente contiene le informazioni per ricostruire il dato originale.
Architettura Tenant–Cloud separata
I dati personali degli utenti risiedono esclusivamente nel Tenant del cliente. Il Cloud LoginMaster verifica le credenziali e firma i token, ma non contiene mai informazioni leggibili: opera solo su dati cifrati e riferimenti.
Doppia firma e isolamento crittografico
Ogni token è firmato sia dal Tenant sia dal Cloud. Ogni tenant possiede chiavi crittografiche uniche generate alla creazione: una violazione su un tenant non ha alcuna superficie d'impatto sugli altri.
Nessun admin onnipotente
Nessun amministratore può resettare la password, cambiare l'email o disabilitare la 2FA di un utente. Questo elimina alla radice il rischio di admin infedeli, social engineering verso l'helpdesk e accessi non autorizzati.
Dati in UE, conformità by design
I dati restano nel Tenant del cliente in Unione Europea. L'architettura soddisfa i requisiti fondamentali di GDPR, NIS2 e ISO 27001 senza strati di protezione aggiunti a posteriori.
LoginMaster a confronto
Il confronto sul punto che conta: chi può accedere alle credenziali dei tuoi utenti.
| Requisito | LoginMaster | Auth0 / Okta | AWS Cognito / Firebase |
|---|---|---|---|
| Il fornitore può accedere alle credenziali degli utenti? | No — impossibile per architettura (zero-knowledge, split-salt) | Hash gestiti e detenuti dal fornitore | Hash gestiti dall'hyperscaler |
| Un admin può resettare password / 2FA di un utente? | No — solo l'utente stesso | Sì (reset lato admin via Management API) | Sì (AdminSetUserPassword / Admin SDK) |
| Residenza dei dati | UE — nel Tenant del cliente | Provider USA (soggetto al CLOUD Act) | Hyperscaler USA (soggetto al CLOUD Act) |
| Isolamento crittografico tra tenant | Sì — chiavi dedicate + doppia firma dei token | Separazione logica | Separazione logica |
| Conformità GDPR / NIS2 by design | Sì — nativa | Configurazione / add-on | Configurazione |
Confronto basato su documentazione pubblica delle piattaforme citate; marchi dei rispettivi proprietari.
Domande frequenti
Significa che il sistema è in grado di verificare l'identità di un utente senza che il fornitore del servizio possieda o possa ricostruire le sue credenziali in chiaro. In LoginMaster le password sono protette con Argon2 e uno schema split-salt che separa i componenti crittografici tra più entità: nessuna singola parte, incluso il fornitore, ha abbastanza informazioni per risalire alla credenziale originale.
L'architettura separa il Tenant del cliente (dove risiedono utenti e credenziali) dal Cloud LoginMaster (il servizio centrale di verifica). Il Cloud non contiene mai dati personali leggibili: opera solo su dati cifrati e riferimenti. I dati personali restano nel Tenant del cliente in UE. È un'impossibilità tecnica, non una promessa contrattuale.
L'utente non recupera la vecchia password: ne imposta una nuova dimostrando la propria identità tramite canali verificati (email, numero di telefono). Nessun amministratore può farlo al suo posto. Questo elimina la funzione 'recupera la password dell'utente X', che semplicemente non esiste nel sistema.
No. Il proprietario del tenant può configurare policy, aggiungere o disattivare utenti, ma non può mai intervenire su password, email o secondo fattore individuali. Questo protegge gli utenti anche nel caso in cui un account amministrativo venga compromesso.
Su queste piattaforme gli hash delle credenziali sono detenuti dal fornitore e un amministratore può reimpostare password o secondo fattore lato server. Sono inoltre fornitori statunitensi, soggetti al CLOUD Act. LoginMaster rende l'accesso del fornitore alle credenziali architetturalmente impossibile, mantiene i dati nel Tenant del cliente in UE e vieta il reset lato admin: solo l'utente controlla le proprie credenziali.
Sì. Le credenziali non sono accessibili a terzi per vincolo architetturale, gli utenti hanno controllo esclusivo su password e 2FA, i dati risiedono in UE e i log di accesso sono disponibili per audit. Questi elementi rispondono ai requisiti fondamentali di GDPR e NIS2 sulla protezione delle credenziali e la gestione degli accessi, con evidenza tecnica documentabile.
Vuoi un'autenticazione che nessuno può violare dall'interno?
Parla con il team LoginMaster: ti mostriamo come lo zero-knowledge protegge i tuoi utenti e semplifica la conformità.