Come chiamare webservice in modo sicuro in Android

È semplice. Non fidarti mai del cliente.

Non affidare mai la tua attività alla memorizzazione di segreti nel client che l'utente non dovrebbe conoscere.

Non importa se si tratta di Android, desktop o altro. A meno che tu non sia disposto a proteggere il tuo dispositivo come un bancomat (imbullonato su una parete in una cassastrong ponderata e telecamere tutt'intorno), il cliente non deve fidarsi. E anche se sei su un bancomat, non ti fidare ancora del dispositivo.

How to secure such that any attacker can't get anyhow my WEB API KEY which I defined in the strings.xml

Non puoi. Non è necessario.

Autentica per utente e per dispositivo. Gli utenti non devono condividere la stessa chiave API con nessun altro, la chiave API deve autenticare l'utente o la decisione dell'utente piuttosto che il client.

Se chiami un'API straniera (ad esempio Twitter) per la quale l'intera app ha un'unica chiave API, puoi:

• Condividi la tua chiave API nella tua app - un "segreto non segreto". È una situazione schifosa, e puoi in qualche modo offuscare la chiave. Ma se è lato client, non lo protegge. Fine della storia.
• Mantieni la tua chiave API sul tuo server e sulle chiamate API proxy. Assicurati che i tuoi client si autenticano sul tuo server, altrimenti il tuo server verrà abusato.

Se invece fornisce un'API che prevedi che i tuoi clienti possano chiamare nelle loro app mobili, allora ti viene in mente qualcosa di più sicuro. Una soluzione ideale è fornire agli implementatori una chiave chiave API, una chiave per generare chiavi per i singoli utenti, piuttosto che un solo segreto non segreto condiviso.

• Il modo migliore per farlo è creare una PKI. Si rilasciano certificati "trusted root" ai propri sviluppatori di app invece delle chiavi API. Quindi, a loro volta, utilizzano le proprie chiavi private per firmare i certificati utente, ognuno dei quali è valido per un singolo utente su una singola installazione. Questi possono essere certificati di sessione a breve termine (creati quando l'utente "accede" al servizio dello sviluppatore e validi solo per un breve periodo) o possono essere a lungo termine (creati quando l'utente installa l'app e validi per un a lungo). Ma fintanto che fai capire che lo sviluppatore è responsabile dell'abuso da parte di qualcuno dei suoi utenti e gli fornisce gli strumenti per proteggersi, puoi fargli scegliere quale di queste opzioni ha più senso.

• Un approccio concettualmente simile consiste nel prendere i componenti di una PKI e usarli separatamente. Si fornisce all'utente una "chiave sviluppatore", che poi utilizza per firmare "chiavi utente" utilizzando qualsiasi meccanismo noto, da complesso come le firme RSA a semplice come concatenare la chiave sviluppatore con una "chiave utente" casuale e troncare il risultato . Potrebbe essere più facile lavorare sul tuo flusso di lavoro, ma probabilmente è anche più facile sbagliare. Ma in ogni caso, è probabilmente più sicuro della semplice condivisione della chiave API degli sviluppatori con tutti i suoi utenti.