Sto sviluppando un'applicazione la cui architettura è organizzata come segue:
Session host <---> Central relay server <---> Session client
Tutta la comunicazione tra l'avvio di session host
e il successivo collegamento di session client
viene inoltrata attraverso il server centrale.
Il session host
deve essere protetto in modo tale che non sia possibile accedervi senza una chiave di sessione pubblica che lo identifica e una password privata che ha stipulato in anticipo.
In effetti nessuna comunicazione che dovrebbe mai essere possibile con session host
a meno che session client
possa dimostrare al server centrale che è autorizzato, vale a dire che l'autenticazione dovrebbe avvenire sul server centrale stesso.
Quindi nel flusso di lavoro che ho in mente:
-
La
session host
si collega al server centrale su TLS, inviando un hash della sua password scelta. -
Il server centrale risponde con una chiave di sessione generata che identifica l'host di sessione.
-
La
session client
si connette al server centrale specificando la chiave di sessione e l'hash della password tentata. -
Il server centrale controlla gli hash per una corrispondenza, se c'è una corrispondenza, i messaggi di
session client
s possono passare asession host
, se non c'è una corrispondenza, l'autenticazione ha fallito.
Quindi la mia domanda è la seguente.
L'hashing della password in questo modo fornisce una sicurezza aggiuntiva rispetto all'invio delle password dichiarate e tentate? Come devo gestire la salatura?
Sono propenso a pensare che valga la pena poiché significa che la password completa non viene mai inviata attraverso il filo, anche se su TLS. Non è nemmeno memorizzato nella RAM sul server centrale. Protegge la password degli utenti, ma non offre alcuna sicurezza aggiuntiva per la sessione in quanto l'hash diventa la password.
Grazie