Creazione di token personali per proteggere la comunicazione con la mia API

Naviga le tue risposte
1

Ho un'API che comunica con il mio cliente, ora voglio proteggere quell'API in modo che solo il mio cliente possa usarlo. Sto pensando di fare quanto segue, dal momento che non ho esperienza in questo ho raccolto tutto questo da una lettura sull'argomento e ho bisogno di un consiglio, ecco il mio flusso:

  1. Quando un utente accede / registra, genera un token (es: token = userId + date + radomvalue), salva questo token (hash) in un DBtable insieme a userId.
  2. Invia token (hash) al client, salva le preferenze per un uso futuro.
  3. Quando si chiama l'API questo token deve essere inviato con la richiesta, sul server, guardiamo attraverso la nostra tabella token e vediamo se troviamo la combinazione di userId + hashedToken, se lo facciamo, l'accesso è garantito.

Tutte le comunicazioni sono su SSL, ecco le mie domande:

  1. Che cosa devo fare per il TTL sui miei token? E cosa succede se ottengo 3 000 000 utenti, questo significa che ogni chiamata che faccio all'API deve guardare attraverso un tavolo con 3 000 000 di righe, ok?
  2. Ovviamente non posso fare in modo che i miei account di accesso / registro richiedano un token passato nella richiesta di accesso (dal momento che il client non ha ancora ottenuto), va bene lasciare questi "aperti"?
  3. Va bene inviare semplicemente testo + password ad api poiché è protetto da SSL, quindi cancellarlo sul lato server?

EDIT: 4. Pensandoci meglio, qualcuno non sarebbe in grado di afferrare il proprio token di accesso dal file delle preferenze e fare chiamate alla mia API dalla propria app, purché hanno l'endpoint e modificano ciò che vogliono sul proprio utente?

Modello di minaccia: sto costruendo un gioco. Ho un database in cui salvo classifica, esperienza e la versione del mio gioco (gratuita, senza pubblicità, premium). Dopo che qualcuno effettua un acquisto, chiamo endpointService.setVersion("userId", "PREMIUM") ;. Questa è l'unica risorsa ad alto valore reale per me, dal momento che non voglio che le persone lo modifichino da soli. Voglio solo proteggere i miei endpoint, ma soprattutto quello.

    
posta Green_qaue 13.03.2017 - 10:53
fonte

2 risposte

1

È possibile riutilizzare un meccanismo di autorizzazione, come OAuth2?

Il tuo cliente ottiene un token di accesso valido su richiesta (userID, segreto) che è firmato crittograficamente. L'app del tuo server può verificare questo token e potenzialmente trarne eventuali reclami; quindi non hai bisogno di cercarlo in un DB. Anche se vuoi esaminare qualcosa, dovresti esaminare i meccanismi di memorizzazione dei valori-chiave in memoria e i meccanismi di memorizzazione nella cache come Redis.

L'on-boarding (registrazione / accesso) sarà eseguito da un IdP, un provider di identità. Vedi come il sistema che esegue la verifica effettiva. Risponderà a un unico token al client; codificato e firmato. Finché la tua API si assicura che questo sia un token valido (firmato dal ragazzo giusto), allora dovresti essere bravo.

Is it okay to send plain-text salt+password to api since it is SSL-protected, then hash it on server-side?

Se salvi la tua password lato client, allora sostituisce semplicemente la password. A meno che qualcuno non faccia un MiTM (intercettazione del proxy, ...) e tu non registri il corpo della richiesta, ... SSL ti impedirebbe di intercettare. Se si utilizza la password o l'hash della password; un attaccante che lo catturi, manderebbe anche l'hash.

...Wouldn't someone just be able to grab their access token from the preference-file and make calls to my API from their own app

Sì, tutto ciò che è sul client non può essere considerato affidabile. Puoi provare a offuscarlo un po ', ma in sostanza, non puoi essere sicuro che sia stata la tua applicazione a inviarlo; e non un altro programma (da qualcuno che ha impiegato il tempo e gli sforzi per decodificarlo)

    
risposta data 14.03.2017 - 23:05
fonte
0

Come JosephSible ha menzionato, e hai accennato alla tua modifica, nel tuo commento, non controlli l'endpoint del cliente e possono fare tutto ciò che vogliono sul proprio sistema. Inoltre, dal momento che controllano il punto finale, SSL non farà nulla, dal momento che possono semplicemente leggere il token dalla memoria.

EDIT:

OK, ho appena visto la modifica del tuo modello di minaccia. Stai facendo una domanda diversa da quella in cui credo tu voglia chiedere. La mia risposta precedente affronta la tua domanda iniziale di "Come faccio a creare un sistema a cui solo i client autorizzati possono connettersi." Non è possibile. Quello che credo tu voglia dire è "Come faccio a impedire all'utente che non ha pagato le funzionalità di X di utilizzarle sul client?" Ci sono un paio di approcci, alcuni più efficaci di altri. La migliore risposta e l'unica efficace al 100% è fare tutto sul lato server. Esistono molti approcci diversi per proteggere il cliente, ma nessuno di questi è efficace al 100%. Se l'utente può aggiustare il client binario o crearne uno, possono aggirarlo.

Potresti voler leggere questo libro: link Parla abbastanza di come i giochi vengono interrotti da un punto di sicurezza.

    
risposta data 14.03.2017 - 14:59
fonte

Leggi altre domande sui tag

Qualunque pratico protocollo Single Sign-On (SSO) / strumento di analisi del traffico / metodo / analizzatore? [chiuso] DVWA - Comportamento dell'iniezione del comando dispari (alto)