Qual è il valore di sicurezza di questa registrazione utente SRP al volo?

Sì, il tuo approccio funzionerebbe.

Alcuni commenti però.

Dove dici:

2. The client sends the username and a randomly generated value to the server.

Non è chiaro quale sia lo scopo del valore casuale e non penso che sia necessario.

In seguito dici:

4. If no user exists, the server sends the RSA Public key to the client, requesting the client to generate a salt, and verifier.

SRP è progettato in modo tale che il sale sia assegnato a chiunque conosca il nome utente che desidera eseguire una prova della password. Quello può essere un attaccante ostile che prova a indovinare la password che ha imparato il nome utente. Quindi, la crittografia del sale al momento della registrazione non aggiunge sicurezza. È necessario crittografare il verificatore per impedire un attacco del dizionario offline. Il sale che puoi inviare insieme al nome utente al passaggio 2.

Per maggiore sicurezza, vale la pena crittografare il nome utente sul cavo; un utente malintenzionato deve saperlo per cercare di indovinare password ovvie o molto deboli. Quindi è meglio usare TLS per crittografare l'intera comunicazione di registrazione da end-to-end per proteggere l'identità dell'utente. Il tuo approccio richiede una chiave pubblica RSA per crittografare (almeno) il verificatore. Ciò comporta la generazione di una coppia di chiavi pubblica privata per il server. Quindi è lo sforzo equivalente per generare un certificato autofirmato per ogni server al momento dell'installazione. Quindi è possibile eseguire TLS per l'intero processo di registrazione con il certificato autofirmato generato.

Se si esegue solo la crittografia del verificatore, è necessario forzare l'utente a selezionare una password complessa per la protezione da parte di qualcuno che ha visualizzato il nome utente del testo semplice che indovina una password debole. Anche se si cripta il nome utente, in genere si utilizza lo stesso nome utente su molti servizi, quindi è facilmente ipotizzabile; applicare una password sicura è comunque una buona idea.

( Modifica vedi questa risposta / domanda che suggerisce anche una connessione crittografata è la strada da percorrere link )

( Modifica nota come protezione del nome utente è una buona idea che dovresti prendere in considerazione l'utilizzo di TLS per l'accesso al gioco, emettere un numero casuale a 128 bit come token di sessione e farli scollegare e riconnettere senza crittografia passare il token di sessione come credenziali per mappare la nuova connessione non crittografata all'account utente su cui è stato rilasciato il token su TLS. Quindi non devono mai passare il nome utente in testo non crittografato).

Una cosa da considerare sono i robot. Hai reso la registrazione molto facile e conveniente. Ciò rende anche molto facile e conveniente per i griefer, gli imbroglioni o altri tipi di malintenzionati di creare bot che sciamano su un server.

A seconda del tuo gioco, potrebbe essere irrilevante. Ma la registrazione automatica senza CAPTCHA è qualcosa che dovresti prendere in considerazione.

Il secondo problema più grosso che vedo con la registrazione è che non esiste l'autenticazione del server. Quando mi registro inizialmente, non c'è modo di verificare che sto parlando con il server reale, e non falso. Non sembra che un utente malintenzionato possa intercettare traffico con un man-in-the-middle (non può imparare rapidamente a impersonare me sul server, quindi il meglio che può fare è passare il mio sale e verificatore e abbandona). Tuttavia, non appena l'utente malintenzionato ha appreso il mio verificatore, potrebbe iniziare a fare un attacco del dizionario contro di esso, proprio come se avessero ottenuto un hash della password. Sfortunatamente, SRP non è particolarmente progettato per resistere agli attacchi di dizionario contro i verificatori; un'implementazione comune utilizza solo due iterazioni di SHA-1 e un'esponenziazione modulare. Anche se ha usato un buon hash per la password, il fatto che una password sia strongmente hash con un buon salt non significa che un hacker possa ottenere l'hash e che un hacker sia ancora probabile in grado di forzare le password deboli. Se l'hacker esegue correttamente questa operazione, ora ha una combinazione di nome utente e password che ha una buona possibilità di lavorare su altri siti Web più importanti.

L'unico modo per prevenire quell'attacco implicherebbe una qualche forma di comunicazione fuori banda. Ad esempio, TLS normalmente lo risolve con la PKI basata su X.509 (che è ciò che protegge la registrazione su un sito Web HTTPS).

Il primo problema il primo è che lo sviluppo di giochi non è normalmente il posto dove progettare un nuovo sistema di autenticazione, perché la sicurezza è difficile . È molto, molto meglio se ti attieni ai protocolli standard. Inoltre, fare ciò richiederà l'implementazione di SRP da solo, ed è anche meglio attenersi alle implementazioni standard. Quindi, il modo migliore per farlo sarebbe utilizzare una buona implementazione SRP poiché è stata progettata per essere utilizzata e utilizzare qualcos'altro per la registrazione (come TLS o qualcosa del genere, in cui è possibile accettare i certificati dalle CA standard e autorizzare gli autoprestiti ma avvisare l'utente).