Come posso proteggere un valore nonce all'interno di app il cui codice sorgente è pubblico?

Sono uno dei principali manutentori di Nylas N1. Penso che l'altra risposta sia un buon consiglio generale, ma qui ci sono un paio di suggerimenti specifici per N1:

• Se si desidera proteggere un processo o un algoritmo, è possibile scriverlo in un modulo nodo nativo che è distribuito in forma binaria. Al momento non lo facciamo, ma molte altre app basate su JavaScript (il DRM di Spotify è in una libreria C ++ distribuita insieme al JS.)

• Se si desidera autenticare il client con un servizio, utilizzare OAuth a tre vie. Con OAuth a tre vie distribuisci il Application ID ma non il Application Secret nel client. Quando l'utente esegue l'accesso, viene restituito un Code e si passa quel Code al proprio server (la terza parte), dove viene utilizzato il Segreto applicazione per scambiare il codice per un token , che viene rinviato al cliente. Questo processo è doloroso da implementare, ma garantisce che gli unici token sensibili che il client abbia mai sono per gli account che l'utente ha autenticato.

• Se desideri memorizzare token, chiavi API utente, ecc. lato client, ti consigliamo di utilizzare node-keytar . È già disponibile in N1 tramite require('keytar') . Fornisce una semplice API per l'archiviazione dei segreti nel portachiavi dell'utente su Mac, Windows e Linux. Attualmente lo utilizziamo per memorizzare token API N1.

Spero che ti aiuti! Sentiti libero di contattare me o altri ingegneri di Nylas sul nostro canale di slack della community all'indirizzo link

In generale, non ci si può fidare di NIENTE dal client - questo è il problema che il link è destinato a risolvere, ma questa è una lunga strada da percorrere La cosa migliore da fare è autenticare l'utente e assicurarsi che tutte le azioni dell'utente siano autorizzate, indipendentemente dal fatto che provengano da un'app reale o da qualcuno che gioca con la tua API, tramite MITM o tramite accesso diretto.

Come le note di @Bakuriu sopra, i nonces sono valori casuali, usati una volta, sempre diversi: sono usati per prevenire attacchi di replay e come token negli schemi di prevenzione CSRF, per esempio. Quello che stai pensando è, forse, una chiave API - un valore usato per autenticare un utente (dove l'utente potrebbe essere un programma). Come dici tu, non puoi inserirlo nell'applicazione, poiché l'utente può accedervi tramite disassemblaggio, ispezione del codice sorgente o tramite ispezione del traffico di rete.

Quindi, segui la strada per non fidarti del cliente. Ciò significa che ogni utente deve essere autenticato, indipendentemente dal client utilizzato. Quindi verifichi che quell'utente abbia il permesso di fare l'azione desiderata. È possibile immettere le chiavi API per ciascun utente.

Uno schema potenziale: chiedi loro di verificare chi sono effettuando l'accesso al tuo sito web e generando per loro una chiave che possono fornire all'app: l'app può salvarla nel portachiavi dell'utente se desideri mantenerla comoda. Quando provano a eseguire un'azione, verificare la chiave API sul database. Finché questo viene fatto su canali sicuri, questo è ragionevole e utilizzato da molti servizi.

Un altro: far autenticare l'utente al tuo servizio (potenzialmente tramite Login con Facebook o qualsiasi altra cosa - oauth / openid sono buoni). Quindi verifica l'utente direttamente su ciascuna richiesta.

Entrambi hanno il vantaggio di essere facili da revocare e di limitare l'utente a ciò che è autorizzato a fare, indipendentemente dal modo in cui fanno la richiesta.

TUTTE le verifiche di autenticazione e verifica dell'autenticazione dovrebbero avvenire sul lato server, sempre. Il cliente si trova in territorio nemico e non può mai essere considerato attendibile (a corto di bruttezza del TPM).