Archiviazione sicura di dati segreti in un'applicazione Web sul lato client


11

Ho questa applicazione web che sarà tutta la tecnologia lato client (HTML, CSS, JavaScript / AngularJS, ecc ...). Questa applicazione web interagirà con l'API REST per accedere e modificare i dati. Al momento è indeciso su quale tipo di sistema di autenticazione utilizzerà l'API REST.

Da quanto ho capito, qualsiasi tipo di sistema di autenticazione API (chiavi API, OAuth 1/2, ecc ...) avrà alcuni dati che devono essere tenuti segreti, altrimenti l'accesso potrebbe essere compromesso. Per le chiavi API, le stesse chiavi devono essere segrete, per OAuth 2 il segreto del client / token di accesso / token di aggiornamento deve essere tenuto segreto, sono sicuro che alcune delle 4 chiavi coinvolte in OAuth 1 devono essere mantenute segrete (non troppa esperienza con OAuth 1). Ho cercato di pensare se esiste un modo per archiviare queste cose segrete in una pura applicazione web lato client senza una sorta di strato intermedio sul lato server.

Ho cercato di pensarci e non riesco a pensare a nessun posto dove farlo. Voglio dire, non riesco a memorizzarlo in JavaScript perché chiunque può semplicemente visualizzare la fonte o aprire la console e ottenere i dati. Non sono sicuro al 100% di quanto sia sicuro localStorage e se gli utenti possono accedere / modificare tali dati. Anche se l'archiviazione locale era sicura, i due modi in cui riesco a pensare di ottenere i dati non lo sono. Un modo è semplicemente archiviare i dati nel codice sorgente javascript che è la cosa più insicura a cui riesco a pensare. Ora se usassi qualcosa come OAuth 2 in cui il resto api stesso mi darebbe i token, non sarebbe ancora così sicuro (meglio della prima opzione) perché quei token verrebbero restituiti come testo normale che chiunque possa vedere il le richieste che il computer sta facendo potrebbero vedere.

Esiste un modo per fare in modo che un'applicazione completamente in esecuzione sul lato client sia in grado di archiviare in modo sicuro dati segreti senza una sorta di livello intermedio sul lato server?



Localstorage è specifico del browser, ma prendendo come esempio Opera su Windows, ci sono solo alcuni file del disco nella cartella del profilo dell'utente, quindi è essenzialmente non protetto.
Ross Patterson,

Un modo sarebbe quello di mantenere il segreto sul server in un db e avere solo application_id sul client. Quindi esegui la query oauth dal server, quindi questo è un tipo di approccio proxy.
Simon Polak,

Risposte:


9

No, non può mai essere completamente sicuro. L'utente ha il controllo dell'hardware e stai cercando di tenere qualcosa fuori dalle loro mani. Alla fine, POSSONO farcela in un modo o nell'altro. Dal momento che stai lavorando da JavaScript, la tua posizione è MOLTO peggiore di una normale applicazione per computer, poiché non solo l'utente controlla l'hardware, ma controlla anche il sandbox in cui ti trovi.

Puoi nascondere le cose e rendere difficile arrivare alle cose, ma alla fine POSSONO farcela, se ci provano abbastanza.


4
^ questo. Quanto sono "segreti" i dati segreti e quanto tempo e denaro vale la pena proteggere? Gli sforzi "standard di settore" potrebbero essere sufficienti.
DaveE

+1 Risposta eccellente. Con un debugger JavaScript, posso modificare la tua applicazione, visualizzare valori intermedi, ecc. Se voglio le informazioni, le otterrò.
Ross Patterson,

2

Quando si progettano sistemi di sicurezza, è sempre necessario pensare al modello di minaccia. " Renderlo sicuro " è un requisito sciocco, non utilizzabile o verificabile. " Impedire all'utente di estrarre i token di accesso dall'applicazione " è molto meglio e definisce i confini della soluzione. " Impedire ad altri di ottenere i token di accesso di un utente " è anche meglio e definisce uno spazio di soluzione completamente diverso. Le soluzioni per l'una non risolveranno necessariamente l'altra ( ad esempio , quest'ultima richiede assolutamente SSL se è coinvolto il WiFi, ma ciò non influirà affatto sulla prima).


0

un'opzione è che l'API REST conceda l'accesso o meno sulla base di un accesso utente; può restituire un token basato su sessione (guid, stringa con hash, qualunque cosa tu voglia) che può essere passato alle altre chiamate API REST per autenticare l'accesso

se sei preoccupato di memorizzare le informazioni di accesso dell'utente sul computer client, allora non farlo, ma l'utente dovrà inserire ogni volta le informazioni sull'account e sulla password

non molto familiare con OAuth et al, ma non vedo motivi convincenti sopra per archiviare persistentemente informazioni di autenticazione ...


Per quanto riguarda i motivi, c'è sempre "conforto" che ovviamente è l'arcogemesi di "sicurezza" e "sicurezza".
henon,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.