Come proteggere l'API (chiave privata) per le app mobili

Question

Come proteggere l'API (chiave privata) per le app mobili

#1 da (1 voti)
#2 da (0 voti)

9

Sto creando un servizio web che deve essere accessibile solo per le app iOS. In futuro, desidero espandermi su un sito web mobile per rendere il mio servizio disponibile anche per altri sistemi operativi mobili.

Ora, ho tutto ciò che funziona tramite un'API. i miei utenti possono registrarsi, cercare società, ordinare prodotti da quelle società e tracciare i loro ordini. Non è ancora attivo, ma funziona ..

Sto affrontando un problema importante: come proteggerlo?

Negli ultimi giorni ho interrotto la codifica e sono costantemente stato impegnato a cercare sul Web, StackOverflow e Information Security su come farlo. Ho scoperto che il modo in cui Amazon protegge le loro API sarebbe la soluzione migliore per me. Il modo in cui Amazon protegge il suo servizio è spiegato qui . L'ho ottimizzato un po 'per il mio servizio:

L'utente registra e ottiene la chiave API privata + chiave pubblica (identificazione)
L'utente inserisce le credenziali e tocca "accedi". L'app crea hash delle variabili + chiave privata. L'app invia variabili + timestamp + hash + chiave pubblica all'API
API cerca la chiave pubblica nel database, trova la chiave privata che appartiene a quella chiave pubblica (se la chiave pubblica è valida). L'API crea quindi hash nello stesso modo in cui è stata eseguita l'app. Se gli hash sono uguali, viene eseguita la richiesta (accedi in questo caso).

Questo modo di garantire un servizio ha senso per me, e posso codificarlo per lo più. ma ho un grosso problema e non riesco a trovare alcuna soluzione:

L'utente ottiene un pubblico e amp; chiave API privata quando viene creato un account. La chiave pubblica può essere inviata dal server al dispositivo dell'utente, perché non è necessariamente un segreto. Dal momento che la chiave API privata può inviare mai tramite il cavo, come posso fare in modo che un account connesso sul dispositivo dell'utente conosca l'API privata chiave creata sul server?

Qualcuno sa come risolvere questo problema ?? qualsiasi aiuto sarebbe molto apprezzato !!

key-management key-exchange databases web-service

posta Joris416 09.12.2013 - 14:15

fonte

2 risposte

Leggi altre domande sui tag key-management key-exchange databases web-service

NFC utilizzato al posto dell'autenticazione a due fattori basata su smart card basata sui contatti OpenSSL EVP aes_256_cbc Dimensione vettoriale inizializzazione

score 1 · Answer 1

Perché vuoi che i client abbiano le loro chiavi private? Sto cercando di capire come dovrebbe funzionare il tuo scenario, ma sono un po 'confuso su quello che stai cercando di ottenere.

In generale, ecco alcuni commenti che possono aiutare:

HTTPS è come stabilire un canale di comunicazione sicuro con i clienti. Una volta fatto, puoi trasferire ciò che vuoi in modo sicuro tramite il client wire < - > server. Questa è la stessa cosa che fa la tua banca.
L'articolo a cui fai il link non dice nulla su HTTPS, sembra che abbia intenzione di inviarlo solo su HTTP. Dovresti utilizzare HTTPS non HTTP per tutto ciò che non vorresti fosse compromesso (come un utente che ha effettuato l'accesso). Perché provare a creare il proprio meccanismo di crittografia quando è possibile utilizzare HTTPS? Usare HTTP per qualsiasi tipo di autenticazione mi sembra un consiglio terribile.
Non sono sicuro che i tuoi clienti abbiano davvero bisogno della loro coppia di chiavi pubblica / privata. In genere è un server che protegge la comunicazione dell'applicazione e che ha un certificato con chiave privata. I client avranno ancora nome utente e password corretti? Questa è l'autenticazione per il tuo cliente (non un certificato) e puoi inviare l'utente / passarlo al server una volta stabilito un canale HTTPS sicuro. Lato server, l'app verificherà che le credenziali di accesso del client siano valide e forniscano al client un modo per dire "Sono già autenticato per 30 minuti" tramite un meccanismo cookie o di sessione. Ovviamente, una volta che un client ha effettuato l'accesso, la comunicazione deve continuare a verificarsi su HTTPS o il token / sessione di autenticazione potrebbe essere rubato.

In conclusione, se stai solo cercando di proteggere la comunicazione tra i client e un server, usa HTTPS e non reinventare la ruota.

score 0 · Answer 2

Sì, c'è una soluzione. Creare le chiavi pubbliche e private sul lato client. Quindi deve essere trasmessa solo la chiave pubblica del client, dal client al server. Il server ha una sua coppia di chiavi pubblica e privata, di cui condivide solo la chiave pubblica.

Lo schema che descrivi non dovrebbe richiedere che entrambe le parti abbiano copie della chiave pubblica e privata. Hai descritto uno schema di comunicazione simmetrica, in cui i dati trasmessi da e verso il server sono crittografati con la stessa coppia di chiavi pubblica-privata, ed entrambe le parti richiedono le chiavi pubbliche e private.

La soluzione è introdurre qualche asimmetria. Il client dovrebbe avere la chiave pubblica del server. Il server dovrebbe avere la chiave pubblica del client. Dovrebbero avere ciascuno la propria chiave privata. Se si desidera che il server possa utilizzare le stesse chiavi per tutti i client, oppure è possibile generare nuove chiavi del server per ciascun client. In ogni caso, non è necessario condividere le chiavi private.

Buona fortuna per la tua implementazione. Pubblica un commento per farci sapere se funziona!