Concetto di sicurezza per app Android con API REST basata su PHP

Question

Concetto di sicurezza per app Android con API REST basata su PHP

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

6

Sto provando a costruire il mio REST Api basato su PHP per la mia app per Android e sono un po 'confuso da tutte le diverse funzionalità di autenticazione degli utenti che si possono trovare su Internet. Quindi voglio presentare le mie considerazioni sulla sicurezza e sarei lieto di alcuni feedback.

In primo luogo, voglio chiarire che non voglio creare un'API pubblica in cui terze parti possano registrarsi per una chiave API, ma voglio solo che gli utenti della mia app possano fare tutto il registro / login / invio di richieste roba. Quindi i miei piani sono i seguenti:

Quando un utente vuole registrarsi, la mia app scambia prima chiavi generate con il mio server usando il metodo Diffie-Hellman. Per questo, il mio server e la mia app memorizzano le informazioni sullo stesso numero primo e sulla stessa base (spesso chiamate p e g). La mia app genera quindi un segreto e crea una chiave pubblica da p, ge il segreto. La chiave pubblica viene inviata al server, che risponde inviando un ID utente nel formato UUID Java e la chiave pubblica del server in base al segreto del server, p e g. Alla fine, entrambe le parti sono in grado di generare un segreto comune. L'intera transazione viene eseguita utilizzando TSL / SSL e può essere visualizzata qui . Invece del numero intero, piuttosto lungo segreto, un hash SHA-512 è memorizzato nel database e nell'app.
Dopo aver scambiato la chiave, ora posso inviare le informazioni dell'account dell'utente (userid, password e altre cose) al server usando TSL / SSL. Il segreto dell'app viene utilizzato per HMAC assicurandosi che l'istanza dell'app (l'utente) sia autorizzata a inviarmi questa roba. Posso verificarlo mentre memorizzo il hash segreto SHA-512 e l'userid nel database. La password deve essere trasmessa per poter accedere nuovamente se l'utente si è disconnesso o desidera modificare la sua password. La password viene cancellata con follwowing queste istruzioni. Dopo l'accesso, un token di accesso casuale viene restituito all'utente che rappresenta il suo stato di accesso. Questo token di accesso è anche memorizzato nel database.
Invece di inviare le credenziali dell'utente ad ogni richiesta, il token di accesso viene utilizzato come credenziali di accesso e il segreto generato nel primo passaggio viene utilizzato per eseguire HMAC. Quindi, se ottengo una richiesta, posso prima verificare se l'utente è autorizzato a inviarmi una richiesta eseguendo l'autenticazione del messaggio con HMAC e quindi posso verificare se l'utente è loggato confrontando il token di accesso trasmesso con quello memorizzato nel Banca dati. Questa transazione può anche essere eseguita con TSL / SSL ma non è necessario.

È un concetto valido o manca di alcuni punti cruciali, contiene incomprensioni o c'è qualche altro tipo di problema?

php rest authentication android

posta zersaegen 29.07.2014 - 13:59

fonte

2 risposte

Leggi altre domande sui tag php rest authentication android

Meriti relativi di Heimdal e del MIT Kerberos? Posso chiedere ai server di chiavi GPG di nominare tutte le chiavi firmate da una particolare chiave?

score 2 · Answer 1

Questo sistema di sicurezza proposto è vulnerabile a CWE-602: applicazione lato client della sicurezza lato server e non limita la capacità di un utente malintenzionato di accedere a questa API RESTful. Fondamentalmente, qualsiasi segreto fornito all'app mobile sarà conosciuto dall'attaccante. Un utente malintenzionato con un telefono in prigione può osservare la memoria utilizzata da qualsiasi processo in esecuzione.

È deve essere presume che un utente malintenzionato abbia pieno accesso alla tua API. Qualsiasi funzionalità fornita al client è per definizione accessibile dagli hacker e deve essere sottoposta a una verifica della sicurezza. Un buon punto di partenza è cercare i problemi trovati su OWASP top 10 .

score 0 · Answer 2

Non proprio una descrizione dettagliata, ma da quello che ho capito, ho alcune domande:)

Nel passaggio 1: lo scambio di chiavi Diffie-Hellman è vulnerabile a un attacco man-in-the-middle. Anche se è in esecuzione all'interno di una connessione protetta TLS / SSL. L'unico modo per evitarlo è usare i certificati PKI.

Nel passaggio 2: come pensi di riciclare il token sicuro. Intendo per quanto tempo è valido per l'autenticazione? Sono sicuro che ci hai pensato. REST è senza stato, quindi, non sono sicuro di cosa intendi per login / logout. Non hai sessioni da convalidare. Penso che il token dovrebbe essere valido per una finestra temporale specifica.

Nel Passaggio 3: se la connessione non è protetta da TLS / SSL, come prevedi di impedire a qualcuno di intercettare la connessione di ottenere il token sicuro e utilizzarlo per accedere alle tue API RESTFul ??