Protocollo chiave-accordo in un'API REST

La tua soluzione si basa sul presupposto che il reverse engineering di un'app offuscata sia difficile. Tuttavia, questa ipotesi non corrisponde all'esperienza. Pertanto, non si può davvero dire che la soluzione sia buona .

Tuttavia, forse la soluzione è la migliore che si possa fare (non la stessa cosa di "buono"). L'alternativa è l'autenticazione dell'utente. Vale a dire, ogni app istanza otterrebbe la propria chiave di autenticazione; quindi, spetta al server accettare una chiave o rifiutarla. Questo ti dà la possibilità di revocare una chiave che sembra essere stata decodificata; potrebbe anche darti una leva legale per perseguire i trasgressori.

Se persegui il concetto di generare una chiave basata sul tempo nell'app, fallo almeno con gli strumenti crittografici appropriati. In questo caso, utilizza HMAC : codifica l'ora corrente in alcuni byte, quindi calcola HMAC / SHA-1 (o HMAC / SHA-256, a seconda di quale sia il più semplice per te) su questi byte, utilizzando una chiave hardcoded. La chiave hardcoded è l'obiettivo per il reverse engineering. L'uso di HMAC almeno ti proteggerà dalla ricostruzione delle chiavi mediante l'analisi dell'output: l'utente malintenzionato dovrà davvero eseguire un effettivo smontaggio del codice. Avrai anche bisogno che l'app invii la sua nozione di "ora corrente" come parametro aggiuntivo, perché non puoi fare affidamento sul fatto che il dispositivo client sia ben sincronizzato.

(Nessuno di questi è esclusivo con l'esecuzione dell'intero contenuto in HTTPS, che di solito è una buona idea quando la sicurezza conta, ma qui è davvero un altro argomento.)

• Innanzitutto, utilizza https (SSL / TLS)
• In secondo luogo, puoi avere attacchi di riproduzione link

Penso che sia necessario utilizzare un metodo di autenticazione e autorizzazione più robusto. Perché è la tua API che non ti serve oauth.

Prova una di queste opzioni, tutte dipendono dal livello di sicurezza di cui hai bisogno.

• HTTP Basic + TLS (con le chiavi invece delle password)
• Application-only-auth link
• Amazon Signature Version 4 link

Per me sembra come sviluppare il tuo algoritmo cryto. È possibile aggirare "alcuni" offuscando il codice Android, ma qualsiasi analisi dinamica del codice può in qualche modo rivelare la casualità della chiave. Inoltre, le chiavi nella richiesta GET possono essere semplicemente intercettate utilizzando il proxy intermedio (anche all'interno di SSL / TLS, il proxy intermedio può essere una CA valida sul dispositivo)

Non riesco a pensare a nulla che possa fermare qualcun altro per falsificare la richiesta e replicarla da un computer desktop. Tuttavia, per rendere la cosa più difficile per qualcuno che vuole accedere all'API limita direttamente il numero di richieste per sessione autenticata che è la migliore vittoria.

Sembra che una persona motivata possa determinare la chiave se lo desidera.

È possibile inviare una chiave univoca insieme a ciascuna istanza dell'applicazione quando viene scaricata? Un GUID o un UUID potrebbe essere utile per questo e sarebbe molto più difficile da prevedere. Quando qualcuno ha scaricato l'applicazione, invierai quella chiave insieme all'istanza e poi la inserirai in un database che controlli.

Quindi, quando una richiesta viene inviata, puoi confermare che esiste nel database. Ciò consentirebbe anche di tenere traccia del numero di richieste provenienti da una chiave specifica.

Con l'originale, un modo per identificare se il codice è stato compromesso. Ad esempio se hai 100 utenti e ricevi 1000 richieste al giorno e poi risparmierà fino a 1100 richieste al giorno che probabilmente sembrerebbero normali. Se identifichi il numero di richieste da ciascuna chiave, puoi vedere che normalmente ricevi 10 richieste al giorno da ciascuna delle tue chiavi, ma se salta a 1100 richieste e un singolo utente passa da 10 a 110 richieste, puoi probabilmente dire quella chiave quella è stata compromessa e la disabilita.