Accesso API sicuro su SSL utilizzando token oauth

1

Sul progetto che sto attualmente lavorando, autenticiamo il clienti per username e password. In questo sistema ogni utente ha una chiave calcolata dalla sua password.

Tuttavia, vogliamo fornire un accesso API per gli utenti dove saranno autenticato con un token 2.0 di giuramento. Quindi il problema che sto affrontando è che abbiamo bisogno della password per il calcolo della chiave e vogliamo evitare all'utente di codificare la sua password. Quindi, quello a cui abbiamo pensato è che quando l'utente richiede il token e il server crittografa e firma la chiave utente e la invia all'utente insieme al token. Ad ogni richiesta API l'utente deve inviare entrambi! Considerando che tutte le comunicazioni vengono eseguite tramite HTTPS, c'è sempre la possibilità che ci sia un attacco sul lato client in cui l'attaccante può catturare sia la chiave crittografata che il token e riprodurli utilizzando le stesse chiamate API!

La soluzione che mi è venuta in mente è la seguente:

La chiave crittografata dovrebbe contenere una data di scadenza (questa data dovrebbe essere inclusa anche nella firma)! Il problema che rimane qui è che come stiamo andando ad aggiornare la chiave crittografata se assumiamo che l'utente non si connette per un lungo periodo. D'altra parte per non-ripudio e replay la prevenzione degli attacchi, chiediamo la firma sul lato client (usando HMAC o RSA) sul token e la password crittografata!

Quindi la mia domanda qui è che se chiedere all'utente di firmare il token e la password crittografata è troppo e inutile.

Grazie

    
posta sgres 17.09.2013 - 16:00
fonte

1 risposta

1

Se il back-end richiede la password in testo semplice, perché non memorizzare la password su un server proxy API sicuro?

  client --- oauth---> [Data Center] ---> HTTP/S ---> App that caches passwords ---> backend

Esistono molti modi per eseguire OAuth 2.0 e suggerirei di utilizzare il token normale che include già campi di scadenza, ambito e firma.

Usa l'ID utente verificato che viene dal token OAuth per dettare al tuo proxy sul back-end le chiamate da effettuare.

Nella mia mente, questa architettura centralizza la sicurezza, riduce la complessità e consente una migliore testabilità.

    
risposta data 17.09.2013 - 17:08
fonte