SRP evita di inviare la password nello scambio di accesso; non rende innocuo un verificatore rubato.
Secure Remote Password, o SRP, consente a un client e a un server di autenticarsi usando una password senza inviarla nel normale scambio del protocollo. Può ridurre l’esposizione verso un server che altrimenti riceverebbe la password durante l’accesso.
Non elimina dal server tutti i segreti legati alla password. Il server conserva un verificatore, e un verificatore rubato può consentire tentativi offline di indovinare la password. Questa distinzione è essenziale nel valutare affermazioni sull’«accesso a conoscenza zero».
Che cosa cambia rispetto a un accesso convenzionale con password?
In un sistema convenzionale, il client invia la password su una connessione TLS autenticata. Un server ben progettato confronta un opportuno hash della password con salt, evita di registrare le credenziali nei log e applica protezioni contro i tentativi di indovinarla. TLS protegge la connessione; l’hash della password protegge in modo diverso la credenziale archiviata.
SRP cambia lo scambio. Durante la registrazione, il sistema stabilisce il salt e il materiale del verificatore. All’accesso, entrambe le parti usano nuovi valori del protocollo e i rispettivi segreti per stabilire e confermare materiale di chiave condiviso. Il client usa la password; il server usa il proprio verificatore. Un client onesto non trasmette la password stessa come contenuto della richiesta di accesso.
La specifica SRP in RFC 2945 spiega i fondamenti del protocollo. Profili e implementazioni successivi richiedono una revisione dei parametri esatti e dei controlli sui messaggi; chiamare un progetto «SRP» non dimostra che ogni scelta implementativa sia corretta.
| Domanda | Accesso convenzionale con password su TLS | Scambio SRP implementato correttamente |
|---|---|---|
| Il server applicativo riceve la password inserita durante l’accesso? | Normalmente sì | Non come parte dello scambio del protocollo |
| Quale materiale sensibile di autenticazione viene archiviato? | In genere un hash della password con salt | Salt e un verificatore derivato dalla password |
| Un database rubato può consentire tentativi offline? | Sì, a seconda del materiale archiviato | Sì, il materiale di un verificatore SRP rubato può consentire tentativi |
| Protegge da un keylogger? | No | No |
| Cifra automaticamente la cronologia dei messaggi? | No | No |
Perché un verificatore rubato continua a essere importante
La sezione 3.3 di RFC 5054 tratta esplicitamente i verificatori rubati. Spiega che un verificatore può permettere a un attaccante di impersonare il server e condurre attacchi a dizionario per recuperare la password.
La distinzione importante è che il verificatore non è semplicemente un token di accesso riutilizzabile del client. Questo non lo rende innocuo. Un attaccante può provare password candidate contro il materiale rubato invece di risolvere un problema di logaritmo discreto per ogni possibile segreto. Una password debole o riutilizzata rimane un rischio serio.
I limiti di frequenza online possono rallentare i tentativi contro un servizio attivo, ma non controllano i calcoli eseguiti su un database rubato. Protezione del database, trattamento attento delle password e password robuste e uniche restano importanti.
Da che cosa SRP non protegge
Un endpoint compromesso: Il malware può catturare la password prima che il protocollo inizi o rubare in seguito una sessione autenticata.
Una pagina di accesso malevola: Se la pagina che chiede la password è essa stessa ostile, può inviare altrove il testo digitato. Un’applicazione web continua ad avere bisogno di un percorso di distribuzione affidabile.
Tutti i percorsi di recupero: Un flusso via email, SMS o assistenza che concede accesso all’account ha requisiti propri. Il metodo normale di accesso più robusto può essere indebolito da un’alternativa meno sicura.
Ogni attacco attivo di rete: Contano i parametri del protocollo, la validazione degli input, la conferma reciproca e la connessione autenticata circostante. Non sostituire le protezioni TLS prescritte per una distribuzione con lo slogan «la password non viaggia mai».
Metadati o cifratura della chat: L’autenticazione stabilisce se una sessione debba essere ammessa. Non determina quali registrazioni delle conversazioni esistano o chi detenga le chiavi per decifrare i messaggi.
Come Livara separa l’accesso dal recupero dell’identità
La panoramica sulla sicurezza di Livara descrive l’autenticazione SRP separatamente dal protocollo di messaggistica LVR1. Documenta anche un backup cifrato dell’identità della versione 7, protetto da una chiave di recupero casuale distinta di 256 bit.
Il backup viene sigillato crittograficamente prima del caricamento e ripristina l’identità crittografica, non la cronologia della chat. Conoscere soltanto la password dell’account non ripristina quelle chiavi di cifratura. Viceversa, affermare che l’assistenza non può ricostruire un segreto di cifratura non dimostra che non possa esistere alcuna azione di gestione dell’account o procedura di cambio password.
Il modello di minaccia include anche la compromissione dei dispositivi e i metadati di comunicazione visibili. SRP non dovrebbe essere usato per ridefinire l’intero servizio come «a conoscenza zero» rispetto a ogni aspetto dell’attività di un utente.
Una lista pratica di valutazione
Come utente, scegli una password robusta e unica, proteggi il dispositivo, conserva il materiale di recupero in un luogo separato appropriato e comprendi come revocare le sessioni. Non digitare un segreto in un sito non affidabile solo perché dichiara di usare SRP.
Come revisore tecnico, richiedi il profilo esatto del protocollo, l’elaborazione dalla password al verificatore, la validazione degli input, la gestione degli errori, il flusso di registrazione e il progetto del ripristino. Esamina insieme client e server. Includi test per valori pubblici non validi, replay e sessioni interrotte, anziché affidarti soltanto a un test di accesso riuscito.
SRP è uno strumento utile per limitare la divulgazione delle password durante l’autenticazione. Il suo valore è più chiaro quando i vantaggi reali vengono descritti insieme a furto dei verificatori, compromissione degli endpoint e rischi del recupero, anziché presentarlo come la fine dei problemi di sicurezza delle password.
