Un'alternativa stateless semplicistica all'autenticazione di base HTTP per le API

Naviga le tue risposte
2

Molte API (servizi) oggi utilizzano OAuth, l'autenticazione di base HTTP o le chiavi API per autenticare i loro utenti.

Il mio obiettivo è trovare un modo semplicistico sicuro per autenticare gli utenti in un'applicazione client-side in un stateless modo per un servizio .

Metodi di autenticazione

Ecco la mia vista su alcuni dei metodi di autenticazione:

  1. OAuth sembra un'ottima soluzione, ma sembra molto complicato per l'impostazione e sembra eccessivo per un solo servizio.

  2. In base a OWASP " l'autenticazione di base HTTP non è sicura e non dovrebbe essere usato nelle applicazioni ".

  3. L'utilizzo di semplici chiavi API in un'applicazione web lato client non lo fa sembra un miglioramento rispetto all'autenticazione di base HTTP.

Utilizzo di token crittografati

La mia idea alternativa è di utilizzare token crittografati che possono essere verificati dal servizio.

  1. Il testo in chiaro del token conterrà il nome utente , password & la data di scadenza del token.

  2. Il testo in chiaro verrà crittografato usando a chiave segreta che è conosciuta solo dal server.

  3. Il testo in chiaro sarà crittografato sul server utilizzando AES in modalità GCM , in modo che l'integrità non possa essere manipolata.

L'utente deve accedere con il proprio nome utente e password per ricevere un token . Questo token è inviato su ogni richiesta e può essere verificato sul server.

Per illustrare: 

+----------+                                          +-----------+
|          +------      Login with user:pass     ---->+           |
|  Client  |                                          |    API    |
|          +<----       Send encrypted token      ----|           |
|          |                                          |           |
|          +------    Use token to authenticate  ---->+           |
+----------+                                          +-----------+

Verifica

La verifica può essere effettuata da:

  1. Decrittografa il token utilizzando la chiave segreta .
  2. Verifica nome utente e password .
  3. Verifica se il token è scaduto .

della Pro

Possibili pro di questo approccio:

  1. I token possono essere memorizzati in localStorage per mitigarli dagli attacchi CSRF e gli utenti sono in grado di disconnettersi cancellando il localStorage.
  2. Le informazioni di accesso in testo normale non vengono inviate su ogni richiesta.
  3. I token possono scadere.

Contro

Possibili contro di questo approccio:

  1. Più carico sul server decifrando ogni richiesta.
  2. Un token è associato a un server specifico.

Quale pensi sia una buona soluzione? Conosci altre buone alternative?

    
posta swordsecurity 20.06.2018 - 14:17
fonte

1 risposta

4

La tua soluzione proposta è quasi identica a JSON Web Tokens (JWT), che sono precisamente quella:

  • Un token stateless contenente informazioni sull'utente
  • Firmato e / o crittografato tramite chiave segreta condivisa o asimmetrica
  • Contrassegnato con un timestamp di scadenza

Vedi link per ulteriori informazioni. Sarai molto ben servito usando questo standard piuttosto che rotolare il tuo, poiché esistono già molte librerie ben collaudate per gestire questi token.

Si noti che in genere non è necessario memorizzare la password nel token, poiché il fatto che sia stato crittografato o firmato con la propria chiave privata dimostra che è stato creato dalla routine di autenticazione. Ciò offre l'importante vantaggio che è possibile avere un servizio di autenticazione completamente separato, che verifica le password e genera token, mentre l'applicazione principale sa solo come leggere i token.

Per quanto riguarda la legatura di cose ad un particolare server, puoi gestire più server in due modi:

  • Utilizza la crittografia simmetrica, con lo stesso segreto condiviso installato su tutti i tuoi server, ma ancora impossibile da scoprire per chiunque altro.
  • Utilizza la crittografia asimmetrica e genera una chiave privata diversa su ciascun server che deve creare token e distribuire le chiavi pubbliche corrispondenti a ciascun server che deve leggere token .
risposta data 20.06.2018 - 14:30
fonte

Leggi altre domande sui tag

In che modo i gestori di password implementano l'integrazione sicura del browser? [chiuso] Il tracciamento della sessione utente-agente fornisce vantaggi?