Ho letto un articolo che documenta Twitter ritirando bruscamente il suo supporto OAuth nell'aprile del 2009. Il l'articolo dice che non specificherà il buco per ragioni di sicurezza, ma menziona "l'ingegneria sociale".
Immagino che il buco sia che un sito dannoso può fingere di usare OAuth e reindirizzare l'utente a un sito di phishing che intende imitare Twitter nel tentativo di ottenere il nome utente e la password. È corretto?
Inoltre, qualunque sia la falla, come viene affrontato in 2.0?
L'aprile 2009 "attacco di fissazione della sessione" è descritto qui: link e più in dettaglio qui: link
Sicurezza significa cose diverse da prospettive diverse. Mentre continuo a ripetere su questo sito, tutto dipende dal tuo modello di minaccia. I fornitori di applicazioni hanno un diverso modello di minaccia rispetto agli utenti, che è diverso da quello della RIAA.
C'è un movimento tra alcuni utenti di OAuth 2.0 dalle crittografie a un modello "wrap": "token bearer avvolti con TLS" (come i cookie). L'editore delle specifiche parla delle sue preoccupazioni per gli scenari di scoperta interoperabile: link In Draft 11 della specifica OAuth 2.0 è tornata l'opzione per le firme. La specifica del token al portatore viene spostata su una specifica companion e ci sono anche le specifiche companion per le firme tramite SAML e Kerberos . Forse ce ne saranno altri (come lo schema OAuth 1.0?) Vedi la decisione e il pensiero al link
Vedi anche un altro commento precedente: link
Ecco un'altra discussione su come può essere complicato gestire le diverse prospettive di sicurezza.
Leggi altre domande sui tag authentication cryptography authorization protocols federation