SRP non invia la password nel protocollo: non significa eliminarla, essere immuni al phishing o rendere innocuo il verificatore.
Passkey e SRP sono due approcci diversi all’autenticazione. Una passkey utilizza una coppia di chiavi e può eliminare la necessità di una password. SRP rimane basato su password, ma, quando il protocollo è implementato correttamente, non invia la password stessa al server per dimostrare di conoscerla.
Quindi «accedere senza inviare una password» non equivale ad «accedere senza avere una password». La scelta dovrebbe dipendere dal rischio di phishing, dalla gestione delle credenziali, dal recupero e dalla qualità dell’implementazione, non da una generica etichetta «a conoscenza zero».
Che cosa cambia una passkey?
Nell’autenticazione tramite passkey, il servizio conserva la chiave pubblica e l’utente conferma l’accesso controllando la chiave privata. Il legame della credenziale con il servizio e l’origine pertinenti è una parte importante della resistenza al phishing. La spiegazione di FIDO sulle passkey.
Non tutte le passkey vengono necessariamente sincronizzate nel cloud. Alcune sono vincolate a un dispositivo o a una chiave di sicurezza; altre passano tra dispositivi tramite un fornitore di credenziali. Il modello di recupero e la protezione della sincronizzazione vanno esaminati per quel particolare fornitore. La sola «sincronizzazione nel cloud» non dimostra che l’azienda conservi le chiavi in forma leggibile.
Anche la sicurezza della sessione dopo l’accesso è una questione distinta. Una passkey non neutralizza automaticamente il malware sul dispositivo o il furto di una sessione valida.
Che cosa fornisce SRP al server?
SRP appartiene alla famiglia degli scambi di chiavi autenticati tramite password. Anziché conservare la password stessa, il server memorizza dati come un salt e un verificatore. Scambiandosi i messaggi del protocollo, le due parti verificano la conoscenza del segreto e la chiave condivisa.
Ma un verificatore non è un dato innocuo. La sezione 3.3 dell’RFC 5054 afferma esplicitamente che un attaccante che ottiene il verificatore può effettuare un attacco a dizionario per indovinare la password. È quindi falsa l’affermazione secondo cui «il furto del database non offre alcuna possibilità di tentativi offline».
Restano necessari password robuste, protezione del server, parametri adeguati, validazione degli input e controlli sui tentativi di accesso. SRP non garantisce neppure che la pagina in cui digitate la password sia sicura: un codice malevolo può catturarla prima dell’esecuzione del protocollo.
Un confronto equo
| Domanda | Passkey | SRP |
|---|---|---|
| L’utente memorizza una password del servizio? | Di solito no; è necessario controllare la credenziale | Sì, il metodo si basa sulla conoscenza della password |
| Che cosa conserva il servizio per l’accesso? | Una chiave pubblica e informazioni correlate | Un verificatore e parametri correlati |
| Come si ottiene la resistenza al phishing? | Legando la credenziale al servizio/all’origine nella progettazione FIDO | Non inviare la password nel protocollo non basta a rendere sicura una pagina di inserimento falsa |
| Il cloud è obbligatorio? | No; esistono anche opzioni vincolate al dispositivo | Il protocollo non richiede intrinsecamente un fornitore di identità esterno, ma necessita di un servizio di autenticazione |
| Come avviene il recupero? | Dipende dal tipo di credenziale e dal fornitore | Lo determinano le politiche dell’account e del prodotto, non il nome SRP |
Questa tabella non consente di stilare una classifica assoluta di tutte le implementazioni. Un processo di recupero debole può compromettere il vantaggio di un metodo di accesso robusto.
Che rapporto c’è tra accesso all’account e chiavi della chat?
L’autenticazione indica al servizio chi è autorizzato ad agire. Le chiavi di cifratura dei messaggi determinano chi può aprire i contenuti. Un prodotto può collegare queste due cose, ma il rapporto deve essere documentato.
La documentazione sulla sicurezza di Livara descrive SRP per l’accesso e presenta separatamente il pacchetto di recupero v7 per l’identità cifrata. Quel pacchetto ripristina l’identità, non la cronologia della chat. Per questo, «la password di accesso è corretta» non significa che «tutte le vecchie chiavi e tutti i vecchi messaggi sono tornati».
Questo articolo è un confronto concettuale, non una prova pratica di tutti i metodi di accesso di Livara né una certificazione dell’esatta implementazione di uno specifico RFC nel prodotto.
Che cosa chiedere al momento della scelta?
- Se si perde il dispositivo, qual è la via alternativa di accesso e chi la controlla?
- Il metodo di recupero è più debole dell’accesso principale?
- Come si possono visualizzare e revocare le sessioni sconosciute?
- Cambiare il metodo di accesso modifica le chiavi dei messaggi o i dispositivi collegati?
- Quale account e quali protezioni indipendenti servono per sincronizzare le credenziali?
Conclusione: Non definite le passkey intrinsecamente «insicure perché usano il cloud» né SRP «immune alle violazioni perché a conoscenza zero». I confini di ciascun metodo e la politica di recupero del prodotto sono la base di un confronto affidabile.
