AWS Signature V4 vs OAuth + gettoni del portatore JWT

3

Per proteggere le API REST, una scelta logica per il controllo degli accessi è JWT da sola o in combinazione con OAuth. Se mi interessa solo autenticare il chiamante, verificare una firma JWT è sufficiente da solo. Se mi interessa anche dell'autorizzazione, utilizzerei OAuth, o qualche tipo di servizio token. Ad ogni modo, includo un'intestazione come Authorization: Bearer [JWT token] nella richiesta HTTP.

AWS ha il proprio standard per il controllo dell'accesso API in cui si firmano parti del si richiede e include un'intestazione come Authorization: AWS4-HMAC-SHA256 ....

Le mie domande:

  • l'approccio di AWS è più sicuro contro gli attacchi di riproduzione? Penso di sì, perché anche se hai una scadenza breve del token, è ancora ipoteticamente possibile riutilizzare un token al portatore su una richiesta diversa. La firma indica che la richiesta non è stata manomessa.

  • se è più sicuro, dovrebbe essere considerato uno standard del settore come OAuth e JWT? In che misura i framework delle app standard forniscono supporto sul lato della validazione? ecc.

posta wrschneider 29.06.2017 - 17:54
fonte

2 risposte

2

is the AWS approach more secure against replay attacks? I think yes, because even if you have a short token expiration, it's still hypothetically possible to reuse a bearer token on a different request. The signature means the request hasn't been tampered with.

Sì, è più sicuro contro gli attacchi di riproduzione. Come hai suggerito, i token Bearer possono essere usati con qualsiasi richiesta (non solo teoricamente). Sono completamente indipendenti dalla richiesta che autorizzano. Le firme AWS, d'altra parte, sono "vincolate" alla richiesta a cui sono collegate. La richiesta firmata contiene anche un timestamp controllato da AWS per accertarsi che si trovi all'interno di una determinata finestra. La richiesta può essere riprodotta solo in questa finestra.

Proprio come hai detto tu, la firma garantisce l'integrità della richiesta. L'integrità è fornita anche da HTTPS. Lo schema AWS mantiene l'integrità anche se HTTPS viene portato via.

if it is more secure, should it be considered an industry standard like OAuth and JWT? To what extent do standard app frameworks provide support on the validation side? etc.

Ti offre più proprietà di sicurezza. Esistono altri schemi di firma HTTP che tentano di replicare ciò che fa AWS. Ecco una bozza . Joyent ha anche creato il proprio schema . Esiste anche una libreria chiamata Escher , che replica completamente lo schema AWS. È anche compatibile con esso e include anche il lato di convalida.

DISCLAIMER: Lavoro per la società che ha sviluppato Escher. Lo usiamo in produzione per collegare molti servizi.

    
risposta data 29.07.2017 - 23:23
fonte
1

is the AWS approach more secure against replay attacks? I think yes, because even if you have a short token expiration, it's still hypothetically possible to reuse a bearer token on a different request. The signature means the request hasn't been tampered with.

Tutte le richieste inviate utilizzando l'API hanno un timestamp ad esse associato. AWS rifiuta le richieste ricevute oltre 5 minuti dopo la data / ora. Per la riproduzione entro i 5 minuti, possono semplicemente mantenere una finestra scorrevole di richieste memorizzate nella cache. Può abbinare l'hash a quello in cache e rilevare la riproduzione.

if it is more secure, should it be considered an industry standard like OAuth and JWT? To what extent do standard app frameworks provide support on the validation side? etc.

Se stai parlando del concetto base di hashing di una richiesta e dell'invio dell'hash insieme alla richiesta, è qualcosa che è già stato fatto. Ritengo che il sistema utilizzato da Amazon sia ispirato al sistema Kerberos che ha un meccanismo simile di rilevamento degli attacchi di riproduzione e l'idea di eseguire l'hashing della richiesta e di allegarla per garantire che non venga manomessa durante il percorso.

    
risposta data 29.06.2017 - 21:00
fonte

Leggi altre domande sui tag