Protezione dell'API REST con HMAC e autenticazione di base

Question

Protezione dell'API REST con HMAC e autenticazione di base

#1 da (5 voti)
#2 da (4 voti)
#3 da (0 voti)

0

Mi chiedevo se offrire agli utenti la scelta di un metodo per proteggere il loro accesso all'API sarebbe una buona idea.

Sfondo:

Stiamo creando e implementando applicazioni per i nostri clienti, che li aiutano a svolgere il loro lavoro in modo più efficiente. Ciascuno dei nostri clienti sta eseguendo un'applicazione autonoma e abbiamo in programma di creare un'API che consentirà loro di integrare i propri strumenti di terze parti o quello che hai. Non sarà un'API pubblica ma privata.

Ora, durante le ricerche sull'argomento, sono giunto alla conclusione che l'utilizzo dell'autenticazione di base, anche tramite HTTPS, non è una buona idea. Apparentemente, il metodo preferito sarebbe utilizzare HMAC con nonces. Io sono tutto per assicurare il strong, tuttavia la soluzione HMAC presenta un problema: è più complicato e richiede che lo sviluppatore crei prima HMAC e poi lo inserisca in una richiesta, fondamentalmente rendendo l'intera API non facilmente individuabile (come non puoi semplicemente digitare curl https://my.url/api/endpoint/ e vedi cosa succede).

Mi viene in mente che gli utenti di Stripe utilizzano l'autenticazione di base con token come utente, pertanto la richiesta di ricciolo è simile a questa: curl -u sk_test_mysecretrandomkeywhatever https://my.url/api/endpoint/

Questo è il mio libro è un grande vantaggio e se è abbastanza buono per la società di elaborazione dei pagamenti, allora forse andrà bene anche per noi?

Poi ho pensato: e se offrissimo entrambi una scelta? Vuoi utilizzare solo l'autenticazione di base? Bene, puoi usare solo quello. Uno dei tuoi clienti è un maniaco della sicurezza e vuole assicurarsi che il tuo sistema sia sicuro? Abilita l'autenticazione HMAC e inizia a giocare con HMAC, ecc. È una soluzione fattibile o diresti che è una farsa di sicurezza?

Per favore, fai un po 'di luce sull'argomento o almeno indirizzami nella giusta direzione.

api authentication hmac

posta RandomWhiteTrash 02.09.2015 - 08:10

fonte

3 risposte

Leggi altre domande sui tag api authentication hmac

Dato un indirizzo IP puoi ssh in / tmp senza password? Gmail chiuderà il mio account botnet ben intenzionato? [chiuso]

score 5 · Answer 1

Non è chiaro per me quale tipo di problema stai cercando di risolvere e potrebbe anche non essere chiaro per te. Se hai un'idea chiara di ciò che stai cercando di ottenere con l'autenticazione, non avresti bisogno di offrire al cliente più schemi di autenticazione, ma segui quello che risolve il tuo problema.

Se temete un compromesso delle credenziali di autenticazione perché la connessione potrebbe essere annusata, usate semplicemente TLS. In questo caso l'autenticazione di base, i cookie di sessione o le autentiche "clear text" simili offrono una protezione sufficiente poiché il segreto è protetto durante il trasferimento.

Se TLS non è possibile, potresti utilizzare i metodi di risposta alle sfide in cui hai una chiave segreta pre-condivisa. Questo protegge l'autenticazione ma non protegge dal dirottamento della connessione, ad esempio un uomo nel mezzo potrebbe passare l'autenticazione e quindi modificare qualsiasi azione eseguita all'interno della connessione autenticata. Con l'uso corretto di TLS questo non sarebbe un problema, ma potreste anche usare metodi di autenticazione più semplici.

Esistono altri metodi di autenticazione (come l'autenticazione TLS reciproca), ma ti consiglio innanzitutto di determinare cosa deve essere protetto e quale tipo di abuso vuoi proteggere. Una volta eseguita questa operazione, puoi selezionare dai metodi esistenti quello che corrisponde meglio al tuo problema.

score 4 · Answer 2

L'arricciatura con l'autenticazione di base è accettabile - ricorda che la sintassi è sintetica - nome utente: password https://yoursite.com e questo significa che dovrai inserire le credenziali del codice nel codice che richiama l'API REST, in genere se è Ajax - quindi stiamo parlando di codice lato client e questo significa esporre le credenziali nel browser (o in un'app mobile) che è una vulnerabilità.

Penso che tu possa migliorare con un approccio in 2 passaggi che è una pratica abbastanza comune:

Quando l'utente effettua il login (app o browser) - ottiene nome utente / password da un modulo e usa l'arricciatura con l'autenticazione di base per chiedere al server un token di un token basato sul tempo TOTP. Non so quale lingua stai usando, ma nel Nodo JS ci sono librerie come questa https://github.com/guyht/notp che sono progetti attivi e mantenuti.

Se si esegue l'hosting su Azure, è possibile utilizzare l'accesso condiviso SAS di Azure che fa parte dell'infrastruttura di Azure e consente di salvare codice e test.

score 0 · Answer 3

A pensarci bene - un ottimo modo per autenticare un'API che espone le funzionalità dei tuoi sistemi ai partner è OAUTH2 - ciò che è eccezionale di OAUTH2 è che hai una buona scelta di librerie e puoi usare un flusso che si adatta al tuo utente relazione - flusso del server, flusso del browser web, flusso mobile, flusso della password senza modificare la logica di business dell'API sottostante.