Differenza di sicurezza tra i token Web e la firma dei messaggi

Question

Differenza di sicurezza tra i token Web e la firma dei messaggi

#1 da (1 voti)

1

Vedo ampiamente utilizzati due diversi tipi di autenticazione, di cui uno molto più complesso dell'altro. Uno è i token ID sessione semplici utilizzati nella maggior parte dei siti Web (l'utente invia le informazioni di accesso, riceve un token e passa quel token con ogni richiesta futura come autorizzazione). L'altra è la firma HMAC utilizzata in alcune API (utilizza chiavi pubbliche / private per la codifica dei messaggi).

Dall'esterno, il metodo HMAC sembra molto più sicuro. I messaggi non possono essere falsificati o duplicati, sai che il messaggio è sempre autentico. Tuttavia richiede molto più lavoro per comprimere e firmare ogni richiesta, e richiede un modo per il client di accedere alle chiavi pubbliche / private da utilizzare per la firma.

Per contratto, i token sono in circolazione da molto tempo e sembrano relativamente sicuri se usati correttamente (trasmettono solo tramite SSL, passano un nuovo token con ogni risposta del server, registrano l'ultimo token utilizzato, ecc.), e non richiedono alcuna gestione delle chiavi.

Quindi perché la firma HMAC esiste sul web? Esistono scenari in cui i token di sessione semplici non possono essere protetti? Se sì, perché i token sono ancora in uso?

I token sono molto più facili da progettare un thin client quando non devo trovare un modo per passare le chiavi, ma non voglio nemmeno spararmi ai piedi ignorando eventuali buchi di sicurezza.

hmac account-security session-management web-service

posta Nairou 24.10.2017 - 17:59

fonte

1 risposta

Leggi altre domande sui tag hmac account-security session-management web-service

Come interpretare le regole di autorizzazione booleane di SELinux? Proxychains non funziona, il test di leak DNS mostra la posizione

score 1 · Accepted Answer

I token firmati sono utili nella situazione in cui è presente una separazione tra il server che effettua l'accesso e il server che fornisce il servizio. Il server che ti accede ti fornisce un token, firmato con la sua chiave privata. Il server che fornisce il servizio non ha bisogno di conoscere quella chiave, può verificare con la chiave pubblica del server di login per assicurarsi che sia valida.

Le sessioni semplici sono perfette per le configurazioni di un singolo server, ma possono essere più impegnative (anche se non impossibili da qualsiasi sforzo) per ridimensionare, poiché l'ID di sessione deve essere ricercato sul lato server per convalidarlo - un ID di sessione è valido se e solo se si trova nell'elenco delle sessioni attive del server. Ciò significa che se una sessione viene creata su un server, è necessario un lavoro aggiuntivo per riconoscerlo da un server separato. Esistono framework per sessioni cross-server, ma nella maggior parte dei casi non è l'impostazione predefinita.

Se fai token, devi assicurarti che tutti i token che hai accettato siano firmati in modo appropriato e che controlli che siano esattamente come ti aspetti. Ci sono state alcune vulnerabilità note che accade quando non sei rigido riguardo agli algoritmi che accetti sul tuo sito - devi andare oltre lo standard JWT e in realtà applicare il tuo standard più severo in generale. (Non sono d'accordo con la conclusione di questo articolo, ma dovresti esserne a conoscenza se fai JWT o simili token)