Protezione di un'API privata utilizzata da un'app iOS

3

Ho un'app che utilizza un server API e non voglio avere altro che essere in grado di usare quell'API. So che questo non è del tutto possibile, ma voglio fare quello che posso.

Non penso che il mio attuale metodo per ottenere questo risultato sia il più grande e mi piacerebbe recuperarlo e ricominciare da capo. Ecco come funziona:

  1. L'app preleva una stringa da un set che chiamerò "entropia".
  2. Usando quella stringa fa un hash della data UTC corrente usando l'entropia come sale
  3. Invia quell'hash al server API che crea l'hash utilizzando ogni possibile entropia dal set fino a quando trova una corrispondenza
  4. Se trova una corrispondenza, viene generata una chiave API per l'app e restituita.

Il server memorizza la stringa entropy, la chiave API, così come IDFV in un database.

Quando l'app effettua una richiesta, invia la propria chiave API, IDFV e un token al portatore. Il token bearer è un hash dell'URL con la stringa entropy come salt.

Quando il server riceve una richiesta:

  1. Seleziona la stringa entropy dal database utilizzando la chiave API e IDFV come parametri di ricerca.
  2. Genera il proprio portatore usando l'URL a cui risponde e l'entryopy da quanto sopra seleziona.
  3. Verifica che le stringhe di entropia corrispondano

Se la query select non restituisce nulla, o se i portatori non corrispondono, il server restituirà un 403 e non procederà.

I problemi di cui sono preoccupato sono:

  • Se l'utente ha una data errata sul proprio dispositivo, la registrazione fallirà. Allo stesso modo,
  • Se il server ha una data errata, la registrazione fallirà
  • Se l'app inizia la registrazione alle 23:59:59 e c'è un ritardo di 1 secondo sul server (che su 3G è del tutto plausibile), la registrazione fallirà
  • Con un elenco codificato di stringhe entropiche, l'app può essere decompilata e le stringhe estratte
  • Con solo un numero limitato di stringhe entropiche è possibile trovarle tutte con un tempo sufficiente.

Alcune delle cose che ho preso in considerazione:

  • Tutte le richieste e le risposte vengono pubblicate su HTTPS
  • Il server API limita le richieste per ostacolare i tentativi di forza bruta
  • Il server API è dietro a CloudFlare per fare anche una prevenzione di attacco di base.

Quello che voglio sapere è quale sarebbe un modo migliore per fare ciò che non richiede alcuna interazione utente aggiuntiva? L'app per iOS è costruita usando Objective-C e il server API è costruito usando Ruby.

    
posta ecnepsnai 31.07.2015 - 21:32
fonte

1 risposta

1

L'associazione OAuth può essere una buona alternativa. Ad esempio:

During the initial login, the device is uniquely identified and paired with the mobile user's account using the OAuth 2.0 protocol (http://tools.ietf.org/html/rfc6749). All requests to the Salesforce service are made using the OAuth token established through the pairing created during activation. After initial login, there is no exchange of a password in the communication between the mobile client and the Salesforce server. For this reason, the Salesforce password is not stored on the device and is not required even when the password is changed or has expired.

Che utilizza il seguente processo:

Use a refresh token for apps that don't have access to the private key, such as mobile apps. A third-party system can generate the refresh token using the private key and provide it to the mobile app. The app then uses the refresh token to generate an access token

Riguardo agli identificatori, non utilizzare IMEI o UDID poiché sono condivisi con altre app. In alternativa:

We recommend that developers avoid using any device-provided identifier to identify the device, especially if it's integral to an implementation of device authentication. Instead, we recommend the creation of an app-unique "device factor" at the time of registration, installation, or first execution. This app-unique device factor in combination with user authentication can then be required to create a session. The device factor could also be used as an additional factor in an encryption routine.

Riferimenti

risposta data 25.08.2018 - 20:36
fonte

Leggi altre domande sui tag