Sicurezza per REST API (utente / pass auth vs hmac vs oauth)

14

Ho due server (uno su Hetzner (lo chiamo H) e l'altro nel mio ufficio (chiamandolo O)). Ho bisogno di eseguire un servizio web CRUD di base su O e l'unico consumatore del servizio è H. Dati su O sono dati utente sensibili. Questo è un servizio temporaneo su nastro che andrà via in futuro insieme alla necessità del server O.

Ecco quello che ho in mente:

  1. Il servizio verrà eseguito su https
  2. Autenticazione HTTP di base per l'autenticazione delle richieste
  3. Apertura della porta su O solo per ip di H tramite iptables.

Mi piacerebbe sapere se sembra abbastanza sicuro o se c'è qualcosa che potrei aver trascurato? Ci sono dei vantaggi che HMAC o OAuth offrono rispetto a questo approccio?

    
posta Abhinav Kaushik 30.07.2013 - 15:01
fonte

1 risposta

15

HMAC è un algoritmo crittografico che ha senso come parte di protocolli più grandi; non dovresti giocherellare direttamente con lui. Quando si utilizza HTTPS, il livello SSL include effettivamente alcuni HMAC (tra gli altri algoritmi).

OAuth è uno standard per l'autorizzazione il cui caso d'uso principale è la gestione dell'autenticazione degli utenti senza condividere le credenziali - l'idea è che un utente può avere credenziali (una parola grossa per "password") noto a un singolo server, che può essere usato per concedere l'accesso da diversi altri server senza fidarsi di loro abbastanza per mostrare loro la password effettiva. Supponiamo che i server S e T server di autenticazione attendibile A , l'utente U si fidi anche di A basta mostrare la sua password (all'interno di una connessione HTTPS), e S e T parlare con A per assicurarsi che l'utente U è in effetti chi sostiene di essere; la parte bella è che S e T non vedono mai la password e U non deve fidarsi di loro .

Nel tuo caso, hai un singolo "utente" (il tuo server H ) e dal momento che è una macchina, non deve essere pignolo riguardo alla sua password; H può avere una "password" (una lunga sequenza di caratteri casuali) che H userà solo per autenticare con O , quindi non c'è serve per la complessità extra di OAuth.

La vulnerabilità intrinseca qui è che il server H ha accesso ai dati sensibili. Questo è in base alla progettazione, ma ciò significa che i dati arrivano a un server ospitato, il che implica che ti fidi del servizio di hosting per non dare una sbirciata ai tuoi dati o perderli attraverso l'incuria. Non puoi eluderlo, come da definizione del tuo problema. Praticamente consideri il server H come sicuro, da solo, da alterne e alterazioni ostili. In queste condizioni, l'autenticazione HTTP "Basic" eseguita in HTTPS andrà bene .

Potresti stringere un po 'di autenticazione del server: la macchina H dovrà accertarsi che parli con il vero O server, che normalmente implica la convalida del certificato. Puoi configurare H per rendere "trust diretto", cioè importare in H una copia del certificato O (solo il certificato pubblico, non la chiave privata) e istruendo H a fidarsi di quel certificato specifico e di nessun altro. Ciò potrebbe evitare problemi con le Autorità di certificazione e, in particolare, consentire un uso sicuro dei certificati autofirmati, che sono economici (dal momento che non devi pagare una CA per tale certificato).

    
risposta data 30.07.2013 - 15:17
fonte

Leggi altre domande sui tag