In Oauth qual è il vantaggio del token di accesso che è opaco

8

Perché è stata presa la decisione che il Cliente non debba essere in grado di analizzare il token di accesso?

Mi sembra che se il token includesse, oltre ai campi correnti, un client_id e un id_utente, renderebbe la vita molto più semplice, impedire lo spoofing, abilitare l'autenticazione, ecc.

Ho notato che come per sezione 1.4 di RFC 6749 non deve essere opaco , ma mi sembra che gran parte di OpenID Connect, se non di tutto, sia un modo per rendere il token di accesso in qualcosa di significativo. Sì, aggiunge un token ID, ma il fatto che sia implementato come qualcosa che accompagna invece incorporato nel token di accesso non cambia questo fatto. Sembra che ogni video, tutorial e post sul blog parlino di questo come se si dovesse presumere che i token di accesso saranno opachi, perché "il cliente non è il pubblico previsto" ... Eppure è il API o fornitore di risorse che non può stabilire l'autenticazione in base al portatore con il token.

In realtà ho bisogno di aggiungere che non penso che il token sia opaco per il client sia il problema. Il problema è che il token è un token al portatore che non limita l'OMS ad usarlo.

    
posta Johan 02.05.2015 - 13:52
fonte

1 risposta

8

In OAuth, o qualsiasi altro protocollo in cui il token può essere opaco o trasparente, i benefici e i rischi oscillano in base a quale sia il risultato desiderato:

  • Se vuoi che il client sia in grado di analizzare il token di accesso, è necessario che il token sia trasparente.
  • Se non vuoi che il client sia in grado di analizzare il token di accesso, è necessario che il token sia opaco.

In effetti, questa è la definizione di token opachi e trasparenti; il cliente può vederli o no.

Se il tuo token è trasparente, devi firmarlo, altrimenti chiunque potrebbe semplicemente modificare il contenuto del token e rivendicare qualsiasi cosa desideri.

Quindi, il primo ovvio vantaggio di avere un token opaco è che puoi semplicemente eliminare qualsiasi meccanismo di firma; non ne hai bisogno e, viceversa, se hai un token trasparente appropriato, il client può leggere il token, ma non modificarlo.

Un altro vantaggio di avere un token opaco è che è più sicuro; Nessun metodo di crittografia è veramente casuale (vale a dire, deve esserci un modo per decrittografarlo), il che significa che puoi sempre dire quale protocollo di crittografia è usato se puoi leggere abbastanza del contenuto dei token (token trasparenti). Questo stesso riduce il tempo per identificare il tuo cifrario (conoscendo il protocollo). Molte persone non pensano che questo sia molto rischioso, e in effetti, se si usano più di 80 bit di entropia, hanno ragione (10 caratteri veramente casuali per il proprio codice, ad esempio "chiave segreta").

Tuttavia, e questo è molto più di un rischio; i token trasparenti consentono ai cracker di giocare con i contenuti (perché li vedono), e alcuni protocolli hanno gravi punti deboli che consentono di creare collisioni o addirittura decodificare il codice in un periodo molto più breve perché il cracker conoscerà il protocollo e il contenuto di blocchi validi (la maggior parte dei protocolli di crittografia utilizza blocchi di 16 byte, quindi se il tuo token contiene 160 caratteri di dati, hai dato al cracker 10 combinazioni valide per il tuo codice. Questo diminuisce il tempo necessario per identificare il tuo cifrario di un ordine di grandezza, dando loro dei token più trasparenti ridurrai ulteriormente anche questo tempo. Alcuni protocolli hanno una versione ridotta di questo rischio, ma dalla natura di ciò che è la codifica, avendo il blocco codificato e il blocco decodificato entrambi nelle tue mani , lo farai sempre più facilmente.

Ecco perché molti scelgono token opachi. In effetti dovresti sempre optare per token opachi se non è necessario che un'entità esterna sia in grado di analizzare il tuo token. Un esempio di questo è un framework di servizio in cui si passa il token al servizio solo come richiesta cieca; non hai idea di cosa dice, ma sai che funziona e ti identifica. Spetta solo al servizio confermare che sei tu tramite la chiave segreta o la cifra.

Anche i token opachi non richiedono la firma, cosa che ho menzionato sopra, inoltre non richiedono la divulgazione di nulla sui protocolli scelti.

Per questo motivo, sono molto più sicuri, non solo matematicamente e logicamente, ma si liberano degli errori di implementazione umana, che è, ad essere onesti, il 99% del motivo per cui le crepe sono mai state create in primo luogo.

Nota interessante

Anche casualità vera significa una perdita del 36,7% (1 diviso per e) dello spazio combinato quando si indovina a caso. Ciò significa che un lucchetto a combinazione di 1000 possibilità, se indovinato casualmente, in realtà ha una probabilità su 1 su 730 di correggerlo.

Quindi 1 / e è la migliore possibilità che tu abbia, e questo è puro caso.

Ogni "possibilità" che è interessante per un essere umano, "informazione", non è veramente casuale per definizione, e peggio, qualsiasi protocollo che viene usato per decodificarlo, lascia un po 'di spazio per il cifrario dal modo in cui il protocollo lavori. Quindi, in realtà, le tue possibilità di indovinare casualmente una risposta sono significativamente minori rispetto all'entropia o allo spazio combinato di cui la maggior parte della gente parla o pensa di avere effettivamente; di solito, quando tutti gli account sono misurati da un buon hacker, almeno un ordine di grandezza è più semplice di quanto non creda un laico.

    
risposta data 08.06.2017 - 20:44
fonte

Leggi altre domande sui tag