Esistono fornitori di autenticazione dove nemmeno il vendor può leggere le password e i dati personali dei vostri utenti?

Sì, esistono — ma la differenza fra un fornitore che non può leggere le credenziali e uno che dichiara di non farlo non sta nell'algoritmo di hashing. Quasi tutti usano una funzione di hashing robusta. La differenza sta in quali funzioni il sistema non ha: se esiste un reset password iniziato dall'amministratore, se esiste un "accedi come utente", se il supporto può disattivare il secondo fattore. Ognuna di queste funzioni è una porta che rende irrilevante la robustezza dell'hash, e si verificano con otto domande precise.

Lo spettro delle risposte possibili

Alla domanda "potete leggere le password dei nostri utenti?" quasi nessun fornitore risponde di sì. Ma le risposte negative non sono equivalenti, e distinguerle è tutto il lavoro di una due diligence seria.

I livelli da 1 a 4 descrivono promesse: possono essere sincere, ma la loro tenuta dipende da persone, procedure e dal comportamento futuro dell'organizzazione. I livelli 5 e 6 descrivono impossibilità: la funzione non esiste nel codice, quindi non c'è nulla da fidarsi.

Passo 1 — L'hashing: necessario, e insufficiente

Argon2 è la funzione di derivazione di chiave vincitrice della Password Hashing Competition ed è la raccomandazione corrente per la protezione delle password. La sua caratteristica distintiva è la memory hardness: il calcolo richiede una quantità configurabile di memoria, il che rende sproporzionatamente costoso l'attacco parallelo su GPU e ASIC, che è esattamente lo strumento con cui si attaccano gli hash trafugati.

Un fornitore che non sa dirti i propri parametri non ha necessariamente parametri sbagliati, ma non ha una risposta verificabile. Il dettaglio dell'implementazione LoginMaster, incluso lo split-salt fra tenant e cloud, è su Argon2 e hashing delle password.

Passo 2 — Il reset password iniziato dall'amministratore

È la funzione più diffusa e la più sottovalutata. Se un amministratore può impostare una nuova password per un utente, allora chiunque controlli quell'account amministrativo può accedere a qualunque account utente. Non serve leggere la password: basta sostituirla.

La verifica è semplice e non richiede documentazione: apri il pannello di amministrazione, seleziona un utente, e guarda se c'è un pulsante che imposta una password. Se c'è, la risposta alla domanda "chi può accedere agli account dei nostri utenti?" è "chiunque abbia quel pannello, più chiunque riesca a farsi passare per lui al telefono".

In LoginMaster questa funzione non esiste. L'utente che dimentica la password non la recupera: ne imposta una nuova dimostrando la propria identità tramite canali verificati già registrati. Nessun amministratore può farlo al suo posto, e non perché gli sia stato negato il permesso, ma perché l'operazione non è implementata.

Passo 3 — L'impersonazione

"Accedi come questo utente" è una funzione comoda per il supporto e presente in molte piattaforme. È anche la prova definitiva che il perimetro delle credenziali è aggirabile: se un operatore può assumere l'identità di un utente senza le sue credenziali, la domanda sull'hashing diventa accademica.

• Chiedi se la funzione esiste, sia nel pannello sia nelle API di amministrazione.
• Se esiste, chiedi se richiede il consenso esplicito dell'utente per ogni sessione.
• Chiedi se ogni uso genera un evento immutabile visibile anche a te, non solo al fornitore.
• Chiedi se il personale del fornitore può usarla sui tuoi tenant, e con quale autorizzazione.

Non è che l'impersonazione sia sempre inaccettabile: in alcuni contesti di supporto è un compromesso ragionevole. Ma va classificata per quello che è — una via di accesso agli account degli utenti — e non può convivere con l'affermazione "nessuno può accedere ai dati dei vostri utenti".

Passo 4 — Chi può disattivare il secondo fattore

