Con il server è necessario memorizzare un "verificatore di password" con una struttura speciale; in SRP 3 (quello descritto in RFC 2945 ), questo è descritto in questo modo:
The host stores user passwords as triplets of the form
{ <username>, <password verifier>, <salt> }
Password entries are generated as follows:
<salt> = random()
x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
<password verifier> = v = g^x % N
Il protocollo non può funzionare se il server non ha v o salt perché il server deve inviare salt al client (nei passi iniziali del protocollo) e deve utilizzare v non lungo successivamente. Pertanto, indipendentemente da ciò che memorizza in realtà, il server deve conoscere abbastanza da recuperare o ricalcolare salt e v in una frazione di secondo. Un utente malintenzionato che ottiene una copia completa del server sarà in grado di fare lo stesso e arrivare a salt e v , consentendo un attacco di forza bruta veloce sulla password (veloce perché il calcolo di v , dato il salt , username e una password putativa, implica solo un paio di SHA-1 e un esponenziazione modulare).
Quindi l'unica speranza è trovare un modo per gli attaccanti di non ottenere una copia completa del server. Cioè, crittografa simmetricamente i dati che sono memorizzati, con una chiave che poi memorizzerai "altrove" e prega per il meglio. Ad esempio, la maggior parte delle violazioni della persuasione di "SQL injection" consentono all'autore dell'attacco di acquisire una copia più o meno completa dei dati del server memorizzati nel database, ma non consente (immediatamente) di leggere file arbitrari al di fuori del database. Se il server memorizza la chiave di crittografia simmetrica in un file e utilizza tale chiave per crittografare i campi rilevanti nel database (ovvero i valori v ), gli autori di attacchi che ottengono solo un dump del database verranno sconfitti.
Una variante consiste nell'impostare un server interno extra che memorizza i valori di salt e v . Il tuo server principale parlerebbe con quel server secondario. In tal caso, il server secondario sarebbe in grado di rilevare i tentativi di pompaggio completo di tutti i valori, nel caso in cui il server principale venisse totalmente dirottato dagli aggressori. Almeno, la separazione fisica proteggerebbe i valori sensibili ( salt e v ) da iniezioni SQL e violazioni simili.
C'è poco altro che puoi fare senza modificare il client.