App nativa, autenticazione token senza login / password

Qual è il tuo modello di minaccia?

Se ogni connessione viene inviata tramite SSL, non è necessario preoccuparsi di qualcuno che annusa le tue comunicazioni. Questa è in realtà la parte più strong del tuo sistema. Buon lavoro scegliendo qualcosa di standard.

Poiché SSL garantisce che nessuno stia ascoltando le tue comunicazioni, dovremmo esaminare gli endpoint. Il tuo UUID è fondamentalmente un segreto condiviso. Chiunque abbia questo UUID sarà in grado di imitare i tuoi utenti.

Per quanto riguarda criptarlo o cancellarlo, no. Non si disturbi. Se hanno accesso al tuo UUID crittografato, hanno certamente accesso al codice sorgente per il tuo gioco, che dovrebbe contenere la password. Tutto ciò che potrebbe impedire all'autore di un attacco di autenticare anche impedirebbe l'autenticazione da parte del cliente.

Devi sviluppare un modello di minaccia. Cosa farebbe un aggressore se riuscissero a mettere le mani su un UUID? Se tutto ciò che possono fare è negli acquisti di giochi per quell'account, allora c'è poco da guadagnare dall'avere un UUID. Potrebbero provare a far incazzare un cliente rubando l'UUID e usandolo per comprare un sacco di cose che il cliente non voleva, ma se si è in grado di rimborsarlo, allora non possono nemmeno incazzare un cliente.

D'altra parte, se gli UUID possono essere usati per acquistare cose che sono utili per gli altri, allora hai più incentivo per gli attaccanti a rubarli. Se possono essere utili alla mafia, allora hai una minaccia ancora più grande, perché potrebbero lanciare una delle loro botnet sul tuo sistema.

Tutta la sicurezza è basata su un modello di minaccia. Niente è perfettamente sicuro. Come disse una volta Kevin Mitnick: "L'unico computer completamente sicuro è uno che è disconnesso da Internet, spento, incassato nel cemento in fondo a un silos sorvegliato da guardie armate. Anche allora, lo controllerei una volta in un mentre ".

This UUID is stored in the device (should i crypt or hash it ?) :

• Per l'applicazione Android puoi utilizzare questa libreria , che è un wrapper crittografato per SharedPreferences, perché SharedPreferences su Android memorizza i dati in "testo normale", quindi un attacker può facilmente avere accesso a questi dati.
• Per l'applicazione iOS: Keychain è un luogo sicuro di memorizzare credenziali e sensibili informazioni, ma non è difficile vieni dentro ( specialmente sul dispositivo jailbroken).

When the user start the game i authenticate him with a token (UUID+timestamp+hmac(sha256, username+timestamp, K)). Is it better to generate a temporary session token (stored in the database) or could i use the previous token for all the requests after authentication?

Il token di accesso deve essere gestito sul lato server, perché può essere modificato sul lato client (ad esempio: un utente malintenzionato può modificare il valore del timestamp corrente del dispositivo) e i token di accesso sono generalmente temporanei, quindi devi aggiornarli dopo un determinato periodo di tempo a seconda della criticità della tua applicazione.