it-swarm-eu.dev

Sicurezza per REST api (user / pass auth vs hmac vs oauth)

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

Ecco cosa ho in mente:

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

Vorrei sapere se sembra abbastanza sicuro o se c'è qualcosa che avrei potuto trascurare? Ci sono dei vantaggi che HMAC o OAuth offrono su questo approccio?

15
Abhinav Kaushik

HMAC è un algoritmo crittografico che ha senso come parte di protocolli più grandi; non dovresti giocherellare direttamente con esso. 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 possa avere credenziali (a big word per "password") noto a un singolo server, che può essere utilizzato per ottenere l'accesso da diversi altri server senza fidarsi di loro abbastanza da mostrare loro la password effettiva. Dire, server [~ # ~] s [~ # ~] e [~ # ~] t [~ # ~] server di autenticazione trust [~ # ~] a [~ # ~] , user [~ # ~] u [~ # ~] si fida anche di [~ # ~] un [~ # ~] abbastanza per mostrargli la sua password (all'interno di una connessione HTTPS) e [~ # ~] s [~ # ~] e [~ # ~] t [~ # ~] parla con [~ # ~ ] a [~ # ~] per assicurarsi che l'utente [~ # ~] u [~ # ~] sia effettivamente chi afferma di essere; la parte bella è che [~ # ~] s [~ # ~] e [~ # ~] t [~ # ~] non vedere mai la password e [~ # ~] u [~ # ~] non ha bisogno di fidarsi di .

Nel tuo caso, hai un solo "utente" (il tuo server [~ # ~] h [~ # ~] ) e poiché si tratta di una macchina, non è necessario essere pignoli la sua password; [~ # ~] h [~ # ~] può avere una "password" (una lunga sequenza di caratteri casuali) che [~ # ~] h [~ # ~] utilizzerà solo per l'autenticazione con [~ # ~] o [~ # ~] , quindi non è necessaria la complessità aggiuntiva di OAuth.

La vulnerabilità intrinseca qui è che il server [~ # ~] h [~ # ~] ha accesso ai dati sensibili. È 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 sbirciare i tuoi dati o perderli attraverso la negligenza. Non puoi eluderlo, come da definizione del tuo problema. Fondamentalmente consideri il server [~ # ~] h [~ # ~] sicuro, da solo, da intercettazioni e alterazioni ostili. In queste condizioni, l'autenticazione "Basic" di HTTP eseguita in HTTPS andrà bene .

Potresti voler stringere un po 'l'autenticazione del server: machine [~ # ~] h [~ # ~] dovrà assicurarti che parli con il vero [~ # ~] o [~ # ~] server, che normalmente comporta la convalida del certificato. Puoi configurare [~ # ~] h [~ # ~] per creare "fiducia diretta", ovvero 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 nessun altro. Ciò può evitare problemi con le autorità di certificazione e, in particolare, consente un utilizzo sicuro dei certificati autofirmati, che sono economici (poiché non è necessario pagare una CA per tale certificato).

15
Tom Leek