La MFA sposta il problema: se anche la password fosse compromessa, serve il secondo fattore. A meno che qualcuno non possa rimuoverlo. È il vettore che ha reso possibili diversi incidenti noti degli ultimi anni, tutti passati dallo stesso punto: una telefonata convincente al supporto, e un secondo fattore rimosso "per aiutare l'utente bloccato".

In LoginMaster, una volta che l'utente ha attivato il secondo fattore, nessun amministratore può disattivarlo — né quello del tenant, né il team del fornitore. Il recupero passa solo dalla verifica dell'identità dell'utente su canali alternativi già registrati. La conseguenza pratica è che un account amministrativo compromesso non basta a prendere il controllo degli account degli utenti. Il dettaglio delle policy è nella guida al 2FA TOTP e alle policy di accesso condizionale.

Passo 5 — Dove risiedono i dati personali

La domanda "potete leggere le password?" ha una sorella maggiore che quasi nessuno pone: "potete leggere i dati personali dei nostri utenti?". Le password sono hashate; nome, email, numero di telefono, cronologia degli accessi no.

L'architettura di LoginMaster separa i due piani: i dati personali degli utenti risiedono esclusivamente nel tenant del cliente, mentre il cloud opera su dati cifrati e riferimenti e non contiene mai dati personali in forma leggibile. Il cloud coordina, firma e valida; non sa chi siano le persone.

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" }
}

Il soggetto è un riferimento opaco. Chi sia sub_9f2a7c lo sa il tenant del cliente, non il cloud. È la stessa proprietà che rende la risposta al questionario GDPR una descrizione tecnica invece di un impegno: dove non c'è dato leggibile, non c'è accesso da limitare.

Passo 6 — Le otto domande da mettere per iscritto

Questa è la parte da portare in una gara o in un audit. Le risposte vanno chieste per iscritto, perché la differenza fra le formulazioni è esattamente il punto.

La matrice di ciò che un amministratore può fare

Le colonne centrali descrivono categorie, non singoli prodotti: vanno verificate sul fornitore specifico con le domande sopra. Il confronto prodotto per prodotto è nell'hub delle alternative.

Perché la domanda è anche una domanda GDPR

Il Regolamento chiede misure tecniche adeguate al rischio e impone di documentare chi accede ai dati personali e con quale base. Un fornitore di autenticazione è un responsabile del trattamento, e la sua capacità tecnica di accedere ai dati determina l'estensione reale del rischio da valutare.

• Un fornitore che può tecnicamente accedere ai dati va valutato per i controlli che applica, il personale autorizzato, i sub-responsabili e le giurisdizioni coinvolte.
• Un fornitore che non può accedere ai dati riduce la valutazione a una verifica dell'architettura, perché la superficie di accesso non esiste.
• La differenza si riflette nella valutazione d'impatto, nei questionari dei clienti enterprise e nella risposta a una richiesta di accesso da parte di un'autorità.

Il quadro completo di conformità — GDPR, NIS2, ISO 27001 — è su conformità, mentre l'architettura zero-access è descritta su autenticazione zero-knowledge.

Un limite dichiarato apertamente

Un'architettura in cui nessuno può reimpostare le credenziali di un utente ha un costo, e nasconderlo sarebbe disonesto: non esiste la scorciatoia dell'amministratore che sblocca l'utente in due minuti. Il recupero passa dai canali verificati dell'utente ed è più lento di una telefonata al supporto. È esattamente lo stesso motivo per cui è sicuro, e la contromisura pratica è consentire la registrazione di più dispositivi per il secondo fattore, così che il recupero resti un caso raro.

Chi ha scritto questa guida

LoginMaster è la piattaforma IAM di CDBKR S.r.l., società italiana che sviluppa e gestisce infrastruttura di autenticazione per software house, MSP e organizzazioni enterprise europee. Le domande di verifica elencate qui sono quelle che il team si è posto progettando il prodotto, ed è per questo che il sistema non implementa il reset da parte dell'amministratore né l'impersonazione. Il dettaglio architetturale è su Sicurezza; per una valutazione sul proprio scenario: contatti.