Completo apolidia, come salvare la password sul client in modo sicuro

Question

Completo apolidia, come salvare la password sul client in modo sicuro

#1 da (3 voti)

-1

Pensando all'apolidia, mi chiedo come posso superare il problema di salvare la password dell'utente sul lato client in modo sicuro ma anche comodo.

Presumo che il client invii sempre le credenziali al server e che utilizzi la potenza della CPU per verificare l'autenticità e assicurarsi inoltre che l'utente abbia l'autorizzazione a fare qualsiasi richiesta.

In questo modo spero di ottenere una configurazione in cui nessun server ha bisogno di interrogare il database per alcune informazioni sulla sessione su ogni richiesta e invece spreca alcuni cicli della CPU. Naturalmente potrei aggiungere una cache al server, ma con molti utenti concorrenti cosa posso tenere in cache e cosa posso eliminare? Ogni server dovrebbe avere un utente nella sua cache o cercarlo dal db. Ora se le richieste sequenziali colpiscono sempre altri server, colpiscono inutilmente il db o inseriscono qualcosa nella loro cache.

D'altro canto, devono comunque farlo per garantire l'autenticità (intendo che devono controllare i crediti) o l'autorizzazione. Ma per il gusto dell'argomento, supponiamo che non lo facciano.

Ora: come posso memorizzare la password sul client in modo che dopo un messaggio di autenticazione iniziale un server arbitrario che risponde con "Credentials okay" posso riutilizzarli, ma non inviarli plaintext su ogni richiesta. (Intendo qui il plaintext. Ovviamente ho bisogno di inviare la password o qualche token su ogni richiesta, questa è l'essenza dell'essere apolidi.Se introduco un token d'altra parte, non sono veramente stateless più, sono io? E se memorizzo la password salata / crittografata dal server - dato che lo restituisce dopo l'iniziale handshake, anche questo è male, presumo).

Supponiamo che il client sia:

a) un web browser b) un'applicazione arbitraria

Qualche idea?

storage passwords server client

posta Sorona 27.01.2017 - 18:54

fonte

1 risposta

Leggi altre domande sui tag storage passwords server client

Misure di copertura del test Decisioni della piattaforma applicativa Intranet wamp vs node [closed]

score 3 · Accepted Answer

Non puoi.

Dici che non vuoi inviare nuovamente la password in ogni richiesta, ma allo stesso tempo, vuoi rimanere senza stato. Non puoi averli entrambi.

Ciò che puoi fare, tuttavia, è generare una chiave sull'autenticazione corretta. Questa chiave verrà quindi archiviata sul lato client e inviata ad ogni richiesta per essere controllata dal server. Ciò significa anche che quando il server deve eseguire il controllo, dovrebbe essere un roundtrip al database, a meno che lo stesso stesso server abbia già eseguito il controllo in precedenza e memorizzato nella cache la risposta.

Questo approccio non è molto diverso dall'invio della semplice password ogni volta. L'unica differenza è che in realtà non si memorizza la password normale per un lungo periodo. Si noti che per quanto riguarda la sicurezza, la differenza non è così grande: se un utente malintenzionato ha accesso al browser (ad esempio installando un plug-in dannoso), l'utente malintenzionato sarebbe in grado di intercettare la password comunque nel momento in cui l'utente lo inserisce e lo invia il modulo.

Ma, aspetta, questo non significa che non sei più stateless?

In realtà no. Quello che succede è che ogni richiesta richiede una chiave da fornire nella richiesta HTTP, e quando no, il server risponde con HTTP 401. Quando viene fornita la chiave, il server esegue un'autenticazione ordinaria. Questo è esattamente come se tu stessi richiedendo le credenziali dell'utente.

Quello che succede è che le chiavi potrebbero (e dovrebbero) avere una politica di scadenza. Ad esempio, se l'ultima richiesta dell'utente è avvenuta cinquanta giorni fa, può essere molto adatto per invalidare la chiave e richiederne una nuova. O se l'ultima richiesta dell'utente era venti secondi fa dall'Oregon, e ora sembra provenire da Nuova Delhi, chiedere di confermare la password potrebbe essere probabilmente un passo appropriato. Ma questo non significa che l'API non sia più stateless: allo stesso modo, l'utente può improvvisamente cambiare la password, e la chiamata API che ha funzionato pochi secondi fa risulterà in HTTP 401 se ripetuta con le stesse credenziali.

That way I hope to achieve a setup where no server needs to query the database for some session info upon each request and instead wastes some CPU cycles.

O semplicemente usi una cache distribuita, ad esempio Redis.

but with many concurrent users what do I keep in cache and what can I get rid off?

Penso che "scadenza cache" sia il termine che stai cercando.