Il questionario di sicurezza, e dove sono le risposte
Le domande sull'accesso di un questionario di sicurezza aziendale, con le risposte per EAuth e la clausola o pagina dietro ognuna, compreso il nostro no.
Il primo grande cliente manda un foglio di calcolo: una colonna per la Sua risposta, una per le prove, e una buona parte delle righe dedicata a come accedono le persone. Se ha costruito l'accesso da sé, è qui che scopre cosa non ha costruito. Se usa EAuth, la maggior parte delle righe ha già una risposta. Questo è l'elenco, con la clausola delle condizioni di EAuth o la pagina della documentazione che sostiene ogni risposta. Le condizioni sono versionate e ogni versione resta pubblicata (14.3), quindi la clausola che Lei cita non cambia a Sua insaputa.
Dove sono conservati i dati, e da chi?
Solo in Svizzera e nello Spazio economico europeo; lo dice il contratto per il trattamento dei dati (allegato B.14). Dal 3 ottobre 2026 EAuth gira sul nostro cluster: otto server presso cinque provider di hosting in quattro Paesi. I tre nodi del database sono a Francoforte, Norimberga e Parigi, l'applicazione gira a Ginevra e ad Amsterdam, i due edge dove termina il TLS sono a Falkenstein e ad Amsterdam, e un sorvegliante gira a Ginevra. Davanti a loro non c'è il proxy di nessuna terza parte. Le e-mail, cioè conferme di indirizzo, reset delle password e inviti, partono tramite un servizio di recapito della posta, che vede l'indirizzo del destinatario e il testo dell'e-mail.
Prova: allegato B, il contratto per il trattamento dei dati, che non richiede una firma separata. Le condizioni ci impegnano ad annunciare un nuovo subresponsabile 30 giorni prima che inizi, e Lei può recedere se si oppone (8.5, B.8).
Come sono salvate le password?
Argon2id, 64 MiB di memoria, tre iterazioni, due lane, un salt casuale di 16 byte per password, con i parametri dentro ogni hash salvato, così si possono alzare in seguito senza un reset. Refresh token, codici di autorizzazione, chiavi API, inviti e codici di recupero sono salvati solo come digest SHA-256, e così anche i link che confermano un indirizzo o reimpostano una password. Le chiavi di firma dei token sono cifrate con AES-256-GCM sotto una chiave che non sta mai nel database. Prova: allegato C.1, e la tabella della pagina sulla sicurezza che spiega come sono salvate le credenziali.
Gli indirizzi e-mail sono verificati?
Sì, prima che un'applicazione veda l'account. Dal 3 ottobre 2026 nessuna applicazione riceve un account il cui indirizzo non sia stato confermato. Una persona che si registra viene fermata sulla via del ritorno da una pagina che invia un nuovo link, e il link riporta all'accesso; un'applicazione che chiede in modo silenzioso, con prompt=none, riceve interaction_required. Quindi email_verified è true in ogni ID token proveniente da un accesso. Un indirizzo vale come confermato tramite il link, tramite un reset della password inviato a quell'indirizzo, o quando il provider di identità di un'organizzazione se ne fa garante. Prova: il quickstart nella documentazione.
È disponibile l'autenticazione a più fattori? È obbligatoria per gli amministratori?
Disponibile per ogni utente finale: un'app di autenticazione con codici di recupero, e le passkey. Se i Suoi utenti debbano avere un secondo fattore lo decide un'impostazione della Sua applicazione, e un'organizzazione può richiederlo ai suoi membri. Da parte nostra, ogni ruolo che può modificare contenuti o credenziali deve usare un secondo fattore, e la dashboard lo verifica a ogni richiesta, non solo all'accesso. Prova: allegato C.2.
Come sono protette le sessioni?
I refresh token ruotano a ogni uso, e un token già ruotato che viene ripresentato revoca l'intera catena, perché il client legittimo e un ladro non possono avere entrambi il più recente. I codici di autorizzazione vivono sessanta secondi, funzionano una volta e sono legati al client, al redirect URI e alla challenge PKCE; PKCE con S256 è obbligatorio su ogni richiesta. Gli access token vivono 15 minuti di default. Le sessioni amministrative vengono verificate sul database a ogni richiesta, quindi revocarne una ha effetto immediato. Prova: allegato C.3, e la sezione «What is enforced» della pagina sulla sicurezza.
Come vi proteggete dagli attacchi brute force?
Ogni tentativo viene contato prima di essere verificato, per indirizzo e per account, e se i contatori falliscono, chiudono: se l'archivio dietro di loro non è raggiungibile, la pagina di accesso rifiuta invece di lasciar passare le richieste. Cinque password sbagliate per un account da un indirizzo, o venti da qualsiasi provenienza, lo sospendono fino a quindici minuti. I codici del secondo fattore ammettono cinque errori in quindici minuti e venti in un giorno. Un browser che ha già effettuato l'accesso all'account conserva una quota propria, quindi un attaccante non può chiudere fuori il proprietario tirando a indovinare. Prova: la pagina sulla sicurezza, con i numeri, e l'allegato C.4.
Esiste un audit trail?
Ogni modifica alle credenziali e alle impostazioni di un'applicazione finisce in un log di audit con l'account e l'indirizzo e-mail di chi l'ha fatta: creazione di un'applicazione, rotazione del suo secret, modifica delle impostazioni, webhook, team, organizzazioni e relativo single sign-on, importazioni ed esportazioni di account, account cancellati e account passati di mano tramite single sign-on. Un trigger del database rifiuta qualsiasi modifica a una voce, e rifiuta di cancellarne una che abbia meno di dodici mesi. Prova: allegato C.5.
Per quanto tempo conservate che cosa?
Sessioni e refresh token fino alla scadenza, e quelli revocati fino a quando sarebbero scaduti, così una copia rubata presentata più tardi viene ancora riconosciuta. I codici di autorizzazione un'ora oltre i loro sessanta secondi. I link di conferma e di ripristino una settimana dopo l'uso o la scadenza, gli inviti 30 giorni. Il log delle richieste di token e il log di audit dodici mesi, le consegne dei webhook 30 giorni. Un account viene cancellato 30 giorni dopo la richiesta del proprietario; uno senza accessi da 24 mesi riceve due e-mail a 30 giorni di distanza e viene cancellato 30 giorni dopo la seconda, a meno che non acceda. Una pulizia rimuove ogni ora ciò che è dovuto. Prova: la pagina sulla sicurezza, «How long things are kept», e le condizioni 7.4 e 7.5.
Possiamo andarcene?
Sì, con gli hash delle password. La console esporta un'applicazione con account, organizzazioni, ruoli, webhook e impostazioni in JSON in qualsiasi momento, senza chiedere a noi. Gli hash sono nella loro forma originale, Argon2id o qualunque formato con cui sono stati importati, quindi i Suoi utenti mantengono le loro password presso il provider successivo. Le passkey sono legate al dominio di accesso e non possono spostarsi, e i segreti del secondo fattore e quelli del servizio stesso non vengono esportati, quindi le persone li configurano di nuovo. Prova: condizioni 7.2 e 7.3.
Cosa succede quando EAuth non funziona?
Gli access token già emessi continuano a funzionare fino alla scadenza, 15 minuti di default, perché la Sua applicazione li verifica con le nostre chiavi pubbliche senza interpellarci. Dopo, i refresh falliscono, e i nuovi accessi falliscono finché EAuth non torna. Le condizioni lo dicono esplicitamente (4.7), e dicono che non c'è nessun service level agreement né impegno di disponibilità (4.1). Se minuti di blocco non sono accettabili, possiamo allungare la durata dei Suoi access token, oppure Lei può gestire EAuth sui Suoi server (4.8, sezione 11).
Ciò che rende meno probabile un'interruzione: due nodi applicativi e due edge in Paesi diversi, e tre nodi di database con replica sincrona, così una scrittura viene confermata solo quando ce l'hanno entrambe le repliche. La pagina di stato su status.elchi.dev mostra lo stato attuale; la disponibilità misurata viene pubblicata lì quando sarà stato misurato un mese intero, e non prima. Un'interruzione di oltre 30 minuti riceve in questo diario una nota con la sua causa (4.9).
Supportate il single sign-on per il nostro provider di identità?
SAML 2.0 per organizzazione, con richieste tramite redirect HTTP come fanno Entra ID, Okta e Google Workspace. Le firme vengono verificate da una libreria mantenuta con il certificato che Lei ha configurato, ogni risposta deve appartenere a una richiesta partita dallo stesso browser e viene accettata una sola volta, e l'indirizzo asserito deve stare nel dominio verificato dell'organizzazione. Le risposte che un provider invia senza che nessuno le abbia chieste vengono rifiutate. Non c'è SCIM: gli account compaiono al primo accesso. Prova: docs.elchi.dev/enterprise-sso.
C'è stato un audit di sicurezza indipendente?
No. Le condizioni lo dicono (9.2, allegato C.6), e quando verrà fatto un audit, il risultato sarà pubblicato qualunque cosa dica. Non c'è nemmeno un report SOC 2 o un certificato ISO 27001. Se un questionario ha bisogno di un sì in questo punto, oggi non possiamo darlo, e preferisco che Lei lo sappia da noi piuttosto che dall'auditor che incarica.
Come veniamo informati dei cambiamenti?
Una modifica sostanziale alle condizioni viene annunciata con 30 giorni di preavviso per e-mail e nel changelog (14.1), un nuovo subresponsabile con 30 giorni (8.5), e un cambiamento che rompe le integrazioni con 90 giorni, a meno che un problema di sicurezza non richieda un periodo più breve (2.3). Ogni e-mail di preavviso viene registrata, così si può dimostrare che il preavviso è stato dato. Il passaggio dell'issuer da auth.elchi.dev a eauth.me il 3 ottobre 2026 non ha richiesto preavviso: quel giorno tutte le applicazioni registrate su EAuth appartenevano a Elchi Studios (2.4). Prova: quelle clausole, e docs.elchi.dev/changelog.
Cosa scrivere nella colonna delle prove
La clausola con la versione: «Condizioni EAuth 1.7, allegato C.1». Un team di sicurezza può confrontare una clausola versionata con il testo pubblicato, e la risposta resta vera per la versione citata. Un link a una pagina di funzionalità dimostra solo che qualcuno l'ha scritta.
Fonti
- EAuth Terms of Service, Elchi Studios, consultato il
- Security, EAuth documentation, Elchi Studios, consultato il
- RFC 9700: Best Current Practice for OAuth 2.0 Security, IETF, consultato il
- RFC 7636: Proof Key for Code Exchange by OAuth Public Clients, IETF, consultato il
- RFC 9207: OAuth 2.0 Authorization Server Issuer Identification, IETF, consultato il
Scritto da Samuel Krauss, Founder. Archiviato in eauth, security, enterprise, gdpr.
Tradotto dall’inglese. Leggi l’originale inglese