Si tratta di uno schema di scambio dati sicuro per un gioco?

Prima di tutto, crypto è difficile e non devi creare il tuo .

Vulnerabilità

Il tuo accesso sembra essere affetto da una vulnerabilità dell'hash . Un utente malintenzionato non ha bisogno di crackare l'hash per accedere, può solo passare l'hash e accedere. Ciò vanifica lo scopo dell'hash della password in primo luogo.

sha512 non è raccomandato per la memorizzazione di password, poiché è troppo veloce . Invece, usa qualcosa come bcrypt .

HTTPS e crittografia

Dici che RSA è troppo costoso. Ma in generale, RSA viene utilizzato solo per lo scambio di una chiave, che viene quindi utilizzata con un crittosistema a chiave privata molto meno costoso.

Come hai chiarito che utilizzi HTTPS, è necessario notare che utilizzi già RSA. HTTPS utilizza RSA o diffie hellman per lo scambio di chiavi e alcuni codici a blocchi o stream per la crittografia dei dati effettiva.

Poiché utilizzi HTTPS, disponi già di riservatezza e integrità dei dati (e dell'autenticazione del server e facoltativamente dell'autenticazione client), non è necessario crittografare ulteriormente a livello di applicazione.

Vantaggi del tuo schema?

Il tuo schema non sembra davvero servire a nessuno scopo. Sei già al sicuro da intercettazioni e manomissioni dei dati tramite HTTPS (e il tuo schema non l'avrebbe comunque impedito).

Quindi il tuo schema non sembra avere a che fare con lo scambio di dati così tanto, visto che riguarda l'autenticazione.

Generalmente, l'autenticazione viene gestita in questo modo:

Login:

• Il client invia nome utente e password (semplice)
• Server hash password e confronta hash con hash in db
• Il server invia di nuovo l'ID di sessione

Altre richieste:

• Il client invia l'ID di sessione
• Il server convalida l'ID di sessione
• (facoltativo) quando lo stato della sessione cambia, il server rigenera l'ID di sessione

Il tuo approccio è simile, ma ha introdotto il pass della vulnerabilità dell'hash e contiene un seed, che sembra non essere necessario e quindi complica lo schema. Rigenera anche l'id di sessione su ogni richiesta, che non è realmente necessaria e sembra solo causare un sovraccarico non necessario.

... Client sends "login" request with username, hash and seed to the server.

Poiché il seed è stato creato dal client, la combinazione di seed e hash costituisce effettivamente una password equivalente che può essere ripetuta più e più volte. Probabilmente stai tentando di implementare qualcosa di simile a Autenticazione del digest qui. Ma con l'autenticazione digest il nonce (cioè il tuo "seed") è determinato dal server e non dal client e quindi sicuro contro gli attacchi di replay.

A parte questo: stai già utilizzando HTTPS che protegge il traffico contro lo sniffing e la modifica. Perché costruire un altro meccanismo di sicurezza su di esso? L'autenticazione del digest viene solitamente utilizzata per le connessioni che non sono crittografate e presenta il problema che è necessario avere la password in chiaro (o equivalente) sul server. Se la connessione è già protetta dallo sniffing, non è necessaria una protezione aggiuntiva per la password e può essere inviata in chiaro. Questo ha il vantaggio di poter memorizzare la password come hash irreversibile sul server.