Che cosa fare quando non puoi proteggere le chiavi segrete dell'app per dispositivi mobili?

Penso di poterti aiutare a risolvere i tuoi dubbi.

So what are we trying to protect? We're trying to protect ourselves from an attacker breaking into user accounts via our web services. Specifically, how might we protect ourselves from an attacker sufficiently motivated to reverse-engineer our mobile app in the wild?

Non puoi. È così semplice. Cercare di fare l'impossibile è ciò che sta causando la tua preoccupazione. Invece, progetta e implementa il tuo server supponendo che il client possa essere la tua app o potrebbe essere un client malintenzionato sconosciuto. Se non riesci a proteggere la tua app con questi presupposti, dovrai acquistare nella spedizione un'app non sicura (probabilmente una cattiva scelta sbagliata) o avere solo clienti in posizioni in cui hai il controllo fisico (probabilmente anche una scelta sbagliata). / p>

Lasciatemi indirizzare alcune delle tue dichiarazioni specifiche:

I have to assume mobile banking apps have this figured out. But they are not so likely to share that knowledge here!

No. Questo è sbagliato. Non sono sicuro di chi pensi siano questi sviluppatori di app di mobile banking segrete, ma posso assicurarti che molti di questo sito hanno sviluppato applicazioni bancarie, mobili o altro, e hanno contribuito a proteggerli.

Our attacker can run a password list against us by spoofing our app's User Login web sequence. Since our attacker is able to observe HTTPS traffic as it exits the app, our attacker knows how to construct the web service request and authentication.

Assolutamente giusto. L'utente malintenzionato può eseguire un attacco con password a forza bruta sul server. Tecniche come blocco dell'account, ritardo esponenziale e CAPTCHA aiuterà a difendersi da questo.

We can encrypt the login (and other) information before it leaves the app. This should prevent both sniffing and spoofing, assuming our attacker does not possess the secret keys used in the encryption.

Given that inbound (to the server) traffic is more important to protect, Public Key encryption would be a possibility. Only the server could decrypt it.

Trust SSL. È ben testato e funziona bene. Non è necessario disporre della crittografia basata su app per proteggersi da un attacco MiTM . So che è strano collegare un proxy di debug come Fiddler e vedere il traffico presumibilmente crittografato in chiaro, ma non è davvero un problema di sicurezza. Sono i dati dell'utente, lasciali vedere se vogliono. E essendo il server è stato scritto con il concetto che non può mai sapere quale app è in esecuzione il client, il tuo protocollo dovrebbe essere in grado di sopportare l'esame da parte di un potenziale aggressore. Tieni presente che devi ancora eseguire correttamente la convalida SSL per impedire un attacco MiTM di terze parti.

Quindi ignorare la crittografia HMAC e quella lato client quando si utilizza SSL. Invece, scrivi un'API robusta e sicura. Non perché lo dico, ma perché non c'è alternativa. La tua analisi lo ha dimostrato.

EDIT:

Prevent our attacker from using our Web Services API to run a password list and potentially log in to a member account. We have other brute-force detection measures in place, but we'd like to directly secure our API from such attack.

Ho già menzionato i blocchi degli account anche se la guida OWASP sembra meno favorevole su di loro a causa del fatto che possono essere usato in un DOS. La menzione ha fatto ritardare la risposta su ripetuti tentativi falliti.

La guida continua dicendo:

Although brute-force attacks are difficult to stop completely, they are easy to detect because each failed login attempt records an HTTP 401 status code in your Web server logs. It is important to monitor your log files for brute-force attacks-in particular, the intermingled 200 status codes that mean the attacker found a valid password.

Mentre nessuno vuole che i propri utenti vengano hackerati, riconoscere e rispondere a un attacco con password di successo ridurrà drasticamente il costo dell'attacco. Il monitoraggio può anche consentire di bloccare (temporaneamente) gli indirizzi IP per terminare gli utenti malintenzionati (anche se un strong attacco probabilmente proviene da molti indirizzi IP che rendono questo difficile da fare).

L'autenticazione a due fattori riduce l'impatto di una password rubata.

Prevent our attacker from using our Web Services API to probe our server for other attack possibilities.

Scusa ma non puoi farlo senza la sicurezza fisica. Puoi incorporare i segreti nella tua app, offuscarla, ecc ... ma nulla di tutto ciò rende l'app più sicura, ma aumenta il costo di un attacco in quanto questi possono essere modificati all'indietro. Quindi, sia che applichi queste strategie o no, devi comunque progettare la tua API come se un utente malintenzionato avesse accesso ai tuoi segreti e codice.

Sono un grande fan di entrambi SAST e DAST . Esegui analisi statiche e risolvi tutti i problemi critici / critici prima di ogni implementazione. Lo stesso per una scansione dinamica. Gli scanner di vulnerabilità possono anche controllare il tuo sito per vulnerabilità note e cattiva configurazione.

Il tuo problema non ha ancora molto senso.

Sembra che tu stia cercando di proteggere gli account utente dall'enumerazione e dalle password di forzatura brute. Questo non ha nulla a che fare con il tuo cliente.

Per proteggersi dagli attacchi con password brute-force, vedi link

Per proteggere contro l'enumerazione del nome utente, restituire lo stesso messaggio di "successo" indipendentemente dal fatto che il nome utente esista o meno per la reimpostazione della registrazione o della password.

Indica chiaramente il vero problema che vuoi risolvere, senza offrire soluzioni potenziali e possiamo aiutarti a migliorare.

Il tuo aggressore è in grado di fiutare il traffico dell'app perché deve utilizzare qualche strumento proxy come il violinista. Questo non è un problema con la tua applicazione. Questo è il modo in cui funzionano questi strumenti proxy. Come sviluppatore di app dovresti saperlo e dovresti anche implementare i controlli di sicurezza di conseguenza. Se vuoi evitare questo, potresti voler utilizzare il blocco dei certificati ma non è nemmeno infallibile. Dovresti sempre assumere uno scenario peggiore e sviluppare il tuo codice. Metti tutti i controlli di sicurezza e la logica aziendale su Server Side e non memorizzare alcuna informazione sensibile sul lato client.

Il blocco dei certificati è un altro controllo comunemente utilizzato contro gli attacchi Data-in-transit. L'handshake TLS non si avvia mai se il client non riceve una chiave pubblica all'interno dell'elenco dei pin noti del client (l'app mobile).

Ho usato Cert Pinning come complimento per la crittografia del payload. Forse quanto segue sta diventando lo standard di base per i dati sensibili delle app per dispositivi mobili? Sembra che Tweets e Facebook Status Updates li usino tutti e tre:

1. Blocco del certificato
2. Codifica payload
3. TLS

Tutti questi sono possono essere sconfitti. Ma non siamo in un gioco di livelli di difesa e ampli? rallentare l'aggressore?

Hai riassunto perfettamente il problema; come fai a sapere che l'app mobile è lì? Potrebbe essere uno strumento come Postman o Paw che automatizza le richieste. Che sconfigge tutto se è nota la chiave segreta Payload Encryption